| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
The only existing spec coverage was essentially integration level and
there was no way either @lucasmazza or myself could find a way to
simulate the bug context.
I extracted some of the code out of outdated into Definition and
SpecSet and added unit specs to those extracted bits.
Closes: #5171
Approved by: <try>
|
| |
|
|
|
| |
Closes: #5171
Approved by: <try>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Support :mri_24 platform
Current ruby trunk is versioned as "2.4.0".
% ruby -ve 'p RUBY_VERSION'
ruby 2.4.0dev (2016-11-15 trunk 56792) [x86_64-darwin15]
"2.4.0"
We'd like to run tests on some gems against ruby-trunk or 2.4 pre-releases, so here's a support for MRI 2.4.
(This is Ruby 2.4 version of #3865)
|
| |/ |
|
| |\
| |
| |
| | |
Ensure that the local platforms are set for the specs in Ruby 2.4
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| | |
Update vendored Molinillo to 0.5.4
See https://github.com/CocoaPods/Molinillo/releases/0.5.4
|
| |/ |
|
| |\
| |
| |
| |
| |
| | |
[Rakefile] Pin CodeClimate reporter to pre-1.0
Should fix our current CI failures
|
| |/ |
|
| |\
| |
| |
| |
| |
| | |
Add Ruby Together CTA
/c @indirect
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Move man pages to man folder
The [gem-man](https://github.com/defunkt/gem-man) gem searches for the man pages in the man folder. Sadly bundler right now uses `lib/bundler/man` for the man pages.
This pr fixes this and also creates correct names for the man pages. A man page always needs the section number in the filename.
After this is merged, I will create a PR that changes the [bundler-site](https://github.com/bundler/bundler-site) repo to search in this new folder for the documentation.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The gem-man gem searches for the man pages in the man folder.
This pr fixes this and also creates correct names for the manpages. A manpage always needs the section number in the filename.
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | | |
[LockfileParser] Stop requiring strscan
Introduced and seemingly never used by https://github.com/bundler/bundler/commit/ba579f4a3e525fdd78d89531291450b26a009b07
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
change license specification in gemspec
for compatibility with license_finder gem, allowing automatic license checks.
Bundler already proposes the same format in it's newgem.gemspec template:
https://github.com/bundler/bundler/blob/master/lib/bundler/templates/newgem/newgem.gemspec.tt#L16
Let use it for bundler itself too.
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
for compatibility with license_finder gem, allowing automatic license checks.
Bundler already proposes the same format in it's newgem.gemspec template:
https://github.com/bundler/bundler/blob/master/lib/bundler/templates/newgem/newgem.gemspec.tt#L16
Let use it for bundler itself too.
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
[WIP] New patch level and conservative options documented.
Fixes #4775.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Fixes #4775.
|
| | | |
| | |
| | |
| | |
| | | |
I should have cleaned these up in a prior PR, but no time like the
present.
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | | |
Warn if executable in bundle exec is empty
closes https://github.com/bundler/bundler/issues/5084
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Update vendored Molinillo to 0.5.3
See https://github.com/CocoaPods/Molinillo/releases/0.5.3
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
use Bundler.which to check for otool and ldd
Hi, there is some weird behaviour in `bundler doctor`. Bundler is checking for the existence of the `ldd` and `otool` commands but is not correctly redirecting the output of `otool`. Example being on the latest version of bundler:
```
› bundle doctor
llvm-otool(1): Apple Inc. version cctools-895
llvm-otool(1): Apple Inc. version cctools-895
llvm-otool(1): Apple Inc. version cctools-895
llvm-otool(1): Apple Inc. version cctools-895
llvm-otool(1): Apple Inc. version cctools-895
llvm-otool(1): Apple Inc. version cctools-895
```
This is happening on Mac OS (10.12). I have refactored the check of these tool using the built in `command` function, this lets us check for the existence of these commands without actually having to execute them.
Thanks.
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
add missing highlights to bundler's bundle man page
Hi, I noticed on the main man page for bundler that some of the listed categories where not being formatted correctly with the rest of the document. This change adds some backticks to add the highlights. The before image is on the right and the after image is on the left.
I'm not sure if those categories were missing their highlights on purpose but let me know if they were.
<img width="1280" alt="screen shot 2016-10-24 at 10 09 22 pm" src="https://cloud.githubusercontent.com/assets/996377/19643530/88d651f0-9a36-11e6-92e3-a05a9a71f147.png">
Thanks!
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Revert "::Rake::CommandFailedError doesn't exist."
This reverts commit c5a889ce865cc0314597e9de11e2bee366e797ac.
|
| | | | |
| | | |
| | | |
| | | | |
This reverts commit c5a889ce865cc0314597e9de11e2bee366e797ac.
|
| |\ \ \ \
| |_|_|/
|/| | |
| | | | |
Version 1.13.6
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
[RubygemsIntegration] Temporarily make #gem public again
Closes #5102
\c @indirect @schneems
(cherry picked from commit 90b99f2c35b38724fd7a9fef3e96587bd5aed2b4)
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conservative updates on outdated
Add conservative resolving behavior to outdated command.
- [x] convert existing flags to --filter-*
- [x] deal with strict flag
- [x] make a 2.0 issue to consider making strict flags more consistent
- [x] fix #5065 (outdated filter options don't work with `--strict')
- [x] fix #5076 (outdated shouldn't say "Bundle up to date!" if results are just filtered out.)
- [ ] document breaking change reasons? (_commit comment has something at least now_)
- [x] what about `bundle show --outdated`? (_it's a much simpler version ... prolly just going to leave it alone for now?_)
The flags as passed to the GemVersionPromoter _change_ resolution. <=1.13.2 of bundle outdated, those flags merely filter the output, with no influence on resolution.
If the lockfile is set to foo 1.0.0, and all of the following exist: 1.0.1, 1.1.0, 2.0.0, then <=1.13.2 bundle outdated currently will show:
`foo (newest 2.0.0, installed 1.0.0)`
<=1.13.2 `bundle outdated --minor` simply filters away that line and won't show it.
With these changes, `bundle outdated --minor` would be fed to the GemVersionPromoter and actually only resolve `foo` up to `1.1.0`.
This gist shows how it currently works, filtering the output: https://gist.github.com/chrismo/0bc6cfa00f539787101a9a2c900616d3
It's unfortunate timing. They were only added in 1.12 ... I'm biased, but feel like the affect the flags have on resolution is of greater value, and would be better to keep in sync with how they work fed to the `bundle update` command as of 1.13, and we could add new --filter-patch flags to replace what they do currently.
IIRC, there was some confusion at the time that Andre perhaps even thought these flags as of 1.12 would be affecting what the newest would resolve to, instead of just filtering the output, so - _if_ I'm remembering correctly, that's also influencing my opinion.
But, I can be swayed by the breaking behavior argument.
from @indirect in [this comment](https://github.com/bundler/bundler/pull/4841#discussion_r82021277):
"IMO, this is what we were trying to do in 1.12, and failed to do because resolving is complicated. :/ I would be okay with this change on the grounds that the previous flags were documented so it sounded like they cause the new resolver aware behavior. 👍"
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes #5076. When a filter option is in use and it filters out
everything in the requested categories, it's safer to say there were no
%{level} updates to display rather than "Bundle up to date!"
Tracking an additional local variable with the exact info to know that
even when filtered there was nothing to update anyway I didn't feel was
worth it with the current design.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes #4772 - Changes previous `--patch` / `--minor` / `--major` options
to `--filter-patch` / `--filter-minor` / `--filter-major` and adds back
`--patch` / `--minor` / `--major` as conservative the patch level update
options to match the behavior of these options in `bundle update` in
1.13.
This is a breaking change for the previous filtering options added in
1.12, but we're allowing it because there was some confusion as to what
those options did in 1.12, some thinking that it would perform the
resolution constraints that these options _now_ actually do.
A problem with merging in conservative bundle update options was the
pre-existing `--strict` `outdated` option, which has been in `outdated`
since 1.5. `--strict` for `outdated` means to only report on newer gem
versions that still satisfy declared requirements in the Gemfile.
Without `--strict`, `outdated` reports the most recent available
regardless of declared requirements in the Gemfile.
`--strict` in `update` in 1.13 means to not allow _any_ dependency to
update past the patch level option.
Rather than break the longer standing `--strict` option, the new
`--update-strict` option has been added which maps to the conservative
bundle update `--strict` option. We can revisit this in 2.0.
This also fixes #5065, where the new filtering options were ignored if
the `--strict` option was used.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
replicate cons. bundle install in update cmd
In the discussion on new 1.13 [Conservative Bundle
Updates](https://github.com/bundler/bundler-features/issues/122), some
users would like to have the same [Conservative
Updating](http://bundler.io/v1.12/man/bundle-install.1.html#CONSERVATIVE-UPDATING)
behavior available in `bundle install` when a declared dependency is
altered in the Gemfile, also available in the `bundle update` command.
|
| | | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In the discussion on new 1.13 Conservative Bundle Updates (see
https://github.com/bundler/bundler-features/issues/122), some users
would like to have the same Conservative Updating (see
http://bundler.io/v1.12/man/bundle-install.1.html#CONSERVATIVE-UPDATING)
behavior available in `bundle install` when a declared dependency is
altered in the Gemfile, also available in the `bundle update` command.
This adds a new option called `--conservative` to both `bundle update`
and `bundle lock`. The option only applies on `bundle lock` if the
`--update` option is in use.
The internal flag is more descriptive as to what actually takes place:
It locks any shared dependencies from the gem(s) being updated.
This also promotes the previously added patch level options to being
shown in command-line help, anticipating a 1.14 release, to make these
public and documented.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
[RubygemsIntegration] Temporarily make #gem public again
Closes #5102
\c @indirect @schneems
|
| |/ / / / / |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
[RubyGemsIntegration] Add a single method for #use_gemdeps
Closes #5040
\c @indirect
|
| | | |/ / /
| |/| | | |
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | |
| | | | | |
Fixed bundler incorrectly printing "the gem may have been yanked" in local installs
Closes #5022.
|
| |/ / / /
| | | |
| | | |
| | | | |
attempting to use a gem from the bundle before running the first bundle install. The gem version does exist in the remote gem server. Incorrect error message: '... that version could not be found in any of the sources listed in your Gemfile. If you haven't changed sources, that means the author of (the gem) has removed it'.
|
| |\ \ \ \
| | |/ /
| |/| |
| | | | |
Version 1.13.5
|
| | | | | |
|
