Distribution.Client.InstallPlan

GenericInstallPlan specialised to most commonly used types.

Packages in an install plan

NOTE: ConfiguredPackage, GenericReadyPackage and GenericPlanPackage intentionally have no PackageInstalled instance. `This is important: PackageInstalled returns only library dependencies, but for package that aren't yet installed we know many more kinds of dependencies (setup dependencies, exe, test-suite, benchmark, ..). Any functions that operate on dependencies in cabal-install should consider what to do with these dependencies; if we give a PackageInstalled instance it would be too easy to get this wrong (and, for instance, call graph traversal functions from Cabal rather than from cabal-install). Instead, see PackageInstalled.

Convenience combinator for destructing GenericPlanPackage. This is handy because if you case manually, you have to handle Configured and Installed separately (where often you want them to be the same.)

Build an installation plan from a valid set of resolved packages.

Conversion of SolverInstallPlan to InstallPlan. Similar to elaboratedInstallPlan

Remove packages from the install plan. This will result in an error if there are remaining packages that depend on any matching package. This is primarily useful for obtaining an install plan for the dependencies of a package or set of packages without actually installing the package itself, as when doing development.

Change a number of packages in the Configured state to the Installed state.

To preserve invariants, the package must have all of its dependencies already installed too (that is PreExisting or Installed).

Lookup a package in the plan.

Find all the direct dependencies of the given package.

Note that the package must exist in the plan or it is an error.

Find all the direct reverse dependencies of the given package.

Note that the package must exist in the plan or it is an error.

Flatten an InstallPlan, producing the sequence of source packages in the order in which they would be processed when the plan is executed. This can be used for simulations or presenting execution dry-runs.

It is guaranteed to give the same order as using execute (with a serial in-order JobControl), which is a reverse topological orderings of the source packages in the dependency graph, albeit not necessarily exactly the same ordering as that produced by reverseTopologicalOrder.

Execute an install plan. This traverses the plan in dependency order.

Executing each individual package can fail and if so all dependents fail too. The result for each package is collected as a BuildOutcomes map.

Visiting each package happens with optional parallelism, as determined by the JobControl. By default, after any failure we stop as soon as possible (using the JobControl to try to cancel in-progress tasks). This behaviour can be reversed to keep going and build as many packages as possible.

Note that the BuildOutcomes is not guaranteed to cover all the packages in the plan. In particular in the default mode where we stop as soon as possible after a failure then there may be packages which are skipped and these will have no BuildOutcome.

The set of results we get from executing an install plan.

Lookup the build result for a single package.

Generic way to show a GenericInstallPlan which elicits quite a lot of information

Return the packages in the plan that are direct or indirect dependencies of the given packages.

Return all the packages in the InstallPlan in reverse topological order. That is, for each package, all dependencies of the package appear first.

Compared to executionOrder, this function returns all the installed and source packages rather than just the source ones. Also, while both this and executionOrder produce reverse topological orderings of the package dependency graph, it is not necessarily exactly the same order.

Return the packages in the plan that depend directly or indirectly on the given packages.