| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
matches
|
| |
|
|
| |
This should help people who run into version conflicts
|
| | |
|
| | |
|
| |
|
|
| |
the gemfile
|
| |\
| |
| |
| |
| |
| | |
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
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
[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
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a kind of weird and specific situation:
If, and only if, some version of a gem is installed into system gems
(e.g. rack 1.0), then trying to resolve a different version of that gem
from a specific remote source (e.g. rack 2.0.1.1.forked) will fail, even
though that gem is in fact available from that soure. Uninstalling the
unrelated version of rack from system gems completely solves this
problem. Alternately, running `bundle update rack` instead of `bundle
install` also completely solves this problem.
From this I speculate that we are unfairly withholding the rack
2.0.1.1.forked spec from the resolver, even though it was provided by
the source.
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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'.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | | |
Merge version 1.13.4 into master
None
|
| | |\ \ \
|/ / / /
| | | _
| | | |
Version 1.13.4
|
| | | | |
|
| | | |
| | |
| | |
| | | |
how did this ever pass even once :astonished:
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
THANK YOU RSPEC BISECT
also THANK YOU @SAMPHIPPEN
So it turns out that the realworld specs make real life network requests
to the real life rubygems.org. But we have some other “realworld” tests
that spin up a webrick server to recreate specific pathological server
behaviors. And those webrick servers might be able to answer requests
from later realworld tests that are expecting the actual rubygems.org,
but instead are getting our fake gem server because Artifice was never
stopped. :O
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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)
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Version 1.12.6
# Conflicts:
# CHANGELOG.md
# lib/bundler/vendor/compact_index_client/lib/compact_index_client/updater.rb
# lib/bundler/version.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
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | | |
Add platform information to env
Closes https://github.com/bundler/bundler/issues/5069
|
