-
Notifications
You must be signed in to change notification settings - Fork 691
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Leading dashes in flag names #4686
Comments
There is no reason to disallow sequential separators, but we will disallow (because it's confusing) and discourage non ascii characters (cabal check), i.e. effectively making flag parser Note: flag names are case-insensitive. |
"There is no reason" is not a true statement. It may be your opinion, but there are certainly reasons. One reason: the disparity between flag and package name syntaxes is confusing. You may think such confusion is warranted, but please don't imply that I have no reasons for making my request. Thank you! |
I understand that it would be more elegant to have I'd turn this issue around, the package name is special, others not so:
But there's no reason to disallow writing, it might be silly, but someone might want to do so.
We can *discourage**double dash in flag names, via |
@phadej I'm having a difficult time discussing this with you, as you are repeatedly telling me that there's no reason for this, despite the fact that I've told you otherwise. If you're telling me that, in fact, this decision is not open for discussion and you are making a call without allowing my to have any input, then please clarify. Stating that my reasons do not exist is not appropriate. |
Is there any technical reason to disallow Background: The issue with cabal/Cabal/Distribution/Types/GenericPackageDescription.hs Lines 137 to 153 in 267efc8
[a-z0-9_-]+ , disallowing leading - (check ). I'm fixing this as part of #4654, by writing current behavior in the spec.
Library support: I'm working on |
To be clear: |
Fwiw, I don't even see much of a big deal either regarding leading hyphens (and that's though it was me who originally brought up the suggestion to discourage leading hyphens in flag names). My rationale for suggesting to discourage the use of leading hyphens in flag names is not so much a technical one (there's always a way to non-ambiguously express But as for sequences of dashes or underscores or a flag name made up of a sequence of |
Given that my reasons have been rejected until now, I'm not sure what I can say that will pass your bar of "technical reason." So let me turn it around: you're currently tightening the restrictions on flag names; what technical reasons do you have for that? |
FTR, I'm okay with this, but we should check that there are no |
@snoyberg you propose tightening the restrictions on flag names, not we. Cabal check warning about unicode is indeed subjective (And I could actually add it for package names as well). Leading dash is exactly what you proposed. |
Quoting you above:
Perhaps I'm misunderstanding you, because that comment stated you wanted to disallow non ascii characters. If you mean that you just want to add a warning for that, that's fine. If your argument is that banning previously valid flag names breaks backwards compatibility (not explicitly stated, but somewhat implied above), that's a discussion to have. As I see it:
|
For the whole time I was talking about cabal check warning. I do mention
|
Can you please briefly summarise what the problems are here? |
EDIT: I was confused, you can declare
|
Edited my previous~2 comment. |
Just chiming in to say that these differences between Hackage and Cabal are annoying to deal with. It means we end up with the actual standard (although there's no standard in this particular case) as well as the de facto standard on Hackage. This has happened before with the PVP: haskell/pvp#4 (comment) |
@tfausak note, that this issue is partly invalid. You could declare The only PVP |
I brought up the PVP issue because it's an example of the actual spec (PVP) not matching the spec in practice (Hackage). I dislike situations like that and would like to avoid it here. Currently Cabal's flag parser matches I think this is a problem because it would be reasonable for, say, Stack to implement a Cabal flag parser that matches the de facto Hackage spec. But then a user could try to make a flag like |
Please elaborate how Hackage practices and PVP disagree?
…Sent from my iPhone
On 14 Aug 2017, at 18.46, Taylor Fausak ***@***.***> wrote:
I brought up the PVP issue because it's an example of the actual spec (PVP) not matching the spec in practice (Hackage). I dislike situations like that and would like to avoid it here.
Currently Cabal's flag parser matches [-_\p{Letter}|\p{Number}]+. The proposed solution to this issue, #4687, tightens that parser but only for cabal check. That means the Cabal flag "spec", such as it is, allows flags that Hackage rejects.
I think this is a problem because it would be reasonable for, say, Stack to implement a Cabal flag parser that matches the de facto Hackage spec. But then a user could try to make a flag like --⓪__א__⓪-- in a private/local package, see that it fails in Stack, and complain.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
So, to summarise:
|
From the linked issue: The PVP allows For this issue: Cabal allows |
Yeah, I've long wanted to fix the |
Only two packages have flags that run afoul of @snoyberg's proposed new rules:
No flag has any non-ASCII characters. In other words, every flag matches I got this information from this script: https://gist.github.com/tfausak/009829dc73386b0779a822b4137cba18/3eb1319662f3c214c6c75057a603757347c81543 |
And the reasons are in #3515 (comment). FWIW, if @tfausak wants to fix PVP, you should open a PR for https://github.com/haskell/pvp about what precisely B MUST be greater means, when Bold is absent. I did open the original issue (haskell/pvp#4) but I lost steam to proceed. |
I fully understand the PVP problem already. I only brought it up as an example of the actual spec (PVP) not matching the de facto spec (Hackage). I don't want to derail this thread; let's stay focused on Cabal flags. |
@23Skidoo To be honest, I don't see any benefit of arbitrarily limiting the lexical syntax to begin with. Usually the burden of proof lies with the party that proposes the change, and I haven't see any compelling reason to impose this arbitrary limitation so far. In fact, any arbitrary exception we add makes the regexp only more complex. Initially the regexp was assumed to be |
It sounds like this ship has already sailed, but I'll say it again: I think that having the actual spec (the Cabal file format) differ from the spec in practice (Hackage) is a bad idea. Obviously there's some benefit in restricting flag names, otherwise #4687 wouldn't exist. Why not codify that in the spec rather than allowing it locally but rejecting it on upload? I also disagree with this appeal to regex simplicity. Why not match tags with |
To clarify, I don't feel very strongly about this stuff, and am fine with keeping I also find @tfausak's point about keeping Hackage-accepted and Cabal-accepted formats as close as possible persuasive (though this is not always possible because of historical reasons, like with the |
I see that @phadej merged #4687, which checks for invalid flags with Regardless, it seems like this issue should be closed as wontfix, based on the comments so far. |
Meta: this issue is Leading dashes in flag names, so technically this issue is fixed. Every other change would benefit from being a separate issue. |
But... it's not fixed. #4687 (comment):
This is the Cabal issue tracker, not the Hackage issue tracker. |
I'd accept a patch that did that. |
@tfausak that comment is outdated. See https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Parsec/Class.hs#L129-L134 |
@tfausak, yes, sometimes speed of Cabal development surprises us!
btw, Could you add |
OK, since the main issue here (leading dashes in flag names) has been resolved, I'm closing this as fixed; if anyone wants to also disallow leading underscores and trailing separators, please create a PR and we'll discuss it there. |
This flag name was changed without comment in 6e1ff78. It has caused a few problems: - commercialhaskell/stack#3345 - commercialhaskell/stackage#2755 - commercialhaskell/stackage#2759 - commercialhaskell/stackage#2842 - haskell/cabal#4686 - haskell-hvr#150 Those problems either caused or accelerated some (attempted) changes in Cabal: - haskell/cabal#4654 - haskell/cabal#4687 - haskell/cabal#4696 Those problems also caused a change in Stack: - commercialhaskell/stack#3349 In short: Cabal never had any trouble with this. Stack did. The current master version of Stack can handle flags like this, but no released versions of it can. It's not clear when the next version of Stack will be released. In the meantime, no Stack users can use this package. This commit changes the offending flag to something that Stack can handle. By using a flag that Stack can handle, Stack users can once again use this package, and it can return to Stackage. There are no apparent downsides to using a more compatible flag name.
After a discussion on the Stack issue tracker, it was revealed that the Cabal flag name requirements are rather lax, and currently seem to allow both sequential separators (- and _), as well as leading and trailing separators. For example, this command line works just fine:
NOTE: this is using:
However, it's unclear how to set this from the command line to either true or false. If I add this line on its own to my cabal file:
I see the following in my shell session:
As you can see, ultimately the double-leading-dash was able to disable the flag, but no combination of + and - I tried enabled the flag.
My recommendation: strengthen to parser to behave like the package name parser, disallowing leading, trailing, or sequential separators. Next best thing: remove leading separators.
The text was updated successfully, but these errors were encountered: