Cabal flag for bytestring version

[ivan-m]

In 0.5.1.0, you changed the name of the flag from pre-bytestring-0-10-4 to bytestring--LT-0_10_4. Does it make sense to change flag names within the same major version release?

Also, it seems that stack doesn't like this new name:

Could not parse 'stack.yaml':
Aeson exception:
Error in $.flags.cassava['bytestring--LT-0_10_4']: failed to parse field 'flags': Invalid flag name: "bytestring--LT-0_10_4"
See http://docs.haskellstack.org/en/stable/yaml_configuration/

[ivan-m]

Specifically, it seems that the -- in there is what's causing the parsing issue. Not sure why though.

[ivan-m]

It appears stack has already been fixed (albeit not in a release).

Was still a bit of a surprise to see the flag name change.

[hvr]

Does it make sense to change flag names within the same major version release?

Well, Cabal's dependency specification deliberately doesn't allow to depend on flags of dependencies. Moreover, the flag in question was an automatic flag, i.e. you shouldn't even have any reason to manually refer to its name, as it's automatically (hence why it's an "automatic" flag) handled by the build-tool (assuming the build-tool properly implements the Cabal spec). Long story short, flag-names are irrelevant as far as the PVP is concerned.

[tfausak]

See #155.

[ivan-m]

@tfausak I think this issue is slightly different due to the discoverability of the flag name change.

[hvr]

I'll close this one, as I don't see much point in keeping it open. The summary is basically that the flag in question is considered an internal flag which ideally wouldn't even be exposed to the user. It's just a technical implementation detail. It could be any other random string over [a-z0-9_][a-z0-9_-]* changing with every release, it simply ought not matter which particular point in the [a-z0-9_][a-z0-9_-]* space is used, so it's the maintainer's prerogative to choose whichever point in that space they consider appropriate without being put on a show trial for politically motivated reasons.

[ivan-m]

Except it isn't internal only: as soon as you use any build tool except cabal-install (including system packagers like nix) then this flag isn't triggered correctly and the build fails with newer ghc/ bytestring, so in practice you do need to know what the flag is.

[hvr]

Sorry, but then those build tools simply fail to implement an important part of the cabal specification. Almost every well-defined flag I mark as automatic flag (a better name would be maybe be "purely functional flag") is not supposed to be referenced/set externally. It's supposed to be a uniquely inferrable flag from the remaining constraints; in other words, a unique & simple function of the remaining degrees of freedom. That's the primary reason we have this feature in the first place. I would expect this to be very reconcilable with the Nix concept/idea of determinism which I admire.

That being said, I don't intend to change to yet another naming convention in the near future so you don't have to worry about Nix.