What should we report when there are duplicate imports?

[philderbeast]

What should we report when there are duplicate imports?

Is it acceptable that there are duplicates reported for configuration, such as the 5 times for - yops/yops-9.config with the project added in #10508?

$ cabal run cabal-install:exe:cabal -- build --dry-run \
  --project-file=cabal-testsuite/PackageTests/ConditionalAndImport/yops-0.project
Warning: this is a debug build of cabal-install with assertions enabled.
When using configuration from:
  - yops-0.project
  - yops-2.config
  - yops-4.config
  - yops-4.config
  - yops-6.config
  - yops-6.config
  - yops-6.config
  - yops-8.config
  - yops-8.config
  - yops-8.config
  - yops-8.config
  - yops/yops-1.config
  - yops/yops-3.config
  - yops/yops-3.config
  - yops/yops-5.config
  - yops/yops-5.config
  - yops/yops-5.config
  - yops/yops-7.config
  - yops/yops-7.config
  - yops/yops-7.config
  - yops/yops-7.config
  - yops/yops-9.config
  - yops/yops-9.config
  - yops/yops-9.config
  - yops/yops-9.config
  - yops/yops-9.config
The following errors occurred:
  - The package directory '.' does not contain any .cabal file.

#9933 would reject duplicate imports.

[geekosaur]

As a C programmer, I'm somewhat inclined to take the C #include stance: multiple imports allowed, but imports must be idempotent. But that just kicks the can up the road, because at present I don't think there's a way to make a project file idempotent. It also could be argued that this is a reaction to how cpp works, and something more/differently principled is more appropriate.

[philderbeast]

We don't want anything like include guards or #pragma once, do we?

[geekosaur]

no, I think the more Haskelly way is ensuring that importing multiple times can't change the outcome regardless of its contents, and otherwise not worrying about it. If I import two project files each of which import the same other project file, it should behave just like that third file had only been imported once. (I think this is already true?)

The other side of this, which is why I go toward the C route, is that every include/import is self-contained: I don't need to require the developer to "just know" that something else must be imported first for it to work. This requires idempotence as a consequence, since two "self-contained" imports may pull in the same "dependency".

[philderbeast]

If we were to separate the reporting of duplicates (as warnings) from the "When using configuration from" message then the output could be trimmed to:

$ cabal run cabal-install:exe:cabal -- build --dry-run \
  --project-file=cabal-testsuite/PackageTests/ConditionalAndImport/yops-0.project
Warning: this is a debug build of cabal-install with assertions enabled.
When using configuration from:
  - yops-0.project
  - yops-2.config
  - yops-4.config
- - yops-4.config
  - yops-6.config
- - yops-6.config
- - yops-6.config
  - yops-8.config
- - yops-8.config
- - yops-8.config
- - yops-8.config
  - yops/yops-1.config
  - yops/yops-3.config
- - yops/yops-3.config
  - yops/yops-5.config
- - yops/yops-5.config
- - yops/yops-5.config
  - yops/yops-7.config
- - yops/yops-7.config
- - yops/yops-7.config
- - yops/yops-7.config
  - yops/yops-9.config
- - yops/yops-9.config
- - yops/yops-9.config
- - yops/yops-9.config
- - yops/yops-9.config
The following errors occurred:
  - The package directory '.' does not contain any .cabal file.