| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
| |
The default cache path is `vendor/cache`, not `vendor/bundle`.
|
| |
|
|
|
|
|
| |
This is a bug fix, so it makes no sense to make it configurable. Also,
the fix is unlikely to cause problems other than maybe needing a fresh
`bundle install` on some edge cases. So, let's ship the fix and remove
the setting.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7127: Add git and branch options to `bundle add` r=deivid-rodriguez a=tokachev
Closes #6841 These changes will allow to add a gem with the git or branch options.
```
bundle add redis --git "https://github.com/redis/redis-rb" --branch "staging"
```
The result in Gemfile will be:
```
gem "redis", "~> 4.0", :git => "https://github.com/redis/redis-rb", :branch => "staging"
```
Co-authored-by: Baumgarten <baumgarten@localhost.localdomain>
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In my opinion, it's overkill to provide a setting for how little this
setting was doing. Both types of Gemfile are supported and work
regardless of this setting. The only difference this setting would make
is the warning message one would get when having _both_ types of
Gemfiles in the same project.
I changed things so that gems.rb is always looked up first, and the
warning message in case you have both always tells you to remove Gemfile
and Gemfile.lock.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The list command was still present (just aliased to `bundle show`), even
if the setting was set to false. So the setting was at least super
confusing if not just wrong.
It also led to misleading situations such as
```
$ bundle list --help
(...)
NAME
bundle-list - List all the gems in the bundle
SYNOPSIS
bundle list [--name-only] [--paths] [--without-group=GROUP] [--only-group=GROUP]
(...)
$ bundle list --only-group=development
Unknown switches '--only-group=development'
```
So, instead, I enable the new list command _always_ and remove the
`bundle list => bundle show` alias.
|
| |
|
|
| |
They are actually compatible.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6931: Add patch option in bundle config r=greysteil a=ankitkataria
### What was the end-user problem that led to this PR?
Issue #5994
### What was your diagnosis of the problem?
As mentioned by @indirect I added a `patch` option in the bundler config, which by default is false. If set to true, patch level update are preferred if no update levels are specified.
### What is your fix for the problem, implemented in this PR?
A patch level config option which can be opted into.
Co-authored-by: Ankit Kataria <ankitkataria28@gmail.com>
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6751: Fix BUNDLE_PATH_RELATIVE_TO_CWD env variable name r=greysteil a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that an environment variable in the docs does not work.
### What was your diagnosis of the problem?
My diagnosis was that its name is incorrect.
### What is your fix for the problem, implemented in this PR?
My fix is to fix the typo.
### Why did you choose this fix out of the possible options?
I chose this fix because it's the only non absurd fix.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
| |
Bundler
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add `bundle remove`
Features of the command implemented:
- Multiple gems support
```bash
$ bundle remove rack rails
```
- Remove any empty block that might occur after removing the gem or otherwise present
Things yet to implement:
- Add `rm` alias. _Optional_
- [x] Add `--install` flag to remove gems from `.bundle`.
- [x] Handling multiple gems on the same line.
- [x] Handle gem spec
- [x] Handle eval_gemfile cases ([one](https://github.com/bundler/bundler/pull/6513#discussion_r195632603) case left)
Closes #6506
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Document that `bundle show [--paths]` sorts results
### What was the end-user problem that led to this PR?
The problem was that I could not tell from the manpage or documentation website whether `bundle show` and `bundle show --paths` would list gems and gem paths in the same order.
I am using `bundle show` and `bundle show --paths` to inventory gems that projects depend upon.
### What was your diagnosis of the problem?
My diagnosis was that the implementation of `bundle show` _does_ sort results by name, but that the manpage for the subcommand doesn't mention this.
### What is your fix for the problem, implemented in this PR?
My fix involved slightly editing the existing manpage for `bundle show`.
### Why did you choose this fix out of the possible options?
I chose this fix because the `.ronn` file text matched the current text I was seeing via the documentation website.
|
| | |/ |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
add warning to docs for explicit source gotcha
See https://github.com/bundler/bundler/issues/6280 for more context.
This PR adds a warning to the Gemfile documentation to more clearly indicate that specifying an explicit source on a per-gem or block basis also makes that scoped source a global source. Also adds a recommendation that users ensure that all gems in the Gemfile are using explicit sources whenever they introduce any explicit source blocks or source directives on individual gems.
If the root cause cannot be fixed until v2, I think this gotcha should be documented in all existing bundler versions which have this behavior, which as far as I can tell is all versions supporting explicit sources via blocks/per-gem directives. I believe it merits a warning because the behavior is non-intuitive, and represents a potential security issue if it is not understood and avoided. I don't know how backporting for documentation is performed, so I'm making this PR against master for now. Please let me know if I need to do anything else.
### What was the end-user problem that led to this PR?
Unclear behavior when mixing global sources with source blocks, as outlined in https://github.com/bundler/bundler/issues/6280 . No documentation was present that described this behavior.
### What was your diagnosis of the problem?
Having docs would have been helpful!
### What is your fix for the problem, implemented in this PR?
Add documentation
### Why did you choose this fix out of the possible options?
It was suggested that I make a PR to add documentation here: https://github.com/bundler/bundler/issues/6280#issuecomment-400535496
## To Reproduce
```ruby
source 'https://code.stripe.com/'
source 'https://rubygems.org' do
gem 'fattr'
end
gem 'mime-types'
```
results in this warning on v1.16.2, telling me that it preferred https://rubygems.org for the `mime-types` gem, which is counterintuitive when looking at the Gemfile.
```
Warning: the gem 'mime-types' was found in multiple sources.
Installed from: https://rubygems.org/
Also found in:
* https://code.stripe.com/
You should add a source requirement to restrict this gem to your preferred source.
For example:
gem 'mime-types', :source => 'https://rubygems.org/'
Then uninstall the gem 'mime-types' (or delete all bundled gems) and then install again.
```
Here is a Dockerfile that reproduces the issue when built, for source blocks:
```Dockerfile
FROM ruby:2.5.1-alpine
WORKDIR /test
RUN echo $'\n\
source "https://code.stripe.com/" \n\
source "https://rubygems.org" do \n\
gem "fattr" \n\
end \n\
gem "mime-types" \n\
' >> ./Gemfile
RUN bundle install --verbose
# the source ambiguity warning doesn't show up on the initial install for some reason
RUN rm -rf /usr/local/bundle/**/*
RUN bundle install
RUN cat Gemfile
```
Here is another Dockerfile that reproduces the issue when built, for a source directive on an individual `gem` function call:
```Dockerfile
FROM ruby:2.5.1-alpine
WORKDIR /test
RUN echo $'\n\
source "https://code.stripe.com/" \n\
gem "fattr", source: "https://rubygems.org" \n\
gem "mime-types" \n\
' >> ./Gemfile
RUN bundle install --verbose
# the source ambiguity warning doesn't show up on the initial install for some reason
RUN rm -rf /usr/local/bundle/**/*
RUN bundle install
RUN cat Gemfile
```
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit adds a warning to the Gemfile documentation to more clearly
indicate that specifying an explicit source on a per-gem or block basis
also makes that scoped source a global source. Also adds a
recommendation that users ensure that all gems in the Gemfile are using
explicit sources whenever they introduce any explicit source blocks or
source directives on individual gems.
|
| | |
| |
| |
| | |
Improves understanding of the options without need to look up the docs.
|
| |/ |
|
| |\
| |
| |
| |
| |
| | |
Add option to filter gem-dependencies from output of 'bundle outdated'
Resolves #5366 by adding a new option '--filter-dependencies' to `bundle outdated`. When present, `outdated` will only check the `gemfile_specs` and skip the `dependency_specs`.
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[bundle add] Add version prefix flexibility
### What was the end-user problem that led to this PR?
By default, on `bundle add` we use "pessimistic" way (~>) of versions. According to this [comment](https://github.com/bundler/bundler/issues/6553#issue-326023952) some users face problems.
### What was your diagnosis of the problem?
Adding flags to provide flexibility to change this declaration namely `optimistic` and `strict`
### What is your fix for the problem, implemented in this PR?
Adding flags to opt for other declarations.
### Why did you choose this fix out of the possible options?
Currently, its an experiment and I have added it to only `bundle add` but still the version locked in lockfile are "pessimistic". Need suggestions on this and on how to proceed.
Addresses #6553
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix man page links
With a markup
[`bundle platform(1)`][bundle-platform(1)]
ronn creates this HTML fragment
<a href="bundle-platform.html"><code>bundle platform(1)</code></a>
At the same time, it generates HTML file `bundle-platform.1.html` based on the
man page section, and this results in certain inter-man-page links 404.
We resolve this inconsistency by spelling out the href attributes.
-----
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
404's on https://bundler.io.
For example, https://bundler.io/v1.16/man/bundle.1.html has the link to `bundle platform(1)`:
<img width="1061" alt="bundler__bundle" src="https://user-images.githubusercontent.com/25666/40212893-7fc73196-5a20-11e8-8964-5ca5ed9abfa2.png">
This points to https://bundler.io/v1.16/man/bundle-platform.html, but it is 404. The correct link is https://bundler.io/v1.16/man/bundle-platform.1.html.
### What was your diagnosis of the problem?
My diagnosis was...
that the document source was wrong.
### What is your fix for the problem, implemented in this PR?
My fix...
is this PR.
### Why did you choose this fix out of the possible options?
I chose this fix because...
`ronn -5 man/*.ronn` appears to generate `<a>` tags with the correct `href` attributes.
I tried serving the generated files with `bundler-site`, but I could not convince it to do so; `bundler-site`'s Rake tasks assumes the document source *always* comes from the remote `bundler/bundler`, and coming up with a way to test it seemed rather involved.
|
| | | | |
|
| | | | |
|
