Skip to content
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

Idea: Separate purs compile flags somehow #353

Closed
googleson78 opened this issue Aug 1, 2019 · 3 comments · Fixed by #366
Closed

Idea: Separate purs compile flags somehow #353

googleson78 opened this issue Aug 1, 2019 · 3 comments · Fixed by #366
Labels

Comments

@googleson78
Copy link
Contributor

What do you think about separating flags passed to purs compile explicitly in some way, for example with --purs-compile-flags=?

Right now --help says you should use -- if you want to specify that something should go to purs compile, but what really confused me is that it is not mandatory to separate them with --.
Running spago build src/X.purs src/Y.purs works fine - which is not immediately obvious when looking at spago build --help (it has no mentions of files as arguments).

This was especially problematic when I tried spago build --watch --path src/**/*.purs, only to see how not all of my files were "being watched". In reality only the first file from the expanded glob is being watched, because --path accepts only one file - the rest are passed onto purs compile, allowing compilation to proceed without errors (or at least that's what I think is going on here).

@googleson78 googleson78 changed the title Idea: Separate purs flags somehow Idea: Separate purs compile flags somehow Aug 1, 2019
@f-f
Copy link
Member

f-f commented Aug 1, 2019

Yeah this sounds like not the ideal behaviour. I'd say we'd want to keep the -- thing instead of adding this to a flag, but I wonder if we can enforce it somehow? (My optparse-applicative-fu is not good enough to answer this)

This is the code for the passthrough stuff:
https://github.com/spacchetti/spago/blob/2d349cc7c1ce02769688e136bdf9a3939c04ed35/app/Spago.hs#L168

@googleson78
Copy link
Contributor Author

googleson78 commented Aug 1, 2019

According to man bash (on my machine) the semantics of -- is "there will be no more options" (as in "strings that start with a dash are now treated as normal arguments").

optparse-applicative docs also match this - it treats everything after -- as an argument.

However, parsers always accept a special argument: --.
When a -- is found on the command line, all the following words are
considered by argument parsers, regardless of whether they start with - or not.

To me it seems like we can't (and possibly shouldn't) force these arguments to be passed after the --.

It would be possible to use noIntersperse forcing all arguments to be at the end, but to me this is a greater cost to UX, compared to adding an option.
It would also still be quite confusing when paired with --path at the end (not resolving my original case).

@f-f
Copy link
Member

f-f commented Aug 5, 2019

@googleson78 great points. We already have the behaviour you suggest in your first post for the node arguments, so introducing it for purs arguments too wouldn't be a too big deal, if we "absorb" into spago interface the most common ones (e.g. as we do for spago docs --format)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants