Flags for dependencies

[clintonmead]

This is kind of a feature request, but I was planning to do the patch myself, but I'm seeking advice about whether this is worth me contributing or is just a dumb idea I shouldn't even attempt.

My idea is that you could add flags to dependencies. For example, instead of just

blah >= 2.0

You could do:

blah(aflag) >= 2.0

When compiling a package dependency, all the flags will be collected together and then passed as if they were passed directly on the command line.

Packages will be recompiled under the following two circumstances:

1. The version is changed (as currently) OR
2. A flag is required which is not in the currently compiled version

I realise that package authors could use this feature to break things, but package authors have to be largely trusted anyway, as they can upload executable code. The primary use case I've got in mind currently for this is to avoid orphan instances without huge lists of dependencies being the result, but there may be other uses. These flags would trigger additional dependencies in the cabal file and instances in the code only when they are explicitly required.

My question here is this sometime that's worth my time having a go at or is it a monumentally stupid idea that I shouldn't even attempt to write a patch for? And if the former, any tips? And if the latter, why not and are there any alternative solutions?

[hvr]

Variants of this has been suggested every now and then that we should have a FAQ by now :-)

The gist is that flags are not supposed to be local to .cabal files and not supposed to be addressable directly by other .cabal files. That's been a deliberate choice (I'd need to search the issue tracker to find the relevant discussion).

Also, your suggestion doesn't seem to take into account the solver at all. It sounds like you suggest to have the logic apply after the solver has already picked a configuration, and then handle the flag dependencies late during the build-phase, at which point it may easily invalidate the solved plan (but the solver cannot backtrack anymore).

As for addressing the orphan instance problem, there's other ideas on the table to address that, including #3061 (provides-mechanism), companion packages and/or multi-library packages combined with injected instance imports etc, that have imho more desirable trade-offs than a flag-based scheme.

EDIT: See also discussion in #2821 (comment) regarding cabal flags in .cabal files

[clintonmead]

Perhaps it does need an FAQ

You've mentioned a number of alternatives:

1. "provides-mechanism"
2. "companion packages"
3. "multi-library packages + injected instance imports"

I'd appreciate it if you could outline how at least one of these avoids orphan instances whilst not requiring dependency compilation for users who do not need such instances?

[23Skidoo]

Proposal for provides-mechanism is #3061. Leaving this open for now to remind us to write that FAQ entry.

[gbaz]

The main use case is partially handled by project files allowing flag settings on deps, which isn't perfect, but does give some further control. Closing this ticket now because whatever "faq entry" was planned doesn't seem in scope any further.