| Age | Commit message (Collapse) | Author |
|---|
|
And make it consistent with platform additions.
https://github.com/rubygems/rubygems/commit/64342ae404
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
Due to a typo in the spec, the issue was not caught initially. If
Bundler does not need to re-resolve, `bundle lock` is a noop so Bundler
does not add checksums.
To fix the issue, we do something similar to what `bundle install` does,
just without actually installation. First set the domain (local or
remote) according to whether a re-resolve is necessary, and then
materialize lazy specifications into real specifications, so that
checksums are actually fetched from each source.
https://github.com/rubygems/rubygems/commit/84b6f4ee96
|
|
All we need is to setup remote or local sources appropriately.
https://github.com/rubygems/rubygems/commit/3ceff46a2a
|
|
existing lockfile
https://github.com/rubygems/rubygems/commit/0a9c1ce60d
|
|
|
|
--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/6a0c03c77f
|
|
https://github.com/rubygems/rubygems/commit/2720da2659
|
|
https://github.com/rubygems/rubygems/commit/fd2e71dfdb
|
|
https://github.com/rubygems/rubygems/commit/bb66253f2c
|
|
The `lock` command is specifically designed to manage the lockfile, so
running it should take precedence over any "frozen" setting.
Besides that, "frozen" is not specifically designed as "lockfile cannot
be updated" but as "installation of gems should be prevented if gemfile
is not in sync with the lockfile".
The lock command does not install any gems and preserves the property of
the lockfile being in sycn with its gemfile, so I think frozen should
not influence it.
The current behavior is quite confusing when frozen is set. On an app
where rubocop can get lockfile updates
```
$ bundle lock --update rubocop
Writing lockfile to /path/to/Gemfile.lock
```
Completely silent, it makes you think that it has written the lockfile,
but still no updates.
In verbose mode, it gives a bit more information, but still confusing
and unexpected, and does not change the lockfile:
```
$ bundle lock --update rubocop --verbose
Running `bundle lock --update "rubocop" --verbose` with bundler 2.4.20
Frozen, using resolution from the lockfile
Writing lockfile to /path/to/Gemfile.lock
```
With this commit, it updates the lockfile as expected.
https://github.com/rubygems/rubygems/commit/1d501ae8ea
|
|
https://github.com/rubygems/rubygems/commit/bc233af4d2
|
|
bundle lock --update can do everything that bundle update can do, but
it doesn't actually install gems. This is especially useful for
generating a lockfile on a machine that doesn't have the libraries
available to be able to build native extensions.
But, there was no parallel for bundle update --bundler. So let's add
one.
https://github.com/rubygems/rubygems/commit/7fc00bd2a5
|
|
https://github.com/rubygems/rubygems/pull/5960
Co-authored-by: David Rodríguez <[email protected]>
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/4533
|
|
* 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
|
|
* lib/bundler, spec/bundler: Merge bundler-1.16.0.
* common.mk: rspec examples of bundler-1.16.0 needs require option.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60603 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
|
