| Age | Commit message (Collapse) | Author |
|---|
|
- ### Problem
Since https://github.com/ruby/rubygems/pull/9131, we are now
compiling make rules simultaneously. The number of jobs
is equal to the number of processors.
This may be problematic for some users as they want to control
this value.
### Solution
The number of jobs passed to `make` will now be equal to the
`BUNDLE_JOBS` value.
### Side note
It's also worth to note that since Bundler installs gems in
parallel, we may end up running multiple `make -j<JOB>` in parallel
which would cause exhaust the number of processors we have.
This problem can be fixed by implementing a GNU jobserver, which I
plan to do. But I felt that this would be too much change in one PR.
https://github.com/ruby/rubygems/commit/d51995deb9
|
|
When running a fresh `bundle install` with gems that contains
executables, Bundler will generate binstubs but soon after will remove
them. This is a regression introduced in https://github.com/ruby/rubygems/commit/573ffad3ea4a.
This results in doing `bundle install && bundle exec foo` to raise an
error saying `foo` couldn't be found.
This issue only appears if `BUNDLE_CLEAN` is set.
At the end of the installation process, when Bundler has installed
gems and generated binstubs, it runs the cleanup.
1. It [detects](https://github.com/ruby/rubygems/blob/4f8aa3b40cded3465bb2cd761e9ce7f8673b7fcb/bundler/lib/bundler/runtime.rb#L182) the executable for the current specs
2. Any existing executables not detected is then removed https://github.com/ruby/rubygems/blob/4f8aa3b40cded3465bb2cd761e9ce7f8673b7fcb/bundler/lib/bundler/runtime.rb#L194.
The issue being that 1. now returns an empty array where as it should
return the executables of the gems from the current bundle.
The problem is in https://github.com/ruby/rubygems/commit/573ffad3ea4a where we
removed the `executables` method from the `EndpointSpecification`.
When Bundler reads the lockfile, it creates a `EndpointSpecification`
object for each spec. At this point, the EndpointSpecification doesn't
know about the `executables` of a gem. Once Bundler fetches the
`gemspec` from the remote, it swaps the the "spec" with the real one
and from here knows what executables the gem has.
Reintroduce the `executables` method and the `bindir` in the
EndpointSpecification class. From what I'm seeing, the removal
of those wasn't needed to resolve the issue where Bundler remembers
CLI flags. This is probably an oversight.
https://github.com/ruby/rubygems/commit/b47f6b0247
|
|
over lockfile method in Gemfile
It would be simpler to do `options[:lockfile] ||= ENV["BUNDLE_LOCKFILE"]`,
but that doesn't work as `options` is frozen.
Fixes https://github.com/ruby/rubygems/pull/9117
https://github.com/ruby/rubygems/commit/6e3603a0e9
|
|
This allows for specifying the lockfile to read and write. It mirrors
the --gemfile option, and has higher priority than the lockfile
method in the Gemfile. It also mirrors the bundle lock --lockfile
option.
When the --lockfile option is used, it is applied twice. First, before
the Gemfile is read, to specify the lockfile to operate on, and again
after the Gemfile is read, so that if the Gemfile has a lockfile
method that overrides the defintion's lockfile, the --lockfile option
still has higher precedence.
https://github.com/ruby/rubygems/commit/17acdd4a89
|
|
This allows for the same behavior as including `lockfile false`
in the Gemfile. This allows you to get the behavior without
modifying the Gemfile, which is useful if you do not control the
Gemfile.
This is similar to the --no-lock option already supported by
`gem install -g Gemfile`.
https://github.com/ruby/rubygems/commit/6c94623881
Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>
|
|
This allows you to specify the lockfile to use. This is useful if
you want to use different lockfiles for different ruby versions or
platforms. You can also skip writing the lockfile by using a false
value.
https://github.com/ruby/rubygems/commit/2896aa3fc2
Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>
|
|
This is a first pass to improve the way errors are handled and raised in
bundler's tests. The goal is to clean up tests and modernize them -
these were some obvious areas that could be cleaned up.
- Instead of raising "ZOMG" in the load error tests, it now tests for
the actual error and gem raising.
- Improve error messages where applicable.
- All errors raise a specific error class, rather than falling back to a
default and just setting a message.
- Removed arguments and `bundle_dir` option from `TheBundle` class as it wasn't
actually used so therefore we don't need to raise an error for extra
arguments.
- Removed error from `BundlerBuilder`, as it won't work if it's not
`bundler`, also it never uses `name`. The only reaon `name` is passed
in is because of metaprogramming on loading the right builder. I
think that should eventually be refactored.
- Replaced and removed `update_repo3` and `update_repo4` in favor of
just `build_repo3` and `build_repo4`. Rather than tell someone writing
tests to use a different method, automatically use the right method.
https://github.com/ruby/rubygems/commit/68c39c8451
|
|
https://github.com/ruby/rubygems/commit/d3baf4110e
|
|
Always build gems with RubyGems programmatically
https://github.com/ruby/rubygems/commit/5cc0c34e64
|
|
https://github.com/rubygems/rubygems/commit/59b909fa74
|
|
https://github.com/rubygems/rubygems/commit/8f9d6c54a1
|
|
https://github.com/rubygems/rubygems/commit/573ffad3ea
|
|
the same gem in Gemfile
https://github.com/rubygems/rubygems/commit/e47a9064be
|
|
There are several issues with these which I'm not sure I'll have time to
address properly. I prefer to keep our default branch in a releasable
state just in case. Once they are fixed, this can be reverted.
|
|
long time
https://github.com/rubygems/rubygems/commit/41dab5954f
|
|
I realized `--redownload` is not a good name, because it does not
necessarily redownloads gems. It only forces reinstallation even if gem
is already installed.
So I believe `--force` is actually a better name and the introduction of
`--force` was a misunderstanding of what the `--force` flag did at the
time.
Let's cancel the deprecation of `--force`.
For now the `--redownload` alias is left around until we decide what to
do with it.
|
|
non-retryable
https://github.com/rubygems/rubygems/commit/cd529776d5
|
|
Since now every functionality that changes in Bundler 4 is under a
setting, we can enable that setting to test the new functionality,
without having to run our full CI twice.
This can actually be seen as increasing coverage, because Bundler 4
functionality will now be tested on Windows, MacOS, or any other
environment where previously "Bundler 4 mode" was not running.
https://github.com/rubygems/rubygems/commit/1cb3e009fc
|
|
As showed by the unskiped spec, on Windows trying to use the 0.0.0.0
interface raises this error, and it's raised as a generic system error
when trying to create a `bundler.lock` file. Here's is a better place to
handle that.
https://github.com/rubygems/rubygems/commit/e32c5a9e5c
|
|
https://github.com/rubygems/rubygems/commit/28b6a7cf5e
|
|
https://github.com/rubygems/rubygems/commit/b0983f392f
|
|
https://github.com/rubygems/rubygems/commit/bb13f4e702
|
|
https://github.com/rubygems/rubygems/commit/7026b5f2e5
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
It reads better this way I think.
https://github.com/rubygems/rubygems/commit/ce9743290d
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
|
|
This has the following benefits:
* Avoid duplicated work in some specs that first build a repo, and then
overwrite it with a completely different set of gems.
* Reduce RSpec nesting and improve readability.
* The change also made surfaces several specs that were incorrect since
they were unintentionally not testing the right thing.
https://github.com/rubygems/rubygems/commit/ed430883e0
|
|
This message is printed when running `bundle lock --add-platform`. This
command affects the lockfile, not the gemfile, and I think it's better
to use "You are adding" rather than "You added", because the addition is
happening during the current invocation (as opposed to other log
messages that talk about a change made to the Gemfile prior to running
the command).
https://github.com/rubygems/rubygems/commit/aba1e55f5b
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
not in lockfile
Current it says "you added a new platform to your gemfile", but that's
not actually the case here.
https://github.com/rubygems/rubygems/commit/1e39527a38
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
Unfortunately this requires reverting a previous enhancement of
reinstalling gems if they incorrectly ship with an empty installation
dir.
However, there's no way to distinguish this kind of bad state from a gem
that's empty for real, for example, sorbet-static-and-runtime.
This reverts commit https://github.com/rubygems/rubygems/commit/9720a9b980d2, and adds a
spec to make sure empty gems are not reinstalled every time.
https://github.com/rubygems/rubygems/commit/7c102394af
|
|
Bundler does not really have a concept of "development dependencies",
like RubyGems has. Bundler has the more generic concept of "groups".
Under the hood, the `gemspec` DSL will put gemspec development
dependencies under a `:development` Gemfile group, but there's no reason
to instantiate these as development dependencies, they are regular
runtime dependencies, except that they belong in a group named
:development.
By never instantiating development dependencies at all, we avoid having
to introduce hacks to "undo" the type Bundler does not know about, and I
also think the error messages read better.
https://github.com/rubygems/rubygems/commit/9a06fa5bda
|
|
gems are available locally
Filtering out remote specs should only apply where there are locally
installed specs. Otherwise they should always be considered.
https://github.com/rubygems/rubygems/commit/118f8389a1
|
|
https://github.com/rubygems/rubygems/commit/9720a9b980
|
|
https://github.com/rubygems/rubygems/commit/96496e3f53
Co-authored-by: Johnny Shields <johnny.shields@gmail.com>
|
|
I think they add unnecessary indirection and inconsistency to the specs.
https://github.com/rubygems/rubygems/commit/609924d985
|
|
https://github.com/rubygems/rubygems/commit/0057382bb1
|
|
to be conservative
When converging specification to pass the set of versions that should be
preserved from the lockfile during resolution, we should make sure all
top level gems are considered, and only exclude those gems themselves
(and not their dependencies) if their locked versions happen to not be
satisfied by an edited Gemfile.
https://github.com/rubygems/rubygems/commit/ed2f1b7b88
|
|
After having a second look at this deprecation, the explanation that
we're giving does not make a lot of sense. When working only with local
gems, Bundler will indeed generate a different lockfile depending on
the latest installed version of each gem is at `bundle install` time.
That's the same situation that happens with remote sources: Bundler will
generate a different lockfile depending on the latest version of each
gem available remotely.
So, I don't think "a consistent lockfile not getting generated" is a
good motivation for deprecating this.
Also, this deprecation brings additional challenges, since for example,
it should arguably not get printed when using `bundle install --local`?
The original problem when this deprecation was introduced was an
incorrect message about a missing gem having been yanked.
So, I think a better solution is to, as long as we give proper error
messages when things go wrong, let users do what's best for them and
undo the deprecation.
https://github.com/rubygems/rubygems/commit/17499cb83f
|
|
https://github.com/rubygems/rubygems/commit/d478ec403f
|
|
installation path with bad permissions
https://github.com/rubygems/rubygems/commit/07e7f0bf5e
|
|
It gives better errors.
https://github.com/rubygems/rubygems/commit/bedae080ef
|
|
https://github.com/rubygems/rubygems/commit/71fd896041
|
|
compatible requirements
https://github.com/rubygems/rubygems/commit/a8d14c1fc2
|
|
https://github.com/rubygems/rubygems/commit/edbb2e3475
|
|
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
|
|
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>
|
|
include the current platform
https://github.com/rubygems/rubygems/commit/afb7a6d754
|
|
https://github.com/rubygems/rubygems/commit/680bafac1a
|
|
truffleruby to cruby
https://github.com/rubygems/rubygems/commit/4f3d9fa3bf
|
