haskell/stackage
1
0
Fork 0
mirror of https://github.com/commercialhaskell/stackage.git synced 2026-02-06 19:37:29 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Markdown cleanups

Browse Source
This commit is contained in:
Michael Snoyman 2014-12-08 14:22:10 +02:00
parent afeaabc3cc
commit e88ec3fcd3
1 changed files with 27 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
ROADMAP.md
View File

@ -22,39 +22,40 @@ High level series of steps for processing
We start off with *constraints*. Constraints state things like "package X has a We start off with *constraints*. Constraints state things like "package X has a
given version range," who the maintainer is for a package, the description of given version range," who the maintainer is for a package, the description of
the system/compiler being used, etc. BuildConstraints discuss the build as a the system/compiler being used, etc. `BuildConstraints` describes the build as
whole, whereas PackageConstraints discuss the constraints on an individual a whole, whereas `PackageConstraints` describes the constraints on an
package. individual package.
There are two primary ways of getting a BuildConstraints. There are two primary ways of getting a `BuildConstraints`.
defaultBuildConstraints inspects the GHC in the PATH environment variable to `defaultBuildConstraints` inspects the first GHC in the PATH environment variable to
determine GHC version, core packages, core tools, etc. It then uses the determine GHC version, core packages, core tools, etc. It then uses the
Stackage.Config module to extract information on additional packages to be `Stackage.Config` module to extract information on additional packages to be
installed. The secondary approach is in UpdateBuildPlan, which will be installed. The secondary approach is in `Stackage2.UpdateBuildPlan`, which will be
discussed later. discussed later.
BuildConstraints do not specify a build completely. That is given by a `BuildConstraints` does not specify a build completely. That is given by a
BuildPlan, which is similarly broken down into BuildPlan and PackagePlan. In `BuildPlan`, which is similarly broken down into `BuildPlan` and `PackagePlan`.
order to get a BuildPlan, we need two pieces of information: the In order to get a `BuildPlan`, we need two pieces of information: the
BuildConstraints, and a package index. The package index (usually downloaded `BuildConstraints`, and a package index. The package index (usually downloaded
from Hackage) is a collection of all of the cabal files available. from Hackage) is a collection of all of the cabal files available.
By applying a BuildConstraints to a package index (via newBuildPlan), we get a By applying a `BuildConstraints` to a package index (via `newBuildPlan`), we
proposed BuildPlan. There is no guarantee that this BuildPlan is valid. To get a proposed `BuildPlan`. There is no guarantee that this `BuildPlan` is
validate it, we use checkBuildPlan. A BuildPlan is an instance of both ToJSON valid. To validate it, we use `checkBuildPlan`. A `BuildPlan` is an instance of
and FromJSON, and therefore can be serialized to a file for later use. both `ToJSON` and `FromJSON`, and therefore can be serialized to a file for
later use.
When dealing with LTS Haskell, we want to be able to take a BuildPlan, and When dealing with LTS Haskell, we want to be able to take a `BuildPlan`, and
update to a newer BuildPlan that keeps all packages in the same major version. update to a newer `BuildPlan` that keeps all packages at the same major
updateBuildConstraints turns a BuildPlan into a new BuildConstraints with that version. `updateBuildConstraints` turns a `BuildPlan` into a new
restriction, and updateBuildPlan applies newBuildPlan to that result. As `BuildConstraints` with that restriction, and `updateBuildPlan` applies
mentioned previously: this is *not* a validated result, and therefore `newBuildPlan` to that result. As mentioned previously: this is *not* a
checkBuildPlan must be used. validated result, and therefore `checkBuildPlan` must be used.
A BuildPlan can actually be acted on. This is done to check that all packages A `BuildPlan` can be acted on. This is done to check that all packages compile
compile together, run relevant test suites, test Haddock documentation is together, run relevant test suites, test Haddock documentation is correct, and
correct, and produce as artifacts both a self-contained GHC binary package produce as artifacts both a self-contained GHC binary package database and a
database and a set of Haddock documentation. (Not yet implemented.) set of Haddock documentation. (Not yet implemented.)
A BuildPlan may be converted into a bundle to be uploaded to Stackage Server. A `BuildPlan` may be converted into a bundle to be uploaded to Stackage Server.
(Not yet implemented.) (Not yet implemented.)