Detect duplicate non-cyclical project imports

[philderbeast]

A follow on from #9578. Uses an IORef to better report on duplicates (including cycles) and to detect duplicates that are not cycles. This was originally included in #9578 but punted at review, #9578 (comment).

• 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.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[sebright]

@Mikolaj Do you know if there is someone else who could review this pull request? This followup change doesn't really affect the dependency solver, and I'm currently focusing on #9743.

[philderbeast]

@TeofilC I'm inviting your review as cabal could perhaps be enhanced to output a list of files imported from a project in the future for use by other tools, input-output-hk/haskell.nix#2144 (comment).

[Mikolaj]

@alt-romes: could you maybe have a look?

[Kleidukos]

Looks like you may need to rebase on master so that the changes specific to #9578 don't appear anymore? At least the changelog entry for it is extraneous here. :)

[philderbeast]

Thanks @Kleidukos for pointing out the stray changelog entry. Rebasing didn't clear it so I deleted it and then squashed related commits.

[gbaz]

@GrayJay do you have time to review this?

[philderbeast]

@gbaz and @GrayJay, I've rebased and squashed this. It is now ready for review.

[sebright]

This change was split from #9578. When I was reviewing #9578, I disagreed with the duplicate project imports error because it wasn't clear to me that it should be an error (I don't think that duplicate non-cyclic imports cause build problems, and it is possible that existing projects are using them intentionally.), and it didn't seem worth the complexity of an IORef. This new PR is mostly outside of the solver, so I'll defer to others who are more familiar with project files.

[Kleidukos]

@philderbeast Great PR, I like that we are tackling this behaviour. I will join @GrayJay in that introducing a breaking change in cabal-install is not desirable without proper communication. Could you please open a wiki page based on this template: https://github.com/haskell/cabal/wiki/Deprecation-Process to set the timeline for full deprecation of this behaviour. Please ask questions if you have them. In this case, since we do not intend to replace the feature but deprecate it, no replacement is needed.

[philderbeast]

set the timeline for full deprecation

@Kleidukos, I've read the wiki and it is unclear to me what the following means:

we follow a timeline of 4 releases

Are we talking the x.y of cabal-x.y.z.p or the x.y.z? Is this going to take months or years?

[Kleidukos]

@philderbeast Sorry for the late answer! Indeed this can be confusing. We mean major versions, so X.Y (epoch.major). At a rate of 2 major releases per year, this is something like 2 years maximum.

[Mikolaj]

Anything I can do to help review/revamp this and so save this fine PR?

[Mikolaj]

A very kind ping!

[philderbeast]

Closing in favour of #10933 which is much the same but issues a warning instead of an error.