| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Not only does this test mean that we’re sure the method works, I like
how the method is structured now a lot better too :grin:
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conservative updates
A port of bundler-patch to bundler proper.
Core team questions:
- [x] bundler-patch also works in vulnerable gem updates based on ruby-advisory-db content. I presume the core team would consider this out of scope for Bundler proper? I probably would, and there's no reason bundler-patch couldn't continue to exist as a plugin with this behavior.
- [x] "resolves foo only to latest patch - changing dependency case" - more comments on that spec. It's a weird edge case. Hopefully the specs and comments make it clear.
- [x] Name of new class: GemVersionPromoter. It's gone through a few renames already and every option I think of I hate now :)
- [x] The `--minimal` flag is also something bundler-patch has that has debatable value. Would love to hear opinions on it and could be easily swayed to remove it or keep it. If I'm on 1.0.1, and both 1.0.2 and 1.0.15 exist, `--minimal` will resolve to `1.0.2` instead of the latest `1.0.15`. Dunno if there's value in that.
- [x] even without `--strict` mode, this code will _remove_ older versions from the options handed back to Molinillo (in `--patch` and `--minor` cases). This is a weird case, but I have seen `bundle update` proper regress a gem version backwards if its parent gem changed to an older dependency (I guess in a bug fix case). I'm ok with this, but it could be considered an inconsistency with the default `--major` case.
- [x] if we roll this out first as an undocumented feature, do we require a config option to toggle it on? We wouldn't have to have one, none of the new behavior will kick in until a new flag (`--patch` or `--minor`) is passed.
---
Notes for issues to create that could be handled separately after this PR, esp. if we release undocumented/unsupported to begin with.
- Updating `outdated` to use the new flags and resolution
- adding some warnings when dependent updates go past --patch or --minor level (with an instruction to use --strict if they don’t want that)
- adding a warning when an unlocked gem doesn't move (possibly w/ a reason why?). the lack of feedback otherwise can be disconcerting, like "did I not do it right?"
- possibly adding a dry-run flag - though after looking at that today, that would make the most sense inside Installer, and make that flag an option for both install and update (drilling through all of the calls to push that option in looks like it would be annoying).
- man page documentation
|
| |
| |
| |
| |
| |
| |
| |
| | |
Not a common case, but glitch is triggered by new plugin integration
tests when there's no Gemfile or .bundle directory. A GemfileNotFound
exception is raised deeper down the call stack trying to access the
cache_path when executed in a non-bundler dir. That case apparently is
legit for plugins.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
Also some pending specs cleanup. These may be added as new issues and
addressed later.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
When I ported over specs from bundler-patch, I had a TODO on a
combination that had no specs, so that's taken care of now.
|
| | |
|
| |
| |
| |
| |
| | |
Getting caught up on missing update_specs, realized `--strict` flagged
wasn't being passed through. Fixed.
|
| | |
|
| |
| |
| |
| | |
...now that its output is inside the Resolver's cache.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If GVP handles the default :major case, it now passes all the specs, but
that's a lot of existing functionality to hand off to it at this stage,
so I kept in the conditional to just roll with existing results if
:major.
Got rid of a couple of superfluous begin/end I'd included to make
RubyMine auto-format the code in a way that made Rubocop happy.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| | |
This shouldn't ever surface to the user, would be the result of a coding
mistake.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Another bit brought over from bundler-patch, this code in Definition
ensures the GemVersionPromoter has the locked specs it needs in the
'unlock all' case. Everywhere else in Definition, empty @locked_specs
means unlock all, but doing conservative updates requires knowing the
current locked version so it always needs this list.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Prior commit added in the code but it only worked in the default :major
case by staying out of the way, so it at least didn't break existing
functionality. But the GemsToPatch class hadn't been brought over from
bundler-patch yet, so none of the patch/minor code could work as it was
referencing an ivar that didn't exist yet.
Bundler-patch not only will handle an update to whatever is the latest
patch/minor version, but will also handle an update to a version
specified in an advisory from ruby-advisory-db. At this point I don't
believe we'll be adding the advisory behavior to Bundler proper, so this
commit can bring over simply the array of gem names being updated
without the GemsToPatch class or the extra sorting code that takes a
specific version number into account.
With these simplifications, the starter update_spec can run without
exception, though for some reason it's behaving as if the :minor level
were specified, instead of :patch.
Rather than keep debugging from an integration level, it's time to start
bringing over resolver tests.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Putting all this code into Resolver itself, when it's almost completely
isolated, didn't make sense. UpdateOptions was the best place for it,
prompting me to think that class needs renaming and see if the current
search_for method could be moved into it as well. Except for `index_for`
it's a cinch.
`install_spec` and `update_spec` are still passing with this addition,
first new spec for conservative update isn't yet.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
First shot adding new update CLI options and passing those through
Definition into Resolver where they're needed.
I opted for three separate options to reduce typing, vs. a --level
[patch|minor|major].
It's a little painful merely extending parameter lists in places, but
bigger refactorings prolly be more painful.
|
| | |
|
|\ \
| |/
|/|
| |
| |
| | |
fix feature request link
I noticed the label name was updated.
|
|/ |
|
|\
| |
| |
| |
| |
| |
| | |
Fix RubyGems printing packaging messages during the specs
Closes #4755.
My bad!
|
| | |
|
|\ \
| |/
|/|
| |
| |
| | |
[Plugin] Source plugins
Adds source plugin. This is in continuation of #4608.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|