Since we no longer have multiple global sources, each top level dependency is
always pinned to a single source, so it makes little sense to talk about
adding or removing a source. Instead, source changes always mean to
change the source one or more dependencies are pinned to. This logic can
now be much simpler.
https://github.com/rubygems/rubygems/commit/f1d33fa0df
Calling `Bundler.definition.specs` will memoize materialized specs.
However, requiring `bundler/setup` will end up materializing the same
set of specs, but not memoize them.
This change makes things consistent.
https://github.com/rubygems/rubygems/commit/e4c2b52824
In case we have a corrupted lockfile that claims to support a platform, but
it's missing platform specific gems for it, bundler has a check that
detects the situation and forces a re-resolve. The result of this check
is kept under the `@locked_specs_incomplete_for_platformn` instance
variable in `Definition`.
The installer, however, calls `Definition#nothing_changed?` before this
instance variable has been filled, so the result of it is actually
incorrect here since it will claim that nothing has changed, but
something has changed (locked specs are incomplete for the current
platform).
The consequence of this incorrect result is that the installer thinks it
can go on without re-resolving, resulting in the incomplete resolution
from the lockfile being used, and in a crash being triggered due to
that.
The solution is to make sure the `@locked_specs_incomplete_for_platform`
instance variable is filled before `nothing_changed?` gets called.
Moving it to `initialize` makes the most sense, not because it's the
best place for it (we can refactor this later), but because all of the
other "outdated definition" checks are already set there.
https://github.com/rubygems/rubygems/commit/708afdd789
As part of a recent bug fix where bundler was accidentally hitting the
network when not supposed to, I made some refactoring, and the commit I'm
reverting here
(d74830d00b)
was some cleanup that those refactorings allowed according to "past me".
That was completely wrong, `bundle check` should never consider cached
gems, only installed gems, so the code that was removed was necessary.
https://github.com/rubygems/rubygems/commit/5483e98305
Bundler has deprecated gemfiles without a global source and this feature
is now obsolete. `Bundler::Definition#has_rubygems_remotes?` is removed
because it's not used anymore.
https://github.com/rubygems/rubygems/commit/d29dd2cb7b
The `only_update_to_newer_versions` feature flag will enable some new
behaviour in bundler 3 (or maybe earlier if we decide to consider it a
bug fix) that prevents `bundle update` from unexpectedly downgrading
direct dependencies.
This seems reasonable, but the current implementation is adding
additional requirements for all locked dependencies, not only from the
ones in the `Gemfile`. That causes some situations where the `Gemfile`
is edited and will resolve to older versions to start failing.
This commit fixes the problem by making sure extra requirements are
added exclusively for direct dependencies in the `Gemfile`, not for all
direct dependencies in the lock file.
https://github.com/rubygems/rubygems/commit/128b4596e1
7340: Fix bundle clean issue r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that `bundle clean` is crashing under some conditions.
### What was your diagnosis of the problem?
My diagnosis was that sometimes (when the bundle includes git sourced gems with extensions), it assumes that some paths exist, but they don't.
### What is your fix for the problem, implemented in this PR?
My fix is to ignore those paths.
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the issue.
Fixes#7338.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit b007fde67c77c1f15f13b97eda186644c2a2be04)
https://github.com/bundler/bundler/commit/3766053507
* bin/*, lib/bundler/*, lib/bundler.rb, spec/bundler, man/*:
Merge from latest stable branch of bundler/bundler repository and
added workaround patches. I will backport them into upstream.
* common.mk, defs/gmake.mk: Added `test-bundler` task for test suite
of bundler.
* tool/sync_default_gems.rb: Added sync task for bundler.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65509 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I faced a big issue about Bundler with ruby core.
I have no time to resolve it issue before 2.5 final release.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61416 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It's rc version for bundler-1.16.1. I'm going to update it version
after official release from bundler team.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61134 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
rubygems 2.7.x depends bundler-1.15.x. This is preparation for
rubygems and bundler migration.
* lib/bundler.rb, lib/bundler/*: files of bundler-1.15.4
* spec/bundler/*: rspec examples of bundler-1.15.4. I applied patches.
* https://github.com/bundler/bundler/pull/6007
* Exclude not working examples on ruby repository.
* Fake ruby interpriter instead of installed ruby.
* Makefile.in: Added test task named `test-bundler`. This task is only
working macOS/linux yet. I'm going to support Windows environment later.
* tool/sync_default_gems.rb: Added sync task for bundler.
[Feature #12733][ruby-core:77172]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59779 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Hiroshi SHIBATA
David Rodríguez
Daniel Niknam
Bundlerbot
Samuel Giddins
hsbt