| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Some setups have `--disable=gems` in `RUBYOPT`, and sometimes use
`bundler` without modifying that env. Let's not break those setups just
to save a `require`.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7498: Add compatibility methods for `rubygems-bundler` gem r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that `bundler install` on a `ruby` installation using `rvm` is broken by default.
### What was your diagnosis of the problem?
My diagnosis was that during 2.1.0 development phase I removed some stuff I thought it was internal and nobody would be using.
### What is your fix for the problem, implemented in this PR?
My fix is to restore a minimal compatibility layer so that this stuff works again.
### Why did you choose this fix out of the possible options?
I chose this fix because I think this is the minimum set of additions that gets stuff working again.
Fixes #7488.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |
| |
| |
| |
| | |
Hopefully `rvm` won't install this gem by default, but for now
I'm adding the following two methods for compatibility with it.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We might be shelling out to rubygems in a `bundle exec` context. In the
case where we don't shell out to the `gem` binstub directly, the
previous trick wouldn't work.
Instead, reset the rubygems ui right after `bundler/setup`, so that if
we end up shelling out to rubygems, it will use its default shell
(non-silent).
The best place to fix this would probably be right inside the `gem`
script, but even if we fix it there, we'll need workarounds for previous
rubygems versions inside `bundler` so I think this is good for now.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7460: Vendor `uri` library r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that after the gemification of the `uri` library (which will happen in ruby 2.7), `bundler` will activate the default version of the new library inside its own `bundler/setup` code. That means users won't be able to specify the version of the library they want/need to use in their own Gemfiles.
### What was your diagnosis of the problem?
My diagnosis was that we should avoid using `uri` inside `bundler/setup` code.
### What is your fix for the problem, implemented in this PR?
My fix is to vendor the `uri` library, like we did with `fileutils`.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
|
| |
| |
| |
| |
| | |
We vendorize it as a dependency of `net-http-persistent`, so usages
inside `net-http-persistent` get automatically replaced by `automatiek`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These gem task checks for a specific string in the gem subcommand
output. However, if we are inside a bundled environment (`bundle exec
rake install` instead of `rake install`), the ruby process will require
`bundler/setup` first thing, and initialize a silent UI for rubygems. As
a result, the output string will be always empty and the condition for
success will always fail. So, even if installation succeeded, user will
always be notified of a failure like:
```
foo 1.0 built to pkg/foo-1.0.gem.
rake aborted!
Couldn't install gem, run `gem install /home/deivid/Code/bundler/tmp/1/bundled_app/pkg/foo-1.0.gem' for more detailed output
...
```
So, don't check for a specific string in the output and only rely on the
exit status.
|
| |
| |
| |
| | |
And use it consistently.
|
|/
|
|
| |
Like it is named in the other analogous methods.
|
| |
|
|
|
|
|
|
|
| |
I think the comment is misleading and it referred to rubygems, not
gemstash, because this code is about the client side of things. If this
is correct, we can drop it because we don't support any rubygems version
under 2.5.2, and the fix was introduced in rubygems 2.5.
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7418: Restore previous BUNDLE_GEMFILE in bundler/inline r=deivid-rodriguez a=fatkodima
[Without spacing changes](https://github.com/bundler/bundler/pull/7418/files?w=1)
Closes #7159
Co-authored-by: fatkodima <fatkodima123@gmail.com>
|
| | |
|
| |
| |
| |
| |
| | |
Since cgi is now a default gem on ruby 2.7, we're getting some
unintended activations of the new default gem inside our specs.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7455: Lazily load `open3` r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was `open3` will be gemified in ruby 2.7, and since we use it inside `bundler`, we might activate a version causing a conflict with the user's choice.
### What was your diagnosis of the problem?
My diagnosis was that only loading it when needed should be better.
### What is your fix for the problem, implemented in this PR?
My fix is to lazily load it.
I expect this PR to fix [some of the errors](https://travis-ci.org/bundler/bundler/jobs/615940817) currently happening in our CI against ruby-head.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/
| |
| |
| |
| | |
Since it's a default gem now, it's better to load it as late as
possible.
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7442: Fix `bundle exec`'ing to rubygems being silent r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that #7401 caused a regression where `bundle exec`'ing to rubygems would silence rubygems output.
### What was your diagnosis of the problem?
My diagnosis was that the removal of:
* Code where `Bundler::RGProxy` would be only set conditionally on `Bundler.ui =` not being passed `nil`.
* Code setting `Bundler.ui` to `nil` right before shelling during `bundle exec`.
caused rubygems UI to be silent during `bundle exec gem`.
### What is your fix for the problem, implemented in this PR?
My fix is to explictly "unsilence" rubygems UI before `bundle exec` calls.
### Why did you choose this fix out of the possible options?
I chose this fix because it's more explicit than the previous one.
Fixes #7441.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
|
|/ |
|
|
|
|
|
|
| |
Using `bin/rake vendor:thor[master]`.
So that we're ready for an upcoming release.
|
|
|
|
|
| |
I think this comes from times where our vendored `Thor` was not
namespaced and we were doing this to avoid conflicts.
|
|\
| |
| |
| |
| |
| |
| |
| | |
7423: Ignore local overrides for bundle pristine r=deivid-rodriguez a=fatkodima
Closes #6836
Co-authored-by: fatkodima <fatkodima123@gmail.com>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6455: [CLI::Gem] Add a --rubocop option r=deivid-rodriguez a=segiddins
Based upon #6451.
### What was the end-user problem that led to this PR?
The problem was I always have to remember how to add RuboCop to my Rakefile when I set up a new gem.
### What was your diagnosis of the problem?
My diagnosis was that RuboCop has become enough of a community standard that it makes sense to offer it in `bundle gem`.
### What is your fix for the problem, implemented in this PR?
My fix adds an option to `bundle gem` to add in RuboCop, in the same way options like `:coc`and `:mit` are handled.
### Why did you choose this fix out of the possible options?
I chose this fix because it does not require bundler have an opinion on _how_ rubocop is configured.
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7417: Fix bundler/inline warning: method redefined; discarding old root r=deivid-rodriguez a=fatkodima
Closes #6167
Co-authored-by: fatkodima <fatkodima123@gmail.com>
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7424: Drop unnecessary `tempfile` require r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The `tempfile` dependency was dropped in [1], but the require was left in there. This could cause gem conflicts because `tempfile` requires `tmpdir` which requires `fileutils`, which loads the default gem instead of our namespaced version, and that could cause fileutils version mismatches and code overriding warnings.
[1]: https://github.com/bundler/bundler/commit/4a37d66f3f222739178d798b30fb135f2429fe45
### What is your fix for the problem, implemented in this PR?
My fix is to drop the unnecessary require.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The `tempfile` dependency was dropped in [1], but the require was left
in there. This could cause gem conflicts because `tempfile` requires
`tmpdir` which requires `fileutils`, which loads the default gem instead
of our namespaced version, and that could cause fileutils version
mismatches and code overriding warnings.
[1]: https://github.com/bundler/bundler/commit/4a37d66f3f222739178d798b30fb135f2429fe45
|
|\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7393: Make 'bundle add' cache newly added gems when needed r=deivid-rodriguez a=andrehjr
### What was the end-user problem that led to this PR?
The problem was that when calling `bundle add` with cache_all as true, I have to call an additional `bundle install` to vendor gems.
### What was your diagnosis of the problem?
My diagnosis was that a call to Bundler.load.cache was missing. For example Bundler::CLI::Update does the same after installing gems.
### What is your fix for the problem, implemented in this PR?
My fix was to call Bundler.load.cache when `Bundler.app_cache.exist? `
### Why did you choose this fix out of the possible options?
I chose this fix because it looks like this makes the behavior consistent with other commands.
I should also say that, as this is my first PR here, I'm not sure that this is the best solution, and it seems an easy fix for #7384.
Co-authored-by: André Luis Leal Cardoso Junior <andrehjr@gmail.com>
|
| | | | | |
|
|\ \ \ \ \
| |_|_|_|/
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7394: Add inline RDoc documentation r=hsbt a=zverok
Since Bundler became part of the standard library, it renders in Ruby's docs. Unfortunately, what renders there... is not really helpful: https://docs.ruby-lang.org/en/master/Bundler.html
I've added rudimentary documentation for `Bundler` module and two of its most user-facing methods to solve this problem at least partially.
Co-authored-by: zverok <zverok.offline@gmail.com>
|
| |/ / / |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Bundler no longer needs to be in the `$LOAD_PATH` once a version of
itself has been loaded.
In any case, the `Metadata` source takes care of adding `bundler` to the
index:
https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/source/metadata.rb#L13-L30
and then that spec is added to the resolution here:
https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/definition.rb#L180-L184
And from the resulting set of specs, the `$LOAD_PATH` is setup:
https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/runtime.rb#L25-L38
So `bundler` will be present in the `$LOAD_PATH` anyways, and the lines
being removed here will never be useful.
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7404: Support multiple groups for --without-group and --only-group options … r=deivid-rodriguez a=fatkodima
This is a reworked version of #6939
It accepts multiple groups for `--without-group` and `--only-group`.
Closes #6939
Co-authored-by: fatkodima <fatkodima123@gmail.com>
|
| | |/ /
| |/| |
| | | |
| | | | |
bundler list command
|