| Age | Commit message (Collapse) | Author |
|
https://github.com/ruby/rubygems/commit/79ba4a537d
|
|
`Bundler.environment` helpers
https://github.com/rubygems/rubygems/commit/e1b8bdcede
|
|
|
|
This is not currently causing any issues, but I think the most correct
thing to do is that Bundler loads the extensions to RubyGems in the
first place, so that they are available from the beginning.
https://github.com/rubygems/rubygems/commit/88faa5c7bb
|
|
We have a quality spec that parses all code for explicit usages of
`Bundler.settings[<something>`, to detect undocumented settings. So
using `Bundler.settings` consistently will help catching these things.
https://github.com/rubygems/rubygems/commit/ce01bb7cc5
|
|
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
|
|
https://github.com/rubygems/rubygems/commit/d7b9c4532e
|
|
https://github.com/rubygems/rubygems/commit/f96fedf1f1
|
|
This will help centralize wheel platform selection logic eventually
Signed-off-by: Samuel Giddins <segiddins@segiddins.me>
|
|
https://github.com/rubygems/rubygems/commit/ca0a7ff8cd
|
|
These changes were included when adding bundler plugin hooks for
`Bundler.require`, but they seem completely unrelated to that feature,
and have caused several issues.
https://github.com/rubygems/rubygems/commit/8d56551dcf
|
|
This gives more flexibility to allow further improvements.
https://github.com/rubygems/rubygems/commit/f11a890f5e
|
|
https://github.com/rubygems/rubygems/commit/d8d68cc00e
|
|
https://github.com/rubygems/rubygems/commit/9e0018d9fe
|
|
https://github.com/rubygems/rubygems/commit/43c0c41c6b
|
|
Ruby's -w flag
When using the `bundler/setup` entrypoint, Bundler prints the following
warnings in JRuby in `-w` is passed to Ruby.
```
/path/to/bundler/shared_helpers.rb:10: warning: constant Bundler::WINDOWS is deprecated
/path/to/bundler/shared_helpers.rb:11: warning: constant Bundler::FREEBSD is deprecated
/path/to/bundler/lib/bundler/shared_helpers.rb:12: warning: constant Bundler::NULL is deprecated
```
This does not happen in CRuby.
This seems like a JRuby bug but we can skip it by autoloading the
constants.
https://github.com/rubygems/rubygems/commit/761ca29fa2
|
|
It gives better errors.
https://github.com/rubygems/rubygems/commit/bedae080ef
|
|
https://github.com/rubygems/rubygems/commit/f11e42a3c5
|
|
https://github.com/rubygems/rubygems/commit/72d8d4dbba
|
|
https://github.com/rubygems/rubygems/commit/47b7e50f64
|
|
string
https://github.com/rubygems/rubygems/commit/ab44fa9ee4
|
|
binstubs
https://github.com/rubygems/rubygems/commit/076aba8b1c
|
|
Gemfile as "local app"
https://github.com/rubygems/rubygems/commit/6aa2ac337f
|
|
https://github.com/rubygems/rubygems/commit/71bcf354f5
|
|
We have some places that already use `bundle config auto_install true`,
ie:
https://github.com/technicalpickles/rubygems/blob/7a144f3374f6a400cc9832f072dc1fc0bca8c724/bundler/lib/bundler/cli.rb#L11
This applies the same logic (copy and pasted) to happen when you
`require "bundler/setup"`.
https://github.com/rubygems/rubygems/commit/bb3c922341
|
|
https://github.com/rubygems/rubygems/commit/a2f43d3756
|
|
https://github.com/rubygems/rubygems/commit/e3d180620c
|
|
https://github.com/rubygems/rubygems/commit/a9d22e5f46
|
|
https://github.com/rubygems/rubygems/commit/b373b7ed0d
|
|
https://github.com/rubygems/rubygems/commit/6a0c03c77f
|
|
Small refactor, no functional change
https://github.com/rubygems/rubygems/commit/5edb7a1026
|
|
https://github.com/rubygems/rubygems/commit/c241a88962
|
|
https://github.com/rubygems/rubygems/commit/bb66253f2c
|
|
Because bundler needs to support older versions of rubygems, we can't
actually rely on Gem::CIDetector (yet - in a year or so they might be
able to consolidate, if they don't change futher). So we're copying it
into the Bundler:: namespace, and enforcing that they stay completely in
sync with a test. No other tests are needed, since Gem::CIDetector is
already tested, and this is and will remain identical.
https://github.com/rubygems/rubygems/commit/abc67f0da1
|
|
Generally the removed message is very similar, but often it needs to
specify that the feature has "been removed" instead of "will be
removed", or "been deprecated". And a few chunks of text needed more
substantial updates. And a number of them seemed to have been carefully
crafted to make sense in either context, so I left those alone.
https://github.com/rubygems/rubygems/commit/8d42cf9104
|
|
https://github.com/rubygems/rubygems/commit/e41156e272
|
|
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
|
|
https://github.com/rubygems/rubygems/commit/63b422b71a
|
|
https://github.com/rubygems/rubygems/commit/34d096e38a
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7873
|
|
|
|
This reverts commit 69580f8b72f41c58cae57d1ada4db909922b3891.
|
|
to Bundler.
https://github.com/rubygems/rubygems/commit/d768be0c65
|
|
Recent bugs fixed made me realize we were relying on state too much
here. We only need to keep incomplete specs to be able to expire them
and retry resolution without them locked. If we use a separate class, we
can do that more transparently and handle them just like we handle
"missing specs".
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
Just like gem sources, a "style-only" change, like adding a trailing
slash, should not expire them.
|
|
https://github.com/rubygems/rubygems/commit/4909d071d2
|
|
https://github.com/rubygems/rubygems/commit/5c5d0c5350
|
|
https://github.com/rubygems/rubygems/commit/23880353c1
|
|
from https://github.com/rubygems/rubygems/commit/0635c1423db5d7c461d53bf0c3329bca75de7609
Notes:
Merged: https://github.com/ruby/ruby/pull/7094
|
|
from https://github.com/rubygems/rubygems/commit/72fd3dd2096af16d797ad0cd8e0d2a8869e240b3
Notes:
Merged: https://github.com/ruby/ruby/pull/7025
|