Misspelled user-flags (-f) are silently ignored

[andreasabel]

Misspelled user-flags (-f) are silently ignored. In the wild:

$ cabal install -w ghc-9.0.1 cabal-plan
...
$ cabal-plan license-report fix-whitespace 
ERROR: `cabal-plan license-report` sub-command not available! Please recompile/reinstall `cabal-plan` with the `license-report` Cabal flag activated.
...
$ cabal install -w ghc-9.0.1 -f licence-report cabal-plan
Resolving dependencies...
Up to date
Copying 'cabal-plan' to ...

$ cabal-plan license-report fix-whitespace 
ERROR: `cabal-plan license-report` sub-command not available! Please recompile/reinstall `cabal-plan` with the `license-report` Cabal flag activated.

Swallowing errors: not a good UI.

[phadej]

This is tricky. What if a version of package doesn't have (an automatic) flag. Should it be omitted by a solver? What if there is a package in the transitive dependency tree which uses licence-report spelling?

I think you ask for a feature, which is not yet described precisely.

[andreasabel]

The documentation is a bit scarce, I found these pages:

• https://cabal.readthedocs.io/en/latest/setup-commands.html#controlling-flag-assignments
• https://cabal.readthedocs.io/en/latest/cabal-package.html#resolution-of-conditions-and-flags

From there, I could not understand the concept of flags completely.

What if there is a package in the transitive dependency tree which uses licence-report spelling?

My natural assumption is that if I pass -f{+|-}foo then this flag foo is set for the main package that is the target of the build. I also assume that if I want to pass a flag to a dependency, I need to qualify it accordingly. Is this assumption correct?

Under the correctness of my assumption, it would not matter if some dependency accepts the miss-spelled licence-report as I would have to qualify it for that dependency to pick it up.

What if a version of package doesn't have (an automatic) flag [?]

This is more tricky. So the set of valid flags for a package depends on the version of that package. We can be conservative and take the union of all flags that have existed and exist now for this package. This would still allow me to catch most misspellings.

Nonwithstanding the exact workings of flags, this improvement should always work:
If a flag passed by the user is never looked at during configuration, a warning is emitted.

Warning: flag '{+|-}foo' did not affect this build.

(This is a bit comparable to a unused-import-warning in a compiler.)

However, I would think scoping of flags can be exploited for a firmer error report.

[phadej]

My natural assumption is that if I pass -f{+|-}foo then this flag foo is set for the main package that is the target of the build. I also assume that if I want to pass a flag to a dependency, I need to qualify it accordingly. Is this assumption correct?

Hmm. Seems so that -f applies only to local packages. So your assumption is correct.

But this drives me nuts as --ghc-options applies to all packages. This is inconsistent, so I don't have any intuition about cabal-install command line interface anymore.

[ulysses4ever]

Seems so that -f applies only to local packages...
But this drives me nuts as --ghc-options applies to all packages.

Not anymore: #3883 (comment)

[philderbeast]

I have another example but this time for a flag no longer used by a package. I'd like to be warned about obsolete flags.

I tried to build haskell/cabal@976f86/cabal.project with stack (after generating the equivalent stack.yaml project) and it warned that these doesn't have an assoc flag. Browsing hackage/these, I see this package used to have an assoc flag in assoc >=1 && <1.2 versions but not in assoc ==1.2.

$ git log -1
commit 976f86ab67952d377c25f19e6a2594e0000900a2
...

If I do cabal freeze I see:

active-repositories: hackage.haskell.org:merge
constraints: any.Diff ==0.5,
...
                      any.these ==1.2,
...
index-state: hackage.haskell.org 2023-11-09T18:29:02Z

For comparison, here's stack's full warning:

Error: [S-8664]
       Invalid flag specification:
       * Package these does not define the following flags
          (specified in the project-level configuration (e.g. stack.yaml)): assoc.
         No flags are defined by package these.
make: *** [updo/Makefile:100: stack.yaml.lock] Error 1

[phadej]

@philderbeast your example illustrates why miss-spelling a flag should never be an error. these-1.2 removed the assoc flag, as there were no use for it. Such change should not break builds. Having a warning is fine.

Also -f semantics in cabal are bad (fine for ./Setup, bad for cabal-install). They apply to all packages. If it were package specific, i.e. -fcabal-plan:license-report, then there are more options:

• warn if not available
• or/and restrict version ranges to packages with the flag

In stack flag specification is per-package. (In cabal we can also, with constraints or in cabal.project package sections, but AFAIK we cannot on the command line).

---

FWIW, this is another example where I think that cabal-install CLI interface should be completely separate from ./Setup ones. Trying to have the same CLI API, but tweak it from exactly-one-package to a project wide just causes huge impedance mismatches. stack is definitely better in that regard, as their CLI interface started from scratch. v2-build missed an opportunity.

[andreabedini]

💯 agree with @phadej. I am afraid separating the CLI will take some work but perhaps there's a quicker way to parse per-package flags?

There is also the issue that project config goes through the legay SavedConfig so I won't hold my breath; but I'm happy to advice if anyone wants to take on this.

[gbaz]

To be clear, one can specify flags per-package on the command line, through the Setup.hs interface even, by passing flag settings via constraints rather than -f

https://cabal.readthedocs.io/en/stable/setup-commands.html#cmdoption-runhaskell-Setup.hs-configure-constraint