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.
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.
17499cb83f
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.
2f3cd8ac4e
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.
607a3bf479
Co-authored-by: Gourav Khunger <gouravkhunger18@gmail.com>
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.
e3ec32e247
If one upgrades the default copy of Bundler through `gem update
--system`, and then reinstalls Ruby without removing the previous copy.
Then the new installation will have a correct default bundler gemspec,
but a higher copy installed in site_dir.
This causes a crash when running Bundler and prints the bug report
template.
This could probably be fixed in Ruby install script, by removing any
previous Bundler default copies, but if the problem is already there, I
think it's best to print a proper user error.
ada6de765d
So generate_index can be implemented with dependencies, such as the compact index
Took this approach from feedback in https://github.com/rubygems/rubygems/pull/6853
Running `gem generate_index` by default will use an installed rubygems-generate_index, or install and then use the command from the gem
Apply suggestions from code review
fc1cb9bc9e
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
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.
2353cc93a4
If a Gemfile duplicates a development dependency also defined in a local
gemspec with a different requirement, the requirement in the local
gemspec will be silently ignored.
This surprised me.
I think we should either:
* Make sure both requirements are considered, like it happens for
runtime dependencies (I added a spec to illustrate the current behavior
here).
* Add a warning that the requirement in the gemspec will be ignored.
I think the former is slightly preferable, but it may cause some
bundle's that previously resolve to no longer resolver.
I went with the latter but the more I think about it, the more this
seems like it should behave like the former.
ad6843972f
Instead, don't check that at all and proceed. If something fails to be
written inside GEM_HOME, we'll eventually fail with a proper permissions
error.
In addition to that, the writable bit in GEM_HOME is not even reliable,
because only the immediate parent is actually checked when writing. For
example,
```
$ mkdir -p foo/bar
$ chmod -w foo
$ touch foo/bar/baz # writes without issue
```
4bced7ac73
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.
bde37ca6bf
If BUNDLE_PATH is configured to a symlinked path, installing gems with
symlinks would crash with an error like this:
```
Gem::Package::SymlinkError: installing symlink 'man/man0/README.markdown' pointing to parent path /usr/home/stevewi/srv/mail/lib/tools/.vendor/ruby/3.1.0/gems/binman-5.1.0/README.markdown of /srv/mail/lib/tools/.vendor/ruby/3.1.0/gems/binman-5.1.0 is not allowed
```
This commit fixes the problem by changing the bundle path to be the
realpath of the configured value, right after we're sure the path has
been created.
3cd3dd142a
Instead of guessing on the culprit.
We actually have a helper, `Bundler.rm_rf`, with exactly the behavior
that we want:
* Allow the passed folder to not exist.
* No exception swallowing other than that.
5fa3e6f04a
When I run bundle install with BUNDLE_DEPLOYMENT=true in the environment
on a different platform than I usually do development, I get the
following output to the console (wrapped exactly as shown):
Your bundle only supports platforms ["x86_64-darwin-19"] but your local platform
is x86_64-linux. Add the current platform to the lockfile with `bundle lock
--add-platform x86_64-linux` and try again.
Because the way the message wraps, its not as simple as copying the
suggested command to the clipboard because it contains a newline:
$ bundle lock
Writing lockfile to [...]/Gemfile.lock
$ --add-platform x86_64-linux
Adding a newline right before the command forces the command in the
error message to be on the same line, which facilitates copy-pasting the
command in the message.
4cf6989b11
