Distribution.Client.ProjectConfig

This type corresponds directly to what can be written in the cabal.project file. Other sources of configuration can also be injected into this type, such as the user-wide config file and the command line of cabal configure or cabal build.

Since it corresponds to the external project file it is an instance of Monoid and all the fields can be empty. This also means there has to be a step where we resolve configuration. At a minimum resolving means applying defaults but it can also mean merging information from multiple sources. For example for package-specific configuration the project file can specify configuration that applies to all local packages, and then additional configuration for a specific package.

Future directions: multiple profiles, conditionals. If we add these features then the gap between configuration as written in the config file and resolved settings we actually use will become even bigger.

The project configuration is configuration that is parsed but parse configuration may import more configuration. Holds the unparsed contents of an imported file contributing to the project config.

That part of the project configuration that only affects how we build and not the value of the things we build. This means this information does not need to be tracked for changes since it does not affect the outcome.

Project configuration that is shared between all packages in the project. In particular this includes configuration that affects the solver.

Specifies the provenance of project configuration, whether defaults were used or if the configuration was read from an explicit file path.

Project configuration that is specific to each package, that is where we can in principle have different values for different packages in the same project.

Newtype wrapper for Map that provides a Monoid instance that takes the last value rather than the first value for overlapping keys.

Newtype wrapper for Map that provides a Monoid instance that mappends values of overlapping keys rather than taking the first.

Find the root of this project.

The project directory will be one of the following: 1. mprojectDir when present 2. The first directory containing mprojectFile/cabal.project, starting from the current directory and recursively checking parent directories 3. The current directory

Information about the root directory of the project.

It can either be an implicit project root in the current dir if no cabal.project file is found, or an explicit root if either the file is found or the project root directory was specicied.

Errors returned by findProjectRoot.

Read all the config relevant for a project. This includes the project file if any, plus other global config.

Read the user's cabal-install config file.

Reads a cabal.project.local file in the given project root dir, or returns empty. This file gets written by cabal configure, or in principle can be edited manually or by other tools.

Reads a cabal.project.freeze file in the given project root dir, or returns empty. This file gets written by cabal freeze, or in principle can be edited manually or by other tools.

Render the ProjectConfig format.

For the moment this is implemented in terms of a pretty printer for the legacy configuration types, plus a conversion.

Write a cabal.project.local file in the given project root dir.

Write a cabal.project.freeze file in the given project root dir.

Write in the cabal.project format to the given file.

Convert configuration from the cabal configure or cabal build command line into a ProjectConfig value that can combined with configuration from other sources.

At the moment this uses the legacy command line flag types. See LegacyProjectConfig for an explanation.

The location of a package as part of a project. Local file paths are either absolute (if the user specified it as such) or they are relative to the project root.

Exception thrown by findProjectPackages.

Determines the location of all packages mentioned in the project configuration.

Throws BadPackageLocations.

Read the .cabal files for a set of packages. For remote tarballs and VCS source repos this also fetches them if needed.

Note here is where we convert from project-root relative paths to absolute paths.

Look up a PackageConfig field in the ProjectConfig for a specific PackageName. This returns the configuration that applies to all local packages plus any package-specific configuration for this package.

Use a RepoContext based on the BuildTimeSettings.

Use a RepoContext, but only for the solver. The solver does not use the full facilities of the RepoContext so we can get away with making one that doesn't have an http transport. And that avoids having to have access to the BuildTimeSettings

Resolved configuration for the solver. The idea is that this is easier to use than the raw configuration because in the raw configuration everything is optional (monoidial). In the BuildTimeSettings every field is filled in, if only with the defaults.

Use resolveSolverSettings to make one from the project config (by applying defaults etc).

Resolve the project configuration, with all its optional fields, into SolverSettings with no optional fields (by applying defaults).

Resolved configuration for things that affect how we build and not the value of the things we build. The idea is that this is easier to use than the raw configuration because in the raw configuration everything is optional (monoidial). In the BuildTimeSettings every field is filled in, if only with the defaults.

Use resolveBuildTimeSettings to make one from the project config (by applying defaults etc).

Resolve the project configuration, with all its optional fields, into BuildTimeSettings with no optional fields (by applying defaults).

The project configuration is not allowed to specify program locations for programs used by the compiler as these have to be the same for each set of packages.

We cannot check this until we know which programs the compiler uses, which in principle is not until we've configured the compiler.

Throws BadPerPackageCompilerPaths