| Age | Commit message (Collapse) | Author |
|---|
|
https://github.com/rubygems/rubygems/commit/8f262f3a47
|
|
https://github.com/rubygems/rubygems/commit/907d46964d
|
|
https://github.com/rubygems/rubygems/commit/3434f094a2
|
|
A spec needed changes because now loading the default `json` prints a
warning about `ostruct` getting loaded although it will be removed in
the future. Use a different default gem to test this.
https://github.com/rubygems/rubygems/commit/7415a66906
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
|
|
included
https://github.com/rubygems/rubygems/commit/b9a2d4d539
|
|
The behavior it's testing is independent from the bundle path being
used.
https://github.com/rubygems/rubygems/commit/9a4b32ec82
|
|
Looking at the description is something that used to be done a long time
ago.
https://github.com/rubygems/rubygems/commit/9c226f52a6
|
|
Co-authored-by: Vít Ondruch <vondruch@redhat.com>
|
|
https://github.com/rubygems/rubygems/commit/edbb2e3475
|
|
They are used by default.
https://github.com/rubygems/rubygems/commit/0b7f7d879f
|
|
As long as we use a high enough test version, the default version of
Bundler should never get in the middle.
https://github.com/rubygems/rubygems/commit/d63f0818aa
|
|
https://github.com/rubygems/rubygems/commit/d850ea1d95
|
|
This was commented out almost 10 years ago, but I think it passes now!
https://github.com/rubygems/rubygems/commit/4a6b1aba3c
|
|
has extensions and `gemspec` DSL is being used
In a `bundle exec` context, the local specification will actually be
part of the known specifications, so RubyGems will assume it has already
been installed, which is not actually true.
This will cause `RequestSet` to rebuild extensions for a gem that's not
actually installed, causing errors.
The fix is to make sure detection of installed activation requests
considers not only that there's a known spec with the same full name as
the one being installed, but also that this spec is installed in the
same gem_home were pretend to install the new gem.
https://github.com/rubygems/rubygems/commit/a8ef1286a6
|
|
actually useful
DSLError prints the specific line in a Gemfile where the error was
raised. That's helpful when the error was explicitly raised by the
Gemfile DSL or, in the case it's implicitly raised, when the offending
code lives right in the Gemfile.
If it's an internal error, or something buried dowm in user code called
from the Gemfile, `DSLError` is not helpful since it hides the actual
culprit.
This commit tries to only raise `DSLError` in the cases mentioned above
and otherwise let the original error be raised.
https://github.com/rubygems/rubygems/commit/b30ff5a682
|
|
Currently, an exe file isn't executable when generating new gems
because it doesn't have the correct permission.
This PR sets the correct permission same as files under the `bin`.
https://github.com/rubygems/rubygems/commit/6509bf128a
|
|
`make test-bundler` on ruby/ruby don't have installed gemspec.
So, `require "psych"` didn't activate psych as default gems on ruby repo.
https://github.com/rubygems/rubygems/commit/f8ca514cbb
|
|
https://github.com/rubygems/rubygems/commit/6b1e8a14bd
|
|
With a default git setup, each cloned repo in the cache will end up with
~60K of sample git hooks. These files all end in `.sample`, and they are
disabled by default. Deleting them should be a no-op, and makes the
cache a bit smaller.
https://github.com/rubygems/rubygems/commit/d2149999cd
|
|
using local overrides
https://github.com/rubygems/rubygems/commit/0a6c1c53ce
|
|
Ruby ships with empty directories for default gems. If Ruby
installations has unsafe world-writable permissions, we will complain
when about to install a gem that happens to be also a default gem,
because we'll start by removing the previous install folder and that's
supposed to be insecure due to too loose permissions.
However, if the folder is empty, we don't actually need to remove
anything, so we can skip the whole thing, avoiding the errors.
https://github.com/rubygems/rubygems/commit/2f3cd8ac4e
|
|
https://github.com/rubygems/rubygems/commit/7c71dac22e
|
|
I found it useful to be able to use `GEM_COMMAND` outside of a ruby-core
env, so I made the ruby-core env detection not depend on it.
https://github.com/rubygems/rubygems/commit/6cb389c290
|
|
`bundle outdated`
Before, `bundle outdated --parseable` (or `--porcelain`) caused output
to be completely silenced during definition resolution, so nothing was
printed at all until the table of outdated gems was printed.
With this change, `--parseable`/`--porcelain` now prints progress to
stderr during resolution. E.g.:
```
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
```
This provides a better user experience, especially when
`outdated --parseable` takes several seconds or more.
The report of outdated gems is still printed to stdout, and the exit
status codes are unchanged, so the fundamental contract with other tools
consuming the `outdated --parseable` result should not be affected.
https://github.com/rubygems/rubygems/commit/7d4bb43570
|
|
git sources
`version` is actually an attribute of the dependency, not of the git
source. Sometimes it's passed to the git source to be able to fake a
gemspec in case there's no gemspec in the source, but it should not be
used for source comparison.
https://github.com/rubygems/rubygems/commit/d936fbd78e
|
|
https://github.com/rubygems/rubygems/commit/a1046466c9
|
|
--add-platform`
https://github.com/rubygems/rubygems/commit/1f93a2bdc5
|
|
`bundle lock`
`bundle lock --print --update` can take a long time to fetch sources and
resolve the lock file.
Before, `--print` caused output to be completely silenced, so nothing
was printed at all until the resolved lock file is finally emitted to
stdout.
With this change, `--print` now prints progress to stderr. E.g.:
```
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
```
This provides a better user experience, especially when
`lock --print --update` takes several seconds or more.
The lock file is still printed to stdout, so tools consuming the lock
file on stdout will not be affected.
https://github.com/rubygems/rubygems/commit/6719baa700
|
|
https://github.com/rubygems/rubygems/commit/e021ff33a8
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/11458
|
|
In https://bugs.ruby-lang.org/issues/20693, I'd like to have Dir.tmpdir
call `File.writable?` instead of `Stat#writable?`. However, that causes
this test to break in bundler because it's using RSpec to stub
`File.writable?`.
We can fix this by allowing the real `File.writable?` to be called for
all files except the directory we're trying to stub.
https://github.com/rubygems/rubygems/commit/0fa6657293
|
|
frozen being set without a lockfile
https://github.com/rubygems/rubygems/commit/0857d62ca6
|
|
The original implementation of this flag was too naive and all it did
was restricting gems to locally installed versions if there are any
local versions installed.
However, it should be much smarter. For example:
* It should fallback to remote versions if locally installed version
don't satisfy the requirements.
* It should pick locally installed versions even for subdependencies not
yet discovered.
This commit fixes both issues by using a smarter approach similar to how
we resolve prereleases:
* First resolve optimistically using only locally installed gems.
* If any conflicts are found, scan those conflicts, allow remote
versions for the specific gems that run into conflicts, and
re-resolve.
https://github.com/rubygems/rubygems/commit/607a3bf479
Co-authored-by: Gourav Khunger <gouravkhunger18@gmail.com>
|
|
The `file://` protocol does not really work with relative paths and it's
not necessary anyways. So restore support for that by not using
`file://`.
https://github.com/rubygems/rubygems/commit/16a68998ce
|
|
Doesn't really change the test outcome, but I noticed it was missing.
https://github.com/rubygems/rubygems/commit/ea4f9d5209
|
|
unsupported Ruby version
https://github.com/rubygems/rubygems/commit/9d41c4088a
|
|
include bare repos
https://github.com/rubygems/rubygems/commit/417319ecb1
|
|
section is badly indented
https://github.com/rubygems/rubygems/commit/ec099ebf1e
|
|
update <specific_gem>` is run
https://github.com/rubygems/rubygems/commit/eec6830c04
|
|
https://github.com/rubygems/rubygems/commit/d8cf4aa0cd
|
|
When resolving on truffleruby, and multiple platforms are included in
the lockfile, Bundler will not respect existing platforms, but always
force ruby variants. That means removal of existing version specific
variants, introducing lockfile churn between implementations.
To prevent this, we introduce the distinction between
`Dependency#force_ruby_platform`, only settable via Gemfile, and
`Dependency#default_force_ruby_platform`, which is always true on
truffleruby for certain dependency names. This way, when resolving
lockfile gems for other platforms on truffleruby, we keep platform
specific variants in the lockfile.
However, that introduces the problem that if only platform specific
variants are locked in the lockfile, Bundler won't be able to
materialize on truffleruby because the generic variant will be missing.
To fix this additional problem, we make sure the generic "ruby" platform
is always added when resolving on truffleruby.
|
|
https://github.com/rubygems/rubygems/commit/3570ba20ed
|
|
include the current platform
https://github.com/rubygems/rubygems/commit/afb7a6d754
|
|
https://github.com/rubygems/rubygems/commit/680bafac1a
|
|
https://github.com/rubygems/rubygems/commit/0fc3feae19
|
|
truffleruby to cruby
https://github.com/rubygems/rubygems/commit/4f3d9fa3bf
|
|
We use pre-existence of `rake_path` to decide whether we need to
regenerate dummy test gems in `tmp`. When changing rubies, the previous
implementation will believe that the correct `rake_path` exists
and avoids regenerating dummy gems, given an error like the following
when specs are run:
```
(...)
Could not find rubygems-generate_index lib directory in /path/to/rubygems/bundler/tmp/1/gems/base/ruby/3.2.0
# ./spec/support/builders.rb:253:in `block in update_repo'
# ./spec/support/helpers.rb:337:in `block in with_gem_path_as'
# ./spec/support/helpers.rb:351:in `without_env_side_effects'
# ./spec/support/helpers.rb:332:in `with_gem_path_as'
# ./spec/support/builders.rb:251:in `update_repo'
# ./spec/support/builders.rb:228:in `build_repo'
# ./spec/support/builders.rb:197:in `build_repo4'
# ./spec/commands/lock_spec.rb:103:in `block (2 levels) in <top (required)>'
(...)
```
To fix this, fix the part of the path that depends on the implementation
and the Ruby version so that we don't give false positives.
https://github.com/rubygems/rubygems/commit/fafacfa210
|
|
Make `bundle check` exit with code 1 when gem git source is not yet
checked out.
https://github.com/rubygems/rubygems/commit/93162bf5af
|
|
Removes the symlink for gems.rb.tt and instead uses the singular
template file. Only the destination filename for the gemfile reads from
the `init_gems_rb` setting.
https://github.com/rubygems/rubygems/commit/43ce0e1666
|
|
|
