| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
since invalid specs were allowed by 1.0-1.9, we allow them in all 1.x
versions. we'll go back to throwing an exception on invalid gemspecs in
Bundler 2.0. (cc @smlance)
fixes #3688
|
| |\
| |
| | |
Fix option description for `bundle gem`
|
| | |
| |
| | |
The `--bin` option incorrectly had the description "Set a default with `bundle config gem.mit true`." I've moved this text to the appropriate place in the `--mit` description.
|
| |/ |
|
| | |
|
| |
|
|
|
| |
The original cases ("not zero") would still pass if the check resulted
in a nil response.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The RemoteSpecification#sort_obj method was added in e5d936e7 (which
was cherry-picked from #3767) to fix #3762, but it still fails when
comparing two instances of RemoteSpecification.
As #sort_obj is private, the check for other.respond_to?(:sort_obj)
returns false, which means the <=> check falls back to the default
(from Object) which returns nil if the objects being compared don't
match. This then results in an ArgumentError when (e.g.) sorting an
array containing multiple instances of RemoteSpecification.
The fix is simple: make RemoteSpecification#sort_obj public.
|
| |
|
|
|
|
| |
Travis support says that the many duplicate build notifacations that
we've been getting via email and Slack are because of the fast_finish
setting misbehaving. We'll just turn it off for now to work around it.
|
| |
|
|
|
| |
The sad days when you have to write old-style hash syntax and want to
cry.
|
| | |
|
| |
|
|
|
| |
Because its faster and okay since all specs with the same name were
already filtered out.
|
| |
|
|
|
|
| |
Reject is clearly not the right method to use here, now I’m trying to
figure out what state of mind I was in when I wrote something that is
so obviously wrong.
|
| | |
|
| |\
| |
| | |
[Definition] Dont updated bundled with when 100% unnecessary
|
| | | |
|
| | |
| |
| |
| | |
[ci skip]
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| | |
from karlo57/3715-install-force-should-delete-existing-gems-before-install
Includes tests for --force and a fix for trying to reinstall Bundler
|
| | |
| |
| |
| | |
yet created
|
| | |
| |
| |
| | |
gem reinstall
|
| | | |
|
| |/ |
|
| |
|
|
| |
Uses a comparison strategy borrowed from RubyGems 2.23 for maximum
compatibility with Gem::Specification et. al.
|
| |
|
|
|
|
| |
/ht @tony-spataro-rs
fixes #3762
|
| |\
| |
| | |
[Resolver] Add optimization for deps where theres a path/gemspec source
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | | |
update rails version in specs
|
| |/ /
| |
| |
| | |
https://github.com/rails/rails/releases/tag/v3.2.22
|
| |/ |
|
| | |
|
| |\
| |
| | |
Implicit lock preservation
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When either `bundle check` is run, or any application requires the
`bundler/setup` file, Bundler will automatically check whether it is
possible to lock the Bundle. During the lock process, Bundler updates
the lock if the implicit locking changes the lock file.
Starting with the 1.10 release, Bundler includes a lockfile section
named BUNDLED WITH that includes the version of Bundler that generated
the lockfile. In order to minimize git churn, and guarantee that the
lockfile will only be changed when the user runs an explicit Bundler
command, Bundler will now only add or update the BUNDLED WITH section
during commands where the user asks for changes to the lock. This
includes, but is not limited to, `install`, `update`, `lock`, and
`package`.
Running the `check` command or loading an application that uses Bundler
will still now add or update the BUNDLED WITH section if, and only if,
the lockfile has also changed for a different reason (such as a gem
being updated).
Simply using an application, by running `bundle exec` commands or by
running `bin/rails` and the like, will not change the lockfile. As a
result, the intended workflow with the BUNDLED WITH section is now
slightly different than it was before:
1. When running `bundle install`, Bundler will update the version in
the lockfile if newer than the version present.
2. Then, check in the lockfile change, exactly as you would after
running install to change any other gem version.
3. Older versions of Bundler will not change the number in the lock,
but will warn the user that they are out of date.
refs bundler/bundler-features#80
refs #3697
|
| |/
|
|
|
|
| |
we want to avoid changing the lock just to add BUNDLED WITH unless the
user is explicitly running a Bundler command; implicit locking should
not alter the lockfile.
|
| |
|
|
|
|
|
| |
The lazy-created UI is silent, and we need to be able to print for
things like ambiguous command error messages.
This reverts commit 849c649632b71111a06e71c0170ba966aca60d04.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
