| Age | Commit message (Collapse) | Author |
|---|
|
https://github.com/ruby/rubygems/commit/d3baf4110e
|
|
https://github.com/ruby/rubygems/commit/c637007e91
|
|
"install_if" git gems:
- Fix https://github.com/rubygems/rubygems/pull/8985
- ### Problem
If you have a Gemfile that contains a `install_if` git gem, it will
be impossible to add other gems in the Gemfile and run
`bundle install`, you'll get a "The git source [...] is not yet
checked out".
### Context
The change that modified this behaviour was in https://github.com/rubygems/rubygems/commit/abbea0cc94dd,
and the issue is about the call to `current_dependencies`.
This call filters out irrelevant dependencies such as the one that
get condtionnally installed. By doing so, we skip over setting
the source based of the lockfile for that dependency
https://github.com/rubygems/rubygems/blob/ade324bdc8ea77b342f203cb7f3929a456d725ed/bundler/lib/bundler/definition.rb#L978
Ultimately, because of this, the dependency source doesn't have
any additional information such as the `revision`. Down the line,
when we end up to converge the spec, Bundler will attempt to get the
revision for that spec but won't be able to because the git source
isn't configured to allow running git operations.
### Solution
Filter out the irrelevant only spec only after we have set its
source.
https://github.com/rubygems/rubygems/commit/d2af439671
|
|
And make it a standard setting.
https://github.com/rubygems/rubygems/commit/17e356fa94
|
|
changes
When the source used to be git and switches back to rubygems,
it is possible that the git source contains a version that
ruybgems doesn't know about yet.
So don't add the locked spec to the base resolve, and also don't add a
lower bound requirement on the version, since the version in the new
source may actually be lower.
https://github.com/rubygems/rubygems/commit/85514e3a1e
|
|
https://github.com/rubygems/rubygems/commit/05199ae0c1
|
|
https://github.com/rubygems/rubygems/commit/d41b8d303c
|
|
Overriding the version constant feels too magic and creates a set of
problems. For example, Bundler will lock the simulated version, and that
can cause issues when the lockfile is used under an environment not
simulating Bundler 4 (it will try to auto-install and auto-switch to a
version that does not exist).
On top of that, it can only be configured with an ENV variable which is
not too flexible.
This commit takes a different approach of using a setting, which is
configurable through ENV or `bundle config`, and pass the simulated
version to `Bundler::FeatureFlag`. The real version is still the one set
by `VERSION`, but anything that `Bundler::FeatureFlag` controls will use
the logic of the "simulated version".
In particular, all feature flags and deprecation messages will respect
the simulated version, and this is exactly the set of functionality that
we want users to be able to easily try before releasing it.
https://github.com/rubygems/rubygems/commit/8129402193
|
|
Since we no longer pass ruby CLI flags in our spec commands, we no
longer need the previous workaround and can get the realworld code
tested.
https://github.com/rubygems/rubygems/commit/fd92c855fb
|
|
|
|
Currently to test Bundler 3 mode we have to actually edit the version
file to simulate we're running a future version. This is inconvenient.
Instead, allow passing an environment variable, `BUNDLER_3_MODE`, to set
the "working mode" Bundler should use.
This can now be set easily by end users to enable them to try out the
changes in the future version and give us feedback.
It's unclear how version auto-switching should work when this
environment variable is set, so the auto-switching feature will be
disabled in that case.
https://github.com/rubygems/rubygems/commit/4e92e9b209
|
|
https://github.com/rubygems/rubygems/commit/ee5a0158fd
|
|
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 <johnny.shields@gmail.com>
|
|
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 <segiddins@segiddins.me>
|
|
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
|
