Refactor of PackageIndex and InstallPlan #3525
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
5 tasks
ezyang
force-pushed
the
pr/plan-refactor
branch
3 times, most recently
from
d5c0f22 to
baf8d99
Compare
|
Haven't reviewed in detail, but looks good so far. |
This is a preparatory commit for giving SolverInstallPlan its own type. We first start by moving the type synonyms for SolverInstallPlan into their own module, and update module references to point to them. TODO: Maybe this module should go in the Solver hierarchy rather than the client hierarchy? Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Now we copy-paste the contents of InstallPlan into SolverInstallPlan, thus giving it a separate set of types. For now, we don't do anything else, e.g., remove unnecessary functions or specialize. We need a new function 'fromSolverInstallPlan' akin to 'mapPreservingGraph' which can take an InstallPlan from the old solver install plan to the new one. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Now we monomorphize SolverInstallPlan so that its data structures
are non-parametric, and delete functions that are not needed.
Specifically:
- GenericPlanPackage -> SolverPlanPackage, lose the
type parameters, lose the Processing/Installed/Failed
constructors (this makes some partial functions total! Yay!)
- GenericInstallPlan -> SolverInstallPlan
- PlanProblem -> SolverPlanProblem
- Deleted ready, processing, completed, failed,
preexisting
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Critically, InstallPlan no longer levies solver-style sanity checks (e.g., whether or not the packages are consistent); it's assumed the SolverInstallPlan checks this, and that processing an InstallPlan is unlikely to cause problems here. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
ezyang
force-pushed
the
pr/plan-refactor
branch
2 times, most recently
from
c23052a to
2a53883
Compare
|
I realized this changeset has one BC-breaking change: the |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
cabal-install still broken, but less so! Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
This is a bit more accurate and doesn't require any fake UnitIds anymore. (But to-do: axe fake UnitIds!) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
The main point is solver packages don't HasUnitId; now that the solver install plan is separate from install plan the knock-on changes are quite localized and pleasing. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
See also haskell#3528. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
Ugh, Mac OS X GHC 8.0 build is timing out. |
ezyang
force-pushed
the
pr/plan-refactor
branch
3 times, most recently
from
b12e07d to
29f3c02
Compare
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Lots of changes:
- When possible, we use the container infrastructure (sudo: false)
rather than Google Compute Engine infrastructure (sudo: required).
Unfortunately, we can't use GCE for the Linux builds, where
reduced RAM available hoses are GHC build.
- Switched from using ./Setup and old-style cabal to new-build.
There are numerous great benefits but the best is that
.cabal/store can be cached on Travis, leading to huge speedups
on the build. Downside is we need to string-and-ceiling-wax
support for test/haddock/etc.
- I stopped bootstrapping on every build we do; instead there
is a separate bootstrap build we do to make sure that that
is working. This also speeds up the basic builds since
we are not building Cabal/cabal-install multiple times.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
Merged. |
|
It might be only me, but I'd realy like a bit more tidied up history. I'm very sorry, but that doesn't look very professional. Consider using |
|
Ugh, this is the "GitHub is bad at noticing what you actually pushed to master" bug (aka I forgot to push to the topic branch after rebasing.) If you look at the integrated history in master these commits are all gone. This branch was somewhat of a strange outlier because I was debugging Travis issues and needed to keep pushing to CI. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The point of this PR is to (1) split InstallPlan into two separate, decoupled data types, InstallPlan (for installing things) and SolverInstallPlan (the output of the solver, which we run consistency checks on) and (2) switch PackageIndex, InstallPlan, and SolverInstallPlan to use the new Graph data type introduced in #3523. Yes there are more lines of code, but they are less coupled and can support future evolution.
CC @dcoutts, @23Skidoo