GitLab

This refactoring unifies the defaulting logic into a single place
paving the way for changing the defaulting logic.

This is a refactoring abstracting `FlagAssignment` while retaining its
external appearance as much as possible (i.e. same Read/Show/Binary
instances etc).

Later we can attach new instances, enforce internal invariants (like
e.g. uniqueness of flagnames), switch out the internal
representation (maybe to `Data.Map`), etc more easily.

It's currently in the old Targets module, but we'll need it in the
new-build code too soon, and it's not really that closely related to
targets, so it makes sense to have it live in the common Types module.

Also add cataVersionRange, anaVersionRange, hyloVersionRange
and use them to deprecate foldVersionRange'

This builds on top of a0d80350 (#4575)
and extends the syntax to support the token `all` or `*` to serve as
wild-card for the relaxation subject, i.e. the following non-exhaustive
list of forms is made possible (NB: the package name `all` is reserved
on Hackage):

    allow-newer: somepkg:*
    allow-newer: somepkg:all
    allow-newer: somepkg:^*
    allow-newer: somepkg:^all
    allow-newer: all:^all
    allow-newer: *:^all
    allow-newer: *:^*
    allow-newer: *:*
    allow-newer: all:all

Refer to the user's guide for details

This removes the redundancy between `RelaxDepsNone` and
`RelaxDepsSome []` by removing `RelaxDepsNone`.

This way we avoid the risk of subtle bugs that can occur if the same
semantic value can be expressed in a non-unique way.

A further step to normalise the type would be to turn `[RelaxedDep]`
into `Set RelaxedDep`, but there is no operation that would
significantly benefit from that yet.

This extends the capabilities of `--allow-{newer,older}` to allow for more
fine-grained scoping to control more precisely which packages and constraints
a relaxation is applied to. See updated documentation for more details.

This is a preparatory refactoring needed for future work such as #4203.

I've refrained from doing additional cleanups in order to keep this a
refactoring that mostly moves around blocks of code mostly
unchanged (except for whitespace), and make it easier to review.

This feature was originally implemented because its lack was complained
about by Stack/Stackage developers. However, after it got implemented it
was never really being used; what's more, it's causing us overhead for
no benefit as well as blocking us improving the implementation via the
likes of #4203.

Closes #3581

Duncan Coutts authored Oct 22, 2016 and Edward Z. Yang committed Feb 07, 2017

It's really an error to try and build a graph where you have duplicate
node keys, so remove Graph.fromList and add Graph.fromDistinctList. This
check is always on, not just an assertion, becuase we get it for free
given the way Maps can be constructed.

All uses of Graph.fromList are ok to convert to fromDistinctList.

kristenk authored Jan 22, 2017 and Edward Z. Yang committed Feb 03, 2017

I used the new constraint scope to enforce the minimum Cabal version in setup
scripts that lack a 'custom-setup' stanza.  It isn't exposed to users yet.

I also removed 'unqualified' from PackagePath.hs and replaced all
uses of it with 'scopeToplevel'. The meaning is identical,
however 'scopeToplevel' is a less confusing name.

--install-base-libraries makes cabal ignore the list of packages that cannot be
installed or upgraded.

Refactored PackageConstraint in two ways:
 1) split it into a package name and a 'PackageProperty' to make
    the code a bit cleaner;
 2) changed PackageName to 'Qualified PackageName'.

Added a Binary instance for Qualifier in PackagePath.hs (needed
for PackageConstraint).

Added pretty-printing code for PackageConstraint.

For now, all the code that creates a PackageConstraint just sets
the qualifier to 'unqualified', so this commit will not change
the external behaviour of cabal-install.

[ci skip]

Duncan Coutts authored Oct 29, 2016 and Herbert Valerio Riedel committed Dec 31, 2016

Going along with the existing approach of using a constraint rather than
altering the deps of custom Setup.hs scripts, but make the constraint
only apply to Cabal instances that are dependencies of Setup.hs scripts
not all instances of Cabal.

