| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| | |
[WIP] New patch level and conservative options documented.
Fixes #4775.
|
| | |
|
| | |
|
| |
| |
| |
| | |
Fixes #4775.
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Warn if executable in bundle exec is empty
closes https://github.com/bundler/bundler/issues/5084
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | | |
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] Add a single method for #use_gemdeps
Closes #5040
\c @indirect
|
| | |/ /
| |/| | |
|
| |/ /
|/| |
| | |
| | | |
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
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
[Index] Allow pre-release versions in search when the base is pre-release
Closes #5089
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
[Index] Allow pre-release versions in search when the base is pre-release
Closes #5089
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Changed the behavior of 'bundle clean --dry-run' to output the list regardless of path set or force option
Changed the behavior of 'bundle clean --dry-run' to output the list of gems bundle without having the local path set or providing the '--force' option. This change does not affect the actual behavior of 'bundle clean' which requires either the path being set or use of '--force'.
Closes #5027.
|
| | | | |
| | | | |
| | | | |
| | | | | |
bundle without having the local path set or providing the '--force' option. This change does not affect the actual behavior of 'bundle clean' which requires either the path being set or use of '--force'.
|
|\ \ \ \ \
| |_|/ / /
|/| | / /
| | |/ /
| |/| | |
Version 1.13.4
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Revert "::Rake::CommandFailedError doesn't exist."
This reverts commit c5a889ce865cc0314597e9de11e2bee366e797ac.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix #4934. Make GVP _after_ eager unlock.
When Definition creates the GemVersionPromoter, it needs to do so
_after_ it's performed the eager_unlock so the GVP gets the correct list
of unlocked gems.
Prior to this fix, it had a stricter list of gems being updated with the
new `--patch` or `--minor` options used with `bundle update` and in some
cases would have inconsistent results when used without a conservative
switch or the `--major` option. See #4934 for details.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
aycabta:use-require-instead-of-autoload-for-plugin-api, r=indirect
[workaround] Use `require` instead of `autoload` for bundler/plugin/api
Please read https://github.com/bundler/bundler/pull/4981#issuecomment-248674155.
> But it's elusive reproduction (and lack of test case) makes me think that the problem is a bit deeper and may recur.
I think so. This Pull Request is just *workaround*.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
use /tmp for mktmpdir
As we noticed in #4519, we need to use a temporary directory to hold
compact index downloads so that multiple processes don't write to the
same files at the same time and break everything.
The fix for that was #4561, which added temporary directories to hold
all files as they download, and then uses the (atomic) `FileUtils.cp` to
move the completed downloads into place, so there is never a point where
multiple processes are trying to write into the file at once.
Unfortunately, using `Dir.mktmpdir` requires that the parent directory
be _either_ world writable or sticky, but not both. Based on #4599, it
looks like it's common for home directories to be both world writable
and sticky. While that's a security problem by itself, it's not a big
concern for Bundler and the compact index. So we want to let users
continue to use Bundler, even with the compact index, without having to
change the permissions on their home directories.
This commit changes the `mktmpdir` call to create the temporary
directory inside the default OS tempdir, which is typically `/tmp` or
`/var/tmp` depending on distro. Since that directory is designed to hold
other temporary directories, that change should (theoretically) reduce
or eliminate the problem reported in #4599.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
change checksum warning to debug print
This was super helpful when the server was continuously returning bad
checksums, but it’s a scary warning to see anytime we update the
versions file. And we’re going to need to update the versions file at
least twice a year, so it seems like a good idea to head off users
worrying about a message that is actually things working as intended.
|
|\ \ \ \
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | | |
Version 1.13.3
# Conflicts:
# lib/bundler/vendor/compact_index_client/lib/compact_index_client/updater.rb
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
(cherry picked from commit ece6829c46e4768aae13f970a54017c272bf974d)
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
[Fetcher::Dependency] Sort gem names in query string
This might slightly help the fastly hit rate?
\c @indirect @dwradcliffe
|
| | | | | |
|
|/ / / / |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This was super helpful when the server was continuously returning bad
checksums, but it’s a scary warning to see anytime we update the
versions file. And we’re going to need to update the versions file at
least twice a year, so it seems like a good idea to head off users
worrying about a message that is actually things working as intended.
|
| | | | |
|
| | | | |
|
| |_|/
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Restore default outdated.
Added command in cli:
- bundle outdated --groups
Added --group option.
Groups with alphabetical order.
Added test. Reverted.
|