(cherry picked from commit 6b6c6842)

(cherry picked from commit 3792f658)

Redesign 'cabal path' command to account for projects (backport #9583)

* Redesign 'cabal path' command to account for projects

Previously, `cabal path` was only able to query from the global
configuration file, e.g., `~/.cabal/config` or the XDG equivalent.
Adding support for cabal project is a huge boost to usability.

We take the foundations and turn them into `cabal v2-path` which takes
project configuration, such as `cabal.project` into account.
Note, the command is still named `cabal path`, but for the sake of
disambiguation, we refer to this new iteration of the command as `cabal
v2-path`.

In addition, we add support for multiple output formats, such as
key-value pairs and json.

The key-value pair output prints a line for each queried key and its
respective value:

    key1: value2
    key2: value2

If only a single key is queried, we print only the
value, for example:

    value1

The json output format is versioned by the cabal-install version which
is part of the json object.
Thus, all result objects contain at least the key "cabal-install-version".

We expand the `cabal v2-path` to also produce information of the
compiler that is going to be used in a `cabal build` or `cabal repl` invocation.
To do that, we rebuild the install plan and query for the configured
compiler program.
This is helpful for downstream tools, such as HLS, to figure out the GHC
version required to compile a project with.

We also add an exhaustive test suite for 'cabal path' cmd

We test that each query honours cabal.project files, cli parameters, and
is composable with the other query flags.

We extend the test output normalisers for ghc compiler location and
cabal-install version, as the 'cabal path' command outputs the exact ghc
and ghc-pkg location. In addition, the json output format is versioned
on the cabal-install version.

Currently, we query the cabal-install version on each test normalisation
run. This might be unnecessary expensive, and could be avoided by
introducing a 'cabalProgram' that specifies how the program version can
be found. This way, we can cache the version query.

Add '--cache-home' flag thats shows the cabal's cache root

Rename '--cache-dir' to the more correct '--remote-repo-dir'.

* Update 'cabal path' documentation

* Add changelog.d entry

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
(cherry picked from commit 4a8a7c5d)

Update setupMinCabalVersionConstraint for GHC 9.10 (backport #9882)

(cherry picked from commit ecb174da)

Fix cabal install in the presence of extra-packages (backport #9719)

Support GHC2024 (fixes #9736) (backport #9791)

(cherry picked from commit 23a68409)

Fix `<more complex packages>` link lost in doc/cabal-package-description-file.rs (backport #9765)

(cherry picked from commit 05860310)

Show import tree provenance (backport #9578)

With this change to the solver message rendering, I also fix some bugs around project imports, adding tests for those cases. Reviewers asked that the Y-shaped import checks (using IORef) be made on a separate pull request. Removing those lead to cascading deletions.

- Regenerate expected .out files
- Show tree provenance of import constraint
- Add trimmed down PackageTests/VersionPriority
- Add changelog entry
- Use NonEmpty
- Fix check for cyclical import
- Use primes for next iteration
- Remove unused LANGUAGE pragmas
- Rename to projectConfigPathRoot
- Docs for ProjectConfigPath and showProjectConfigPath
- Renaming
- Add cyclical import tests with 1 and 2 hops in cycle
- Use full path for cyclical error message
- Expected output has project with full project path
- Add fullPath local function
- Project directory as FilePath, not Maybe FilePath
- Use (_, projectFileName) binding splitFileName
- Need full path to project parsing legacy
- Inline seenImports conversion
- Add cyclical checks with same file names and hops
- Add noncyclical tests that hop over folders
- Add a project testing skipping in and out of a folder
- Update expectations of cyclical tests
- Use canonicalizePath for collapsing .. when possible
- Capture trace for later
- Add module for ProjectConfigPath
- Move functions for ProjectConfigPath to its module
- Fetch URI is not prefixed with ./https://etc
- Document normaliseConfigPath
- Add doctests for normaliseConfigPath
- Add doctest of canonicalizeConfigPath
- Show an example of canonical paths
- Use importer and importee in canonicalizeConfigPaths
- Add logging

Extra-packages listed in a cabal project are to be fetched from hackage,
and will be in memory as 'NamedPackages' rather than resolved to
'SpecificSourcePackage'.

On install, we need to make source-dists for all the specific source
packages, and fetch other packages from hackage. Since extra-packages
are already 'NamedPackages', we simply return them along the sdistize-d
specific source packages and the hackage source packages -- they will be
correctly fetched from Hackage from install.

Previously, cabal install <tgt> on a project with extra-packages would
fail because the branch of 'NamedPackage' for 'PackageSpecifier' was
simply unimplemented.

Fixes #8848

(cherry picked from commit c671f0e9)

Conform BSD-2-Clause and BSD-3-Clause text to SPDX (backport #9813)

`cabal init` text for BSD-2-Clause and BSD-3-Clause licence differed
slightly from the one published at SPDX. [1] [2]

This caused some problems to users when dealing with licence-recognition
software. [3]

[1] https://spdx.org/licenses/BSD-2-Clause.html
[2] https://spdx.org/licenses/BSD-3-Clause.html
[3] https://discourse.haskell.org/t/non-standard-license-generated-by-stack-new/9059

(cherry picked from commit 1e86730a)

Bump time upper bound to acccomodate 1.14 (backport #9848)

(cherry picked from commit e7d9b84a)

CI validate-old-ghcs: pin to haskell-actions/setup@v2.6 (backport #9859)

This provides temporary life support to the `validate-old-ghcs` action
until node16 will be finally axed by GHA in May 2024.

Workaround for:
- https://github.com/haskell/cabal/issues/9858

(cherry picked from commit 2da8b2fa)

* Bump version numbers for 3.12.0.0

Version fields, constraints, licences, and bootstrap.

☞ N.B.:
- This commit removes 8.10.7 from bootstrap list.
- This release only deals with Cabal, not cabal-install.

* Update index state in cabal.project.release

This is needed since we need the new (0.6.2.5) release of
hackage-security.

* Regenerate bootstrap .json files

Update licence list

Per https://github.com/haskell/cabal/wiki/Updating-the-license-list
to version 3.23 (2024-02-08) of SPDX License List.

Make `check` recognise `main-is` in conditional branches (backport #9768)

* Add tests for #9742

`main-is` not picked up when inside a multibranch CondNode.

* Fix comments

* Add simplifyBranch to Distribution.Types.CondTree

Goes hand in hand with with simplifyCondTree.

* Make `check` deal correctly with multiple branches

`cabal check` had a problem recognising fields in presence of
multiple branches. This patch fixes the problem and does not
meaningfully increases CI time of particularly taxing tests
(like “duplicate flagged dependencies” from MemoryUsage).

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
(cherry picked from commit 74b1f215)

Add 3.12 Cabal changelog

- generated with
     git log --pretty=oneline --no-color cabal-install-v3.10.1.0..HEAD > 3.12.prlog
- deduped
- stored WIP “release notes” file for future `cabal-install` release

Update .cabal files (backport #9761)

`extra-doc-files` and `no-autogen-paths` warnings.

(cherry picked from commit 28daab12)

Find build-tool installed programs before programs in path (backport #9762)

We must consider the path to the installed build-tool before the path to
existing versions of the build tool in paths such as `extra-prog-path`
or in the system path.

This was previously fixed by #8972 but undone by #9527.

This also renames `appendProgramSearchPath` to
`prependProgramSearchPath` to describe correctly what that function
does.

Fixes #9756

(cherry picked from commit 84c30c26)

update copyright for 2024

testsuite: Run tests in temporary system directories

1. Working directory is not contaminated with results of the testsuite.
   Tests can be written in a more liberal way (creating/writing files
   etc).
2. The tests are more hermetic.. for example it was basically impossible
   to write a test which run outside of a project context.
3. The overall path lengths will be much shorter, which has been a
   consistent issue on windows. We can remove hacks like
   `withShorterPathForNewBuildStore`.

Fixes #9711

Download stackage.org/.../cabal.config locally

cabal-install: Clarify the semantics of package-db flag

In this PR we make the `--package-db` flag apply only to the default
immutable initial package stack rather than also applying to the store
package database.

There are two special package databases which cabal install knows about
and treats specially.

* The store directory, a global cache of installed packages where cabal
  builds and installs packages into.
* The inplace directory, a local build folder for packages, where cabal
  builds local packages in.

It is very important that cabal registers packages it builds into one of
these two locations as there are many assumptions that packages will end
up here.

With the current design of the `--package-db` flag, you are apparently
allowed to override the store location which should have the effect of
making the last package database in the package stack the "store"
directory. Perhaps this works out in theory but practically this
behaviour was broken and things were always registered into the store
directory that cabal knew about. (The assertion in
`ProjectBuilding.UnpackedPackage` was failing (see added test)).

With `--package-db` not being able to modify the location of the store
directory then the interaction of `--package-db`, `--store-dir` and
`--dist-dir` flags become easy to understand.

* `--package-db` modify the initial package database stack, these
  package database will not be mutated by cabal and provide the initial
  package environment which is used by cabal.
* `--store-dir` modify the location of the store directory
* `--dist-dir` modify the location of the dist directory (and hence
  inplace package database)

Treating the flags in this way also fix an assertion failure when
building packages.

Fixes #9678