| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7416: Don't use insecure temporary directory as home directory r=deivid-rodriguez a=fatkodima
Closes #6501
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
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7401: Stop silencing output by default r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that bundler defaults to a silent UI:
https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler.rb#L66-L68
In my opinion, this isn't a good behavior for a CLI tool, and forces us to override it in many many different places. It has also caused several issues, for example, https://github.com/bundler/bundler/issues/3710 where `bundle list` was printing nothing.
The [solution to that issues](https://github.com/bundler/bundler/pull/3707) led us to add yet more places where we override the default UI, and @indirect [predicting that having to unset the UI everytime we want it to not be silent](https://github.com/bundler/bundler/pull/3707#issuecomment-108646127) would cause many headaches.
Well, yeah... I've lost a lot of time trying to figure out why UI was silent sometimes, and normal another times, why some specs printed warnings and some didn't. In particular, see my series of "big fail PRs" fighting against bundler's UI: https://github.com/bundler/bundler/pull/7284, https://github.com/bundler/bundler/pull/7294, https://github.com/bundler/bundler/pull/7305, https://github.com/bundler/bundler/pull/7362.
Another series of issues/PRs probably related to this is issue https://github.com/bundler/bundler/issues/6900, where the output would use a different UI on different environments. We had a lot of trouble to reliably fix it (https://github.com/bundler/bundler/pull/6994, https://github.com/bundler/bundler/pull/7002, https://github.com/bundler/bundler/issues/7253).
I also run into these issues again when trying out the `RUBYGEMS_GEMDEPS` environment variable that enables `bundler/setup` from rubygems.
### What was your diagnosis of the problem?
My diagnosis was that we shouldn't silence UI by default.
### What is your fix for the problem, implemented in this PR?
My fix is to, instead of silencing and then overriding the default shell at many places, don't silence it by default and instead make it silent when needed. By doing this, I managed to get 100% of our specs green, so I'm pretty confident that the output is still the same (or if it's not, it's probably because some output/errors where being unintentionally swallowed).
Now specs should pass, but they print a bunch of output to the screen. You can see error messages, hard crashes, success messages... Some of them might be showing actual issues with either the code or tests, so I plan to go through each of them and review them. I can do that in this PR or separately, no strong opinion.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | | | |
|
| | | | |
|