| Age | Commit message (Collapse) | Author |
|---|
|
https://github.com/rubygems/rubygems/commit/a0f7851451
|
|
This test confirms that a bug that existed in 2.6.3
was fixed by https://github.com/rubygems/rubygems/commit/b8e55087f026
https://github.com/rubygems/rubygems/commit/9e4ca5c5b2
|
|
missing
https://github.com/rubygems/rubygems/commit/054a0cd76c
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
https://github.com/rubygems/rubygems/commit/e891be9197
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
Because it does not swallow errors if it fails to remove the given
folders, making issues easier to debug.
https://github.com/rubygems/rubygems/commit/0db12d7afc
|
|
are incorrect
Resolver had internal logic to prioritize locked versions when sorting
versions, however part of it was not being actually hit because of how
unlocking worked in the resolver: a package was allow to be unlocked
when that was explicit requested or when the list of unlocks was empty.
That did not make a lot of sense and other cases were working because
the explicit list of unlocks was getting "artificially filled".
Now we consider a package unlocked when explicitly requested (`bundle
update <package>`), or when everything is being unlocked (`bundle
install` with no lockfile or `bundle update`).
This makes things simpler and gets the edge case added as a test case
working as expected.
https://github.com/rubygems/rubygems/commit/b8e55087f0
|
|
And avoid installing any gems.
https://github.com/rubygems/rubygems/commit/c12700c7e4
|
|
https://github.com/rubygems/rubygems/commit/96496e3f53
Co-authored-by: Johnny Shields <[email protected]>
|
|
In particular, when a gem registry transitive dependency is changed to a
git source direct dependency.
https://github.com/rubygems/rubygems/commit/bcdc7660d9
|
|
https://github.com/rubygems/rubygems/commit/92196ccfdb
|
|
https://github.com/rubygems/rubygems/commit/9548aa6766
|
|
And get specs passing.
https://github.com/rubygems/rubygems/commit/c23b5f5b84
|
|
https://github.com/rubygems/rubygems/commit/0658903e25
|
|
While working on something else I noticed:
* Usage of uppercased "RUBY" and "JAVA" as platforms, when those don't
really exist.
* Usage of some test gems with "1.0" as gemspec version and "1.0.0" as
actual version.
This commit fixes both inconsistencies to make things more expectable.
https://github.com/rubygems/rubygems/commit/e3ec32e247
|
|
|
|
a full unlock
https://github.com/rubygems/rubygems/commit/a8670e43f8
|
|
So that those lockfiles still work with older Bundler versions.
https://github.com/rubygems/rubygems/commit/880275bb66
|
|
https://github.com/rubygems/rubygems/commit/2d9eeadb62
|
|
https://github.com/rubygems/rubygems/commit/e8a363713e
|
|
If two platform specific variants have different dependencies, then
resolution may fallback to the non platform specific variant. However,
the platform specific variants that have the same dependencies as the
non specific one can still be kept.
Do a pass to complete those after resolution.
|
|
|
|
And make it easier to update next time.
https://github.com/rubygems/rubygems/commit/1ea4bfa5d8
|
|
https://github.com/rubygems/rubygems/commit/bb66253f2c
|
|
Looks for the CHECKSUMS section in the lockfile, activating the feature
only if the section exists. Without a CHECKSUMS section, Bundler will
continue as normal, validating checksums when gems are installed while
checksums from the compact index are present.
https://github.com/rubygems/rubygems/commit/2353cc93a4
|
|
https://github.com/rubygems/rubygems/commit/ed4eaefac0
|
|
https://github.com/rubygems/rubygems/commit/93619c97ff
|
|
Since we started locking the specific platform in the lockfile, that has
created an annoying situation for users that don't develop on Linux.
They will create a lockfile on their machines, locking their local
platform, for example, darwin. But then that lockfile won't work
automatically when deploying to Heroku for example, because the lockfile
is frozen and the Linux platform is not included.
There's the chance though that resolving against two platforms (Linux +
the local platform) won't succeed while resolving for just the current
platform will. So, instead, we check other platform specific variants
available for the resolution we initially found, and lock those
platforms and specs too if they satisfy the resolution.
This is only done when generating new lockfiles from scratch, existing
lockfiles should keep working as before, and it's only done for "ruby
platforms", i.e., not Java or Windows which have their own complexities,
and so are excluded.
With this change, we expect that MacOS users can bundle locally and
deploy to Heroku without needing to do anything special.
https://github.com/rubygems/rubygems/commit/5f24f06bc5
|
|
https://github.com/rubygems/rubygems/commit/7ab4c203f9
|
|
Improve error reporting for checksums, raises a new error class.
Solve for multi-source checksum errors.
Add CHECKSUMS to tool/bundler/(dev|standard|rubocop)26_gems.rb
https://github.com/rubygems/rubygems/commit/26ceee0e76
Co-authored-by: Samuel Giddins <[email protected]>
|
|
code.
(https://github.com/rubygems/rubygems/pull/6917)
https://github.com/rubygems/rubygems/commit/2238bdaadc
|
|
This gets the specs passing, and handles the fact that we expect
checkums to be pinned only to a particular source
This also avoids reading in .gem files during lockfile generation,
instead allowing us to query the source for each resolved gem to grab
the checksum
Finally, this opens up a route to having user-stored checksum databases,
similar to how other package managers do this!
Add checksums to dev lockfiles
Handle full name conflicts from different original_platforms when adding checksums to store from compact index
Specs passing on Bundler 3
https://github.com/rubygems/rubygems/commit/86c7084e1c
|
|
We lock the checksum for each resolved spec under a new CHECKSUMS
section in the lockfile.
If the locked spec does not resolve for the local platform, we preserve
the locked checksum, similar to how we preserve specs.
Checksum locking only makes sense on install. The compact index
information is only available then.
https://github.com/rubygems/rubygems/commit/bde37ca6bf
|
|
When a path does not make a lot of sense.
https://github.com/rubygems/rubygems/commit/d173c79e9a
|
|
https://github.com/rubygems/rubygems/commit/9a0e0dfd5b
|
|
https://github.com/rubygems/rubygems/commit/b86caaa3d5
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7873
|
|
I've never seen this error in real life, and if it was happening, I
think it's either some server side issue that would need to be fixed or
some transient issue. We should move away from the full index, since
it's slow, so let's stop recommending it.
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
To make it easier to change the default platforms that get locked later.
https://github.com/rubygems/rubygems/commit/255c4012ec
|
|
Nicer :)
https://github.com/rubygems/rubygems/commit/c0ab2893c3
|
|
https://github.com/rubygems/rubygems/commit/d2c56315e2
|
|
Following up on https://github.com/rubygems/rubygems/pull/6355, which
turned a crash into a nicer error message, this commit auto-heals the
corrupt lockfile instead.
In this particular case (a corrupt Gemfile.lock with missing
dependencies) the LazySpecification will not have accurate dependency
information, we have to materialize the SpecSet to determine there are
missing dependencies. We've already got a way to handle this, via
`SpecSet#incomplete_specs`, but it wasn't quite working for this case
because we'd get to `@incomplete_specs += lookup[name]` and
`lookup[name]` would be empty for the dependency.
With this commit we catch it a bit earlier, marking the parent spec
containing the missing dependency as incomplete.
https://github.com/rubygems/rubygems/commit/486ecb8f20
|
|
https://github.com/rubygems/rubygems/commit/c8e024359f
Notes:
Merged: https://github.com/ruby/ruby/pull/7345
|
|
I did a bad thing (script that edits the Gemfile.lock directly) and
ended up with a Gemfile.lock that was completely missing some indirect
dependencies. While this is my fault and an error is reasonable, I
noticed that the error got progressively less friendly in recent
versions of bundler.
Something similar came up in https://github.com/rubygems/rubygems/issues/6210,
and this commit would have helped with that case as well
(although we've already handled this a different way with #6219).
Details:
---
Back on Bundler 2.2.23, a corrupt lockfile like this would cause a helpful error:
```
Unable to find a spec satisfying minitest (>= 5.1) in the set. Perhaps the lockfile is corrupted?
```
Bundler 2.3.26 gave a helpful warning:
```
Warning:
Your lockfile was created by an old Bundler that left some things out.
Because of the missing DEPENDENCIES, we can only install gems one at a time,
instead of installing 16 at a time.
You can fix this by adding the missing gems to your Gemfile, running bundle
install, and then removing the gems from your Gemfile.
The missing gems are:
* minitest depended upon by activesupport
```
But then continued on and crashed while trying to report the unmet
dependency:
```
--- ERROR REPORT TEMPLATE -------------------------------------------------------
NoMethodError: undefined method `full_name' for nil:NilClass
lib/bundler/installer/parallel_installer.rb:127:in `block (2 levels) in check_for_unmet_dependencies'
...
```
Bundler 2.4.0 and up crash as above when jobs=1, but crash
even harder when run in parallel:
```
--- ERROR REPORT TEMPLATE -------------------------------------------------------
fatal: No live threads left. Deadlock?
3 threads, 3 sleeps current:0x00007fa6b6704660 main thread:0x00007fa6b6704660
* #<Thread:0x000000010833b130 sleep_forever>
rb_thread_t:0x00007fa6b6704660 native:0x0000000108985600 int:0
* #<Thread:0x0000000108dea630@Parallel Installer Worker #0 tmp/1/gems/system/gems/bundler-2.5.0.dev/lib/bundler/worker.rb:90 sleep_forever>
rb_thread_t:0x00007fa6b67f67c0 native:0x0000700009a62000 int:0
* #<Thread:0x0000000108dea4a0@Parallel Installer Worker #1 tmp/1/gems/system/gems/bundler-2.5.0.dev/lib/bundler/worker.rb:90 sleep_forever>
rb_thread_t:0x00007fa6b67f63c0 native:0x0000700009c65000 int:0
<internal:thread_sync>:18:in `pop'
tmp/1/gems/system/gems/bundler-2.5.0.dev/lib/bundler/worker.rb:42:in `deq'
...
```
Changes
---
This commit fixes the confusing thread deadlock crash by detecting if
dependencies are missing such that we'll never be able to enqueue. When
that happens we treat it as a failure so the install can finish.
That gets us back to the `NoMethodError`, which this commit fixes by
using a different warning in the case where no spec is found.
https://github.com/rubygems/rubygems/commit/d73001a21d
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7020
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6987
|
|
Pick from https://github.com/rubygems/rubygems/commit/ba3adad4d80038ffd7bea015da2f11d3e8a2ff82
Notes:
Merged: https://github.com/ruby/ruby/pull/6966
|
|
We have a check for a corrupt lockfile right before installing. However,
the check accounted for locked specs not satisfying locked dependencies,
but not for locked specs missing for some locked dependencies.
Instead of fixing this check, I decided to remove it in favor of
automatically detecting the situation and re-resolve to automatically
fix the lockfile rather than printing a warning but leave the problem
there.
https://github.com/rubygems/rubygems/commit/4a7a584252
Notes:
Merged: https://github.com/ruby/ruby/pull/6966
|
|
Pick from https://github.com/rubygems/rubygems/commit/084f7d1f21f6fc3e2bb685b7bda3653fb2891c6e
Notes:
Merged: https://github.com/ruby/ruby/pull/6936
|
