| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| | | | |
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With markup
[`bundle platform(1)`][bundle-platform(1)]
ronn creates this HTML fragment
<dt><a href="bundle-platform.html"><code>bundle platform(1)</code></a></dt><dd><p>Display platform compatibility information</p></dd>
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.
|
| |/ |
|
| | |
|
| |
|
| |
Parsed out the information in the first graph in order to help users understand the order of priority Bundler follows when loading config settings.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Document `# frozen_string_literal` in `bundle init` Gemfile
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?
An enhancement request to bundle-init docu as per - issue 6140
### What was your diagnosis of the problem?
n/a
### What is your fix for the problem, implemented in this PR?
Updated the man/bundle-init.ronn file to include brief description of frozen string literal, and added a SEE ALSO section with link to Gemfile(5) webpage
### Why did you choose this fix out of the possible options?
File edited to try and reflect the previous discussion regarding what was required.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Update docs to reflect revised guidance to check in locks for gems
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?
The problem was...
- Bundler stopped gitignoring gem locks. The change was merged in but we need to reflect that change in documentation.
### What was your diagnosis of the problem?
My diagnosis was...
- To add in documentation explaining why Bunder now does _not_ gitignore gem locks.
### What is your fix for the problem, implemented in this PR?
My fix...
- Update the `gemfile.lock` section of `bundle install` man pages as well as the `gemfile` man page.
### Why did you choose this fix out of the possible options?
I chose this fix because...
- This addresses open issue https://github.com/bundler/bundler/issues/5879
|
| | |
| |
| |
| |
| |
| | |
After reviewing, I think the question and answer is a bad fit for the
`gemfile` man page. It does seem like a good fit for the FAQ page on the
Bundler documentation site, though, and I'll add it over there.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Addresses https://github.com/bundler/bundler/issues/6243
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
[man] fix typo on bundle-binstubs
Typo found while i was packaging 1.16.1 for Debian
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
[Man] Audit links to other manpages
### What was the end-user problem that led to this PR?
The problem was links to many of our man pages were broken.
Closes https://github.com/bundler/bundler-site/issues/355.
### What was your diagnosis of the problem?
My diagnosis was we were omitting the section in the link ID.
### What is your fix for the problem, implemented in this PR?
My fix manually updates the link IDs to be correct.
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
add `--paths` option to `bundle list` command.
See #6172
This option mimics the `--paths` options in `bundle show` which is
being removed in Bundler 2.
Example Usage:
```
$ bundle list --paths
/Users/c/Desktop/Projects/testapp/.bundle/ruby/2.4.0/gems/actioncable-5.1.4
/Users/c/Desktop/Projects/testapp/.bundle/ruby/2.4.0/gems/actionmailer-5.1.4
/Users/c/Desktop/Projects/testapp/.bundle/ruby/2.4.0/gems/actionpack-5.1.4
/Users/c/Desktop/Projects/testapp/.bundle/ruby/2.4.0/gems/actionview-5.1.4
```
|
