| 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
|
|
- Fix https://github.com/ruby/rubygems/pull/9188
- This message is a bit misleading because it always outputs one extra
specs, which is Bundler itself.
This is now fixed when the message is about to be output.
https://github.com/ruby/rubygems/commit/70b4e19506
|
|
- Fix https://github.com/ruby/rubygems/pull/9186
- ### Problem
Running `bundle pristine` in a Gemfile where there is many git gem
pointing to the same repository will result in a error
"Another git process seems to be running in this repository".
### Context
This error is a regression since https://github.com/ruby/rubygems/commit/a555fd6ccd17
where `bundle pristine` now runs in parallel which could lead
to running simultaneous git operations in the same repository.
### Solution
When Bundler pristine a git gem it does a `git reset --hard` without
specifying a path.
This means the whole repository will be reset. In this case, we can
leverage that by just pristining one gem per unique git sources.
This is also more efficient.
https://github.com/ruby/rubygems/commit/710ba514a8
|
|
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
|
|
RHEL-based systems
Add fallback to `require` when `require_relative` fails to load native
extensions. This addresses an issue on RHEL-based Linux distributions
where Ruby scripts and built native extension shared libraries are
installed in separate directories.
https://github.com/ruby/rubygems/commit/68599bd107
|
|
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
|
|
https://github.com/ruby/rubygems/commit/bb4d791cb4
|
|
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
|
|
|
|
https://github.com/ruby/rubygems/commit/64f92d2da0
|
|
https://github.com/ruby/rubygems/commit/f360af8e3b
|
|
This specifies the lockfile location. This allows for easy support
of different lockfiles per Ruby version or platform.
https://github.com/ruby/rubygems/commit/b54d65bc0a
Co-authored-by: Sutou Kouhei <kou@cozmixng.org>
Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>
|
|
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>
|
|
- With the logger change that is now threadsafe, such code no longer
behaves the same:
```ruby
Bundler.ui.silence do
Bundler.ui.level = 'info'
Bundler.ui.info("foo")
# This used to output something. Now it doesn't.
end
```
IMHO this is the right behaviour since we are in a silence block,
changing the level should have no effect. And fortunately it seems
that we only need to change this spec.
The call to `Bundler.ui.silence` is done in a `around` block
https://github.com/ruby/rubygems/blob/4a13684f07ebb1dea5501e3f826fab414f96bf47/bundler/spec/spec_helper.rb#L119
https://github.com/ruby/rubygems/commit/e716adb6c9
|
|
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/pull/8183)
* Add new gem templates
* Add `--ext=go` in `bundle gem`
* Add setup-go to .github/workflows/main.yml
* Embed go version in go.mod
* Use go in bundler CI
* Add example method to template
* Install Go in .circleci/config.yml
* Install Go in .gitlab-ci.yml
* Allow hard tabs in go template
* Run `rake update_manifest`
* Fix test
* Move go_gem to gemspec
Respect to 9b0ec80
* nits: :golf:
* includes valid module name in go.mod
* generate header file
* Run `go mod tidy` to create `go.sum`
* Check if `go.sum` is generated only when Go is installed
To avoid test failure in environments where Go is not installed
* Run CI
* Workaround for hung up
c.f. https://github.com/rubygems/rubygems/actions/runs/11639408044/job/32415545422
* Write man for --ext=go
* Re-generate man with `./bin/rake man:build`
* pinning :pushpin:
* Update with `./bin/rake man:build`
* nits: Extract to method
* nits: Use `sys_exec` instead of `system`
* Clean go module cache after test
Workaround following error
```
1) bundle gem gem naming with underscore --ext parameter set with go includes go_gem extension in extconf.rb
Failure/Error: FileUtils.rm_r(dir)
Errno::EACCES:
Permission denied @ apply2files - /home/runner/work/rubygems/rubygems/bundler/tmp/2.2/home/go/pkg/mod/gopkg.in/yaml.v3@v3.0.1/decode_test.go
# ./spec/support/helpers.rb:37:in `block in reset!'
# ./spec/support/helpers.rb:21:in `each'
# ./spec/support/helpers.rb:21:in `reset!'
# ./spec/spec_helper.rb:130:in `block (2 levels) in <top (required)>'
# /home/runner/work/rubygems/rubygems/lib/rubygems.rb:303:in `load'
# /home/runner/work/rubygems/rubygems/lib/rubygems.rb:303:in `activate_and_load_bin_path'
```
Files installed with `go get` have permissions set to 444
ref. https://github.com/golang/go/issues/35615
```
$ ls -l /home/runner/work/rubygems/rubygems/bundler/tmp/2.2/home/go/pkg/mod/gopkg.in/yaml.v3@v3.0.1/decode_test.go
-r--r--r-- 1 runner runner 42320 Nov 15 06:38 /home/runner/work/rubygems/rubygems/bundler/tmp/2.2/home/go/pkg/mod/gopkg.in/yaml.v3@v3.0.1/decode_test.go
```
So they cannot be deleted by `FileUtils.rm_r`.
Therefore, this is necessary to execute `go clean -modcache` separately from `FileUtils.rm_r` to circumvent it.
* Remove needless changes
ref. https://github.com/ruby/rubygems/pull/8183#discussion_r2532902051
* ci: setup-go is needless
* Don't run go command in `bundle gem`
ref. https://github.com/ruby/rubygems/pull/8183#discussion_r2532765470
* Revert unrelated date changes
---------
https://github.com/ruby/rubygems/commit/260d7d60b3
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
|
|
https://github.com/ruby/rubygems/commit/d604c1d1cb
|
|
https://github.com/ruby/rubygems/commit/210fa87f65
|
|
https://github.com/ruby/rubygems/commit/1dc669a0ab
|
|
https://github.com/ruby/rubygems/commit/d3baf4110e
|
|
Always build gems with RubyGems programmatically
https://github.com/ruby/rubygems/commit/5cc0c34e64
|
|
If we install uri-1.0.4 as default gems. The example may be failed with
version miss-match.
https://github.com/ruby/rubygems/commit/fd2dcb502b
|
|
https://github.com/ruby/rubygems/commit/c637007e91
|
|
- ### Problem
Running `bundle lock --add-checksums` doesn't add the checksum of
gems hosted on server that don't implement the compact index API.
This result in a lockfile which is unusable in production as
some checksums will be missing and Bundler raising an error.
Users can work around this problem by running:
`BUNDLE_LOCKFILE_CHECKSUMS=true bundle install --force`
But this means redownloading and installing all gems which isn't
great and slow on large apps.
### Context
Bundler uses the Compact Index API to get the checksum of gems,
but most private gem servers don't implement the compact index API
(such as cloudsmith or packagecloud). This results in a soft failure
on bundler side, and bundler leaving out blank checksum for those
gems.
### Solution
For gems that are hosted on private servers that don't send back
the checksum of the gem, I'd like to fallback to the
`bundle install` mechanism, which don't rely on an external API but
instead compute the checksum of the package installed on disk.
This patch goes through the spec that didn't return a checksum,
and compute one if the package exists on disk.
This solution makes the `bundle lock --add-checksums` command
actually usable in real world scenarios while keeping the
`bundle lock` command fast enough.
https://github.com/rubygems/rubygems/commit/8e9abb5472
|
|
https://github.com/rubygems/rubygems/commit/59b909fa74
|
|
https://github.com/rubygems/rubygems/commit/c43e35c3ea
|
|
https://github.com/rubygems/rubygems/commit/06508374aa
|
|
https://github.com/rubygems/rubygems/commit/9d70887185
|
|
https://github.com/rubygems/rubygems/commit/7b0da18764
|
|
https://github.com/rubygems/rubygems/commit/12753b3262
|
|
https://github.com/rubygems/rubygems/commit/edd6b1d335
Co-authored-by: David Rodríguez <2887858+deivid-rodriguez@users.noreply.github.com>
|
|
https://github.com/rubygems/rubygems/commit/0e553c4425
|
|
https://github.com/rubygems/rubygems/commit/04574ba59a
|
|
https://github.com/rubygems/rubygems/commit/fd2c54f371
|
|
without a value
https://github.com/rubygems/rubygems/commit/9f34bf6854
Co-authored-by: Martin Emde <martinemde@users.noreply.github.com>
|
|
https://github.com/rubygems/rubygems/commit/47c3dc19ee
Co-authored-by: Jonathan Barquero <jonbarlo@hotmail.com>
|
|
https://github.com/rubygems/rubygems/commit/3bbbf4a4e5
|
|
https://github.com/rubygems/rubygems/commit/444022cfd3
|
|
https://github.com/rubygems/rubygems/commit/8f9d6c54a1
|
|
If the CLI flags are used, we abort early as usual.
As per the settings, I decided to ignore them. We've been migrating them
automatically to the new name for a long time and we don't yet have a
standard way to deprecate and remove settings (we should probably use
the existing setting validators). So I think it's fine for now to do
what we normally do (ignore the setting).
https://github.com/rubygems/rubygems/commit/8311de6e69
|
|
https://github.com/rubygems/rubygems/commit/573ffad3ea
|
|
--deployment` during specs
https://github.com/rubygems/rubygems/commit/c903afbc3f
|
|
the same gem in Gemfile
https://github.com/rubygems/rubygems/commit/e47a9064be
|
|
--no-prune`
Since they are remembered flags, too.
I also restored a previous spec about `--frozen`, but didn't bother with
`--no-prune`.
https://github.com/rubygems/rubygems/commit/7802f016fc
|
|
previous patch
https://github.com/rubygems/rubygems/commit/fbb8340186
|
|
fixed
https://github.com/rubygems/rubygems/commit/4fc57c69b2
|
|
vendor/cache is empty
https://github.com/rubygems/rubygems/commit/36c5af9156
|
|
Limit the `before` block to set `frozen`, which is the context of the
spec, and change the implementation to only write the Gemfile once, with
a gem being removed from what's in the lockfile.
https://github.com/rubygems/rubygems/commit/4d0314ff37
|
|
https://github.com/rubygems/rubygems/commit/eaa51203ca
|
