| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
| |
We should use "Ruby\0" instead of "ruby\0".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It resolves #6247. This changes includes the patches that add (RSpec)
specs for this situation in #6247.
If there is a platform specific gem but it can't be resolved available
version, Bundler reports an error.
For example,
@index = build_index do
gem "bar", "1.0.0"
gem "foo", "1.0.0"
gem "foo", "1.0.0", "x64-mingw32" do
dep "bar", "< 1"
end
end
dep "foo"
platforms "x64-mingw32"
raises an error because foo-1.0.0-x64-mingw32 requires bar<1 but there
isn't bar<1.
With this change, foo-1.0.0 (no x64-mingw32) is used as
fallback. Because foo-1.0.0 doesn't depend on bar<1.
|
|
|
|
| |
be the only option
|
|
|
|
| |
The first spec succeeds, but the second spec fails currently.
|
| |
|
| |
|
|
|
|
| |
Also avoid mutating the original exception message to generate the message we want
|
|
|
|
| |
because #6014 avoids pre-releases when a non-pre-release version is possible
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
resolution
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Specify `--require spec_helper` in .rspec
Specifying `--require spec_helper` in .rspec will automatically require spec_helper in *_spec.rb.
It isn't necessary to specify `require "spec_helper"` in individual *_spec.rb. I think that it's a [DRY](https://en.wikipedia.org/wiki/Don't_repeat_yourself) way.
Refer: https://github.com/rspec/rspec/wiki#rspec
|
| | |
|
|/
|
|
| |
Run `rubocop -a --only Style/PercentLiteralDelimiters` and `rubocop --auto-gen-config`.
|
| |
|
| |
|
|
|
|
|
| |
I should have cleaned these up in a prior PR, but no time like the
present.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
segiddins and I are agreed there appears to be an issue with Molinillo
in these cases, but they are unusual and for now we're looking to do an
undocumented release of the new conservative updates, so we can start to
get feedback. We'll revisit these cases.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first behavior change from bundler-patch. Used to be older
versions would never be an option, but Bundler proper has always
supported this (if necessary to resolve the dependency tree) and there
can be some legit cases for doing this.
The `--strict` flag could be used to override this behavior, but I'm
running into a Molinillo behavior that I'm not sure is correct, so the
specs involving the strict option are failing right now. I'm going to
push so @segiddins and I can discuss.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In the process I was able to simplify some of the code inside
GemVersionPromoter dealing with SpecGroups.
I also attempted to implement the :major behavior into
GemVersionPromoter as that would eliminate the logic to skip it in
`#search_for`, however I ran into some test failures that I need to
investigate further, though unit specs are working so far.
|
| |
|
|
|
|
|
|
|
| |
A couple of confusing cases that should be clearer now and the
differences called out. Details in the spec code and comments.
Plus some MODO additions and other pending spec additions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UpdateOptions which was then renamed to DependencySearch is now called
GemVersionPromoter, cuz I can't name this damn class. It's in its own
file now, so there's that.
I took a shot at moving Resolver#search_for into it, but had naively
overlooked a few instance variables and such and it just didn't make as
much sense as I'd first envisioned. Probably some other smaller classes
in between perhaps.
GemVersionPromoter class now caching its results, too, and I moved out
the return from it back into Resolver as it made more sense there. As a
standalone class, it may make sense to have this actually implement
:major sorting, but maybe later.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Ported over resolver specs from bundler-patch README (which don't match
the actual specs for no particular reason other than dev lolz) and
expanded on some of the cases after a few weird cases resolved ... a
little unexpectedly.
They're passing, but some discussion to be had on some of the cases
perhaps. See inline spec comments.
|
|
|
|
|
|
|
| |
I stared at that code 2 or 3 times before seeing the obvious bug. Sigh.
Anyway - needed to get these resolver specs going sooner or later. Both
the first new resolver spec is passing as is the first update_spec spec
(plus the pre-existing ones).
|
| |
|
|
|
|
|
| |
- `Bundler::RubyVersionRequirement` can easily be replaced by
`Bundler::RubyVersion` whereever/however it's used
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Adds support for `bundle update --ruby` command to allow for updating
ruby version in Gemfile.lock.
* Adds support for `bundle install` to allow for adding ruby version in
Gemfile.lock.
https://www.pivotaltracker.com/story/show/106008092
Signed-off-by: JT Archie <jtarchie@gmail.com>
|
|/ |
|
| |
|
| |
|
| |
|
| |
|