Also rearrange things a little with a dedicated solver policy function
for adding a min dep on Cabal versions for setup scripts.

65e9b88b made template-haskell non-upgradable

65ae95c1 made it upgradable again

...and this commit makes it non-upgradable again

While there may be a few cases when `template-haskell` can be
reinstalled, it's generally not advisable, and causes more harm than the
benefit in the few cases where we'd gain install-plan
flexibility (e.g. when only template-haskell's API is needed for
compile, but no actual TH evaluation takes place).

Closes #4098

Also gets rid of `Distribution.Packages.TextClass`

Herbert Valerio Riedel authored Oct 30, 2016 and Edward Z. Yang committed Oct 31, 2016

Construction and destruction follows the usual pattern with `mkFlagName`
& `unFlagName` functions.

Similiar to dabd9d98 which made
`PackageName` opaque, this makes `Distribution.Version.Version` opaque.

The most common version numbers occuring on Hackage are 3- and
4-part versions. This results in significant Heap overhead due to
`Data.Version`'s inefficient internal representation.

So like the `PackageName` commit, this commit is a preparatory commit to
pave the way for replacing `Version`'s internal representation by a
representation with a memory footprint which can be an order of
magnitude smaller.

Finally, this also adds a new functor-like convenience function

    alterVersion :: ([Int] -> [Int]) -> Version -> Version

for modifying the version number components.

When looking at heap-profiles of `cabal-install`, the `(:)` constructor
stands out as the most-allocated constructor on the heap.

Having to handle 10k+ package names contributes to the allocation
numbers, especially on 64bit archs where ASCII `String`s have a 24 byte
per character footprint.

This commit is a preparatory commit to pave the way for changing
`PackageName`'s internal representation to something like
`ShortByteString` (which is essentially a thin wrapper around primitive
`ByteArray#`s which themselves have have an overhead of 2 words + one
byte per ASCII character rounded up to nearest word) which would allow
to reduce the memory footprint by a full order of magnitude, as well as
reduce pointer chasing and GC overhead.

There is a bug in `cabal configure`'s invocation of the solver in
Distribution/Client/Configure.hs:

    standardInstallPolicy
        installedPkgIndex
        (SourcePackageDb mempty packagePrefs)
        [SpecificSourcePackage localPkg]

We can see that the solver is given an EMPTY source package database.
This is because we assume that everything you need from cabal configure
is taken from the installed package index.

But this is NOT true for executables, which never have an entry in the
installed package index. So we SHOULD NOT solve for
executables in the legacy codepath, since there isn't anything useful we
can do with the info anyway.  This gets toggled using a new solver
parameter SolveExecutables.

I didn't bother with a test because this will be obsoleted by
nix-local-build.

Fixes #3875
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

The solver can handle duplicate targets by linking them together, but the log
is more complex, and the result is the same as if the targets were deduplicated
beforehand.

Duplicate targets can occur in a sandbox (issue #3203).

This fixes #220: new-build now builds, installs and adds executables to
PATH automatically if they show up in 'build-tools'.  However, there is
still more that could be done: the new behavior only applies to a
specific list of 'build-tools' (alex, happy, etc) which Cabal recognizes
out of the box.  The plan is to introduce a new 'tool-depends' field to
allow dependencies on other executables as well.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

[ci skip]

Removing 'topdown' as a resolver choice means that 'choose' is also
obsolete and so it is removed too.

This implements the flag `--allow-older` which is the analogous to
`--allow-newer` acting on lower bounds.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

As per an existing TODO in the code, the use of
testEnabled/benchmarkEnabled to indicate if a component
was enabled/disabled by the user command line was an
egregious violation of abstraction.  This commit removes
these two fields, instead passing along the necessary
enabling information with ComponentEnabledSpec instead.

As there were not many uses of testEnabled/benchmarkEnabled,
this was not too difficult to do.
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>

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>

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>

This also adds a not yet used `AllowOlder` newtype

This is a preparatory refactoring propsed in #3466 for supporting `--allow-older`