Show import tree provenance

[philderbeast]

Fixes #9562. This adds the path in the project import tree with the constraint conflict just below the solver's rejecting message (sample taken from the change log entry).

$ cabal build all --dry-run
...
[__1] next goal: hashable
[__1] rejecting: hashable-1.4.3.0
      (<ROOT>/1-web-import-constraints.project requires ==1.4.2.0)
[__1] rejecting: hashable-1.4.2.0
      (https://www.stackage.org/nightly-2023-12-07/cabal.config requires ==1.4.3.0)
        imported by: <ROOT>/1-web-import-constraints.project

Important

The way imports worked changed between cabal-install-3.8 and cabal-install-3.10. With the earlier version imports were anchored to the project root (relative to a fixed location) but this was changed to make them relative to their importer. I had to pay close attention to the check for seen imports, something I added tests for. These tests merged already with #9665 and #9680. I've also added verbose logging at the info level so we can see the import we're processing, the seen imports and the import we're fetching.

Because relative imports may contain .. and the only way to resolve this is to use canonicalizePath I had to take an extra dependency on directory in cabal-install-solver. I also needed network-uri to check for URIs and avoid messing with them. I assume that once we import a URI config then imports stop there. Put another way, something imported via https://... doesn't itself import another config. Those extra dependencies we should be able to remove when the suggested change of @andreabedini lands, #9642.

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary. (Can't find "rejecting" in the docs to change).
• Manual QA notes have been included.
• Tests have been added. (I took stripped down tests that I hope to reuse and expand for Override imported package version equalities #9510).

If testing manually, I suggest trying cabal build --dry-run with a simple cabal.project, a project with imports and a bare package with no project. To see the change, a solver rejection will need to be triggered by introducing a version constraint.

Note

I'd tried to use a tree-like layout but settled on a list instead after review.

I used +-- ASCII chars to mark tree nodes (and not the same ones as tree does). Can we use the nicer unicode chars?

$ tree -P 'cabal.project*' --prune -L 1 --charset ascii
.
|-- cabal.project
|-- cabal.project.buildinfo
|-- cabal.project.coverage
|-- cabal.project.doctest
|-- cabal.project.latest-ghc
|-- cabal.project.libonly
|-- cabal.project.meta
|-- cabal.project.release
|-- cabal.project.validate
|-- cabal.project.validate.libonly
`-- cabal.project.weeder

$ tree -P 'cabal.project*' --prune -L 1 --charset utf8
.
├── cabal.project
├── cabal.project.buildinfo
├── cabal.project.coverage
├── cabal.project.doctest
├── cabal.project.latest-ghc
├── cabal.project.libonly
├── cabal.project.meta
├── cabal.project.release
├── cabal.project.validate
├── cabal.project.validate.libonly
└── cabal.project.weeder

[andreabedini]

I think it would be better if we could keep the concept of project configuration outside of the solver, for the sake of modularity and cleaner separation between cabal-install and cabal-install-solver.

I haven't thought about how to do this technically. Perhaps ConstraintSource could be made more polymorphic? In the end, the solver only needs to know whether the constraint comes internally (i.e. from a previous choice during the solving process) or externally.

[philderbeast]

@andreabedini project configuration is already in the solver. I've replaced a FilePath with a simple data type that distinguishes between the root and imported FilePath.

data ConstraintSource =
...
-  | ConstraintSourceProjectConfig FilePath
+  | ConstraintSourceProjectConfig ProjectConfigPath

I had a quick go at making ConstraintSource polymorphic but so many other things depend on it that this would lead to a lot of cascading changes.

What I can do is move some pretty printing functions from cabal-install-solver to cabal-install with cabalism@fc87c29, functions showConstraintSource and showProjectConfigPath.

Does that help?

@grayjay would you want me to move those printing functions out of cabal-install-solver?

[andreabedini]

@philderbeast I know it's already used but we could try to improve the separation between those parts (provided you agree with my assessment, of course).

I spent some time looking at this today and ConstraintSource is barely used in cabal-install-solver. It's only part of FailReason. Adding a type variable for it was indeed a bit invasive since it ends up propagating to Tree, which is used everywhere. But by using existential qualification it seems to be possible to confine the changes to small part of the code. Done that I was able to move ConstraintSource back into cabal-install. I haven't quite finished yet. I'll let you know how it goes.

[philderbeast]

@andreabedini your changes sound promising. Do you have a WIP branch I could look at?

Do you want to raise a separate issue for improving separation between the solver, ConstraintSource and printing failures?

[andreabedini]

@philderbeast I opened #9642 to not block you here.

[philderbeast]

I've fixed the remaining CI problem (@gbaz using project overrides as they currently work ;-)).

[philderbeast]

@grayjay could you please take a look at this? @andreabedini has #9642 that will tease ConstraintSource out of cabal-install-solver separately.

[grayjay]

Thanks @philderbeast!

[philderbeast]

Label merge+no rebase is necessary when the pull request is from an organisation.

[Mikolaj]

Splendid joint work @philderbeast and @grayjay, in particular, in managing the scope of the PR. Agile at its best, though to make it less stressful, ideally a bit of this work could be moved to the planning/design phase in the issue ticket next time.

I think it needs a manual conflict resolution before it can get merged (a change must have crept in during the 2-day merge delay period).

[ffaf1]

@mergify backport 3.12

[mergify]

backport 3.12

✅ Backports have been created

• #9877 Show import tree provenance (backport #9578) has been created for branch 3.12 but encountered conflicts