-
-
Notifications
You must be signed in to change notification settings - Fork 2k
Commits on Jul 9, 2016
-
Configuration menu - View commit details
-
Copy full SHA for b57b1df - Browse repository at this point
Copy the full SHA b57b1dfView commit details -
UpdateOptions added and passed thru all_the_things
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.
Configuration menu - View commit details
-
Copy full SHA for c821411 - Browse repository at this point
Copy the full SHA c821411View commit details -
bundler-patch resolver code ported over.
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.
Configuration menu - View commit details
-
Copy full SHA for a404dad - Browse repository at this point
Copy the full SHA a404dadView commit details -
minor/patch resolution code invokable.
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.
Configuration menu - View commit details
-
Copy full SHA for 100c3bb - Browse repository at this point
Copy the full SHA 100c3bbView commit details -
First resolver spec and bug fix.
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).
Configuration menu - View commit details
-
Copy full SHA for 80e1b17 - Browse repository at this point
Copy the full SHA 80e1b17View commit details -
1st pass thorough specs on conservative resolver.
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.
Configuration menu - View commit details
-
Copy full SHA for 0ccdb21 - Browse repository at this point
Copy the full SHA 0ccdb21View commit details -
Configuration menu - View commit details
-
Copy full SHA for 949dea2 - Browse repository at this point
Copy the full SHA 949dea2View commit details -
Configuration menu - View commit details
-
Copy full SHA for 5f63cad - Browse repository at this point
Copy the full SHA 5f63cadView commit details -
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.
Configuration menu - View commit details
-
Copy full SHA for b26b54c - Browse repository at this point
Copy the full SHA b26b54cView commit details -
Ensure locked_specs provided in unlock all case.
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.
Configuration menu - View commit details
-
Copy full SHA for 20426a8 - Browse repository at this point
Copy the full SHA 20426a8View commit details -
Configuration menu - View commit details
-
Copy full SHA for bdc1df5 - Browse repository at this point
Copy the full SHA bdc1df5View commit details -
Configuration menu - View commit details
-
Copy full SHA for 3630f18 - Browse repository at this point
Copy the full SHA 3630f18View commit details -
Clarified changing dependency specs.
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.
Configuration menu - View commit details
-
Copy full SHA for 3d3aeda - Browse repository at this point
Copy the full SHA 3d3aedaView commit details -
Configuration menu - View commit details
-
Copy full SHA for 93fac82 - Browse repository at this point
Copy the full SHA 93fac82View commit details -
Configuration menu - View commit details
-
Copy full SHA for a444014 - Browse repository at this point
Copy the full SHA a444014View commit details -
Configuration menu - View commit details
-
Copy full SHA for d88ef5c - Browse repository at this point
Copy the full SHA d88ef5cView commit details -
Invalid level in GemVersionPromoter now raises.
This shouldn't ever surface to the user, would be the result of a coding mistake.
Configuration menu - View commit details
-
Copy full SHA for 6af8ef7 - Browse repository at this point
Copy the full SHA 6af8ef7View commit details -
Configuration menu - View commit details
-
Copy full SHA for cb2f8c8 - Browse repository at this point
Copy the full SHA cb2f8c8View commit details -
Moved GemVersionPromoter inside search_for cache.
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.
Configuration menu - View commit details
-
Copy full SHA for 8cbe425 - Browse repository at this point
Copy the full SHA 8cbe425View commit details -
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.
Configuration menu - View commit details
-
Copy full SHA for 861eb2b - Browse repository at this point
Copy the full SHA 861eb2bView commit details -
Configuration menu - View commit details
-
Copy full SHA for 00b8064 - Browse repository at this point
Copy the full SHA 00b8064View commit details -
No need to dupe cached GVP output
...now that its output is inside the Resolver's cache.
Configuration menu - View commit details
-
Copy full SHA for d025055 - Browse repository at this point
Copy the full SHA d025055View commit details -
Configuration menu - View commit details
-
Copy full SHA for f37c76f - Browse repository at this point
Copy the full SHA f37c76fView commit details -
Hook-up
--strict
option, flesh out update specs.Getting caught up on missing update_specs, realized `--strict` flagged wasn't being passed through. Fixed.
Configuration menu - View commit details
-
Copy full SHA for 3d1e6e3 - Browse repository at this point
Copy the full SHA 3d1e6e3View commit details -
Configuration menu - View commit details
-
Copy full SHA for 57d70be - Browse repository at this point
Copy the full SHA 57d70beView commit details -
Add some additional GVP specs per TODO.
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.
Configuration menu - View commit details
-
Copy full SHA for 257c8b2 - Browse repository at this point
Copy the full SHA 257c8b2View commit details -
Support for reverting to older versions.
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.
Configuration menu - View commit details
-
Copy full SHA for 60f64fd - Browse repository at this point
Copy the full SHA 60f64fdView commit details -
Add docs to GemVersionPromoter.
Also some pending specs cleanup. These may be added as new issues and addressed later.
Configuration menu - View commit details
-
Copy full SHA for 3e56e8f - Browse repository at this point
Copy the full SHA 3e56e8fView commit details -
Mark pending two failing specs.
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.
Configuration menu - View commit details
-
Copy full SHA for f16f129 - Browse repository at this point
Copy the full SHA f16f129View commit details -
Configuration menu - View commit details
-
Copy full SHA for 9022339 - Browse repository at this point
Copy the full SHA 9022339View commit details -
Don't parse empty Lockfile during GVP init
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.
Configuration menu - View commit details
-
Copy full SHA for 263c187 - Browse repository at this point
Copy the full SHA 263c187View commit details