GitLab

It seems that package authors are often unaware of the purpose of
synopsis/description fields, and their impact on cabal and Hackage.  A
common mistake is to write a verbose synopsis and leave the description
field empty or even worse with useless boilerplate-text filled in by
tooling, resulting in a suboptimal presentation on Hackage.

The `synopsis` is supposed to be a terse <80 char description. In fact,
the cabal user's guide states:

> A very short description of the package, for use in a table of
> packages. This is your headline, so keep it short (one line) but as
> informative as possible. Save space by not including the package name
> or saying it’s written in Haskell.

On Hackage this synopsis is printed in the `<title>` and at the top of the
package page, and is difficult to spot. However, the synopsis is
displayed on Hackage in package lists or search results.

On the other hand, the `description` field is rather important for
`cabal info`  as well as the package cover-page, as it's printed below
the "The $PKGNAME package"-heading, and above the properties section,
and that's where everyone looks at.

This new lint check is an attempt to point out a suspiciously short
description field by using the heuristic of expecting the description
field to be longer than the synopsis.

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.

Pretty utils

Remove setup-dev.sh since it is no longer necessary post-new-build.

[ci skip]

[ci skip]

Consistently update 'localPkgDescr' with 'HookedBuildInfo' + docs

I got sucked into this rathole while puzzling over why
we pass both 'PackageDescription' and 'LocalBuildInfo' (which
has a 'PackageDescription' in 'localPkgDescr').  The conclusion
is that they were different, but not for a good reason. Now they're
the same.

Added docs fixes #1757.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

1. Unbreak the deployment script (hopefully the last time).
2. No longer attempt to upload docs when building from non-main repos.

Fixes #3592.

Explode Distribution.PackageDescription into many Distribution.Types modules

This commit explodes Distribution.PackageDescription and
Distribution.Simple.LocalBuildInfo into many Distribution.Types modules.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

BC fix: libraries -> library/subLibraries (#3574)

The resulting code is more verbose, but it is more backwards-compatible
and actually is simpler to understand in some cases (because
CLibName uniquely identifies the "public library"; no faffing
about with package names to figure it out.)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

Introduce new ComponentEnabledSpec, removing testEnabled/benchmarkEna…

Test bootstrap on OSX.

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

The command 'new-build' won't be completed, but if you type it out
you'll get completions from that point.

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>

See the comment in the code.  I don't like it but it's BC!
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.

    - There are some hacks.  The big one is setting CABAL_BUILDDIR
      explicitly; this smooths over quite a few infelicities in
      the current new-build implementation.
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>

See also #3528.
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>

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>