Implement spago update for solver projects#1376
Conversation
|
@thomashoneyman oh, I now realise that we introduced single-version bounds in #1373 (not yet released); the registry will need to learn to parse those. I think implementing it after this patch will be nicer because we now have a separate type for it in Core, instead of coercing it to a Range. |
|
Gary had contributed this: It sounds like you're worried the registry will barf if it sees a range specified as "X.Y.Z" in the manifest instead of |
Yeah, this new branch is using that code, but now we are also allowing spago configs to have pinned versions instead of only ranges, like
Yea I think it will? |
|
Ah, right. We'd need to change this to have an additional case of |
src/Spago/Command/Upgrade.purs
Outdated
| upgradedCore = upgradeConstraints currentCore corePlan | ||
| upgradedTest = upgradeConstraints currentTest testPlan | ||
|
|
||
| -- Write back to config |
There was a problem hiding this comment.
Not sure how much it matters but this goes ahead and writes the constraints immediately after solving; #1001 describes building the resolved plan first, though, and only persisting changes in the build succeeded. Should we run the build with the solved plan and only then write?
There was a problem hiding this comment.
Yeah that slipped through, but it makes sense so I will add it.
2 participants
Fix #1001: we add
spago updatesupport for solver-based projects. The heuristic for doing this is by "extending" the range upwards, while keeping the lower bound intact. The packages that are fixed to a single version will keep being specified as a single (upgraded) version.