Add an explicit purs args flag

[googleson78]

Description of the change

Add an explicit flag for arguments passed over to purs as per #353. Fixes #353

I am not sure about the short flag name, but everything that immediately comes to mind is already taken.

Checklist:

• Added the change to the "Unreleased" section of the changelog
• Added some example of the new feature to the README
• Added a test for the contribution (if applicable)

[thomashoneyman]

Quick question -- does this work with a string containing an arbitrary number of arguments to pass to purs, like this?

spago build --purs-args '--verbose-errors -o outputDirectory'

[f-f]

Thinking more about this maybe it'd be better if we:

• just remove the passthrough arguments
• absorb into spago the most used purs compile flags

This is because adding this flag wouldn't make it any easier for us to control what's being passed to purs, while controlling it would help us greatly in fixing #216 and #355 (because duplicate flags make purs fail with a bad error message)

So I'd propose that instead of adding the --purs-args flag we'd close this escape hatch and add the following flags to the BuildOptions:

• -o,--output
• -v,--verbose-errors
• -g,--codegen
• --json-errors

However, if we do the change I propose above then we'd totally cut away the psa flags, so we cannot really go for it..

Also this last item on the list made me realize that all of this is potentially a big breaking change for editor tooling, because instead of spago build -- --json-errors you'd have to instead call spago build --json-errors or spago build --purs-args="--json-errors" (cc @nwolverson, does this make sense?)

So in the end I think we should not change anything at all here, as there are more things relying on all of this than what we initially thought

[nwolverson]

Editor tooling - from my POV that's just a config change, so it's a change anyone using that setup would have to make. Personal opinion, wouldn't use that as a deciding factor.

Would say that if you "close the hatch" it's kind of committing to supporting all compiler flags, though I guess that's not too bad if you have a higher release cadence

[googleson78]

tl;dr - I think disabling passthrough is too restrictive, whereas passing all non-parsed spago arguments to purs makes it too easy to shoot yourself and not get feedback on what you did wrong.

Long -
I think of passthrough arguments as a "patch" that eventually disappears when you can do at least 100% of what the compiler. But it is also highly idealistic to think you will ever get to that point, because of the ever-evolving nature of the compiler. Even if you were to support all the compiler flags you would end up having to invest a lot of time into implementing dummy option passing, that your build system is not interested in at all. So 👎 for removing it from me.

Adding those flags to spago will definitely help with issues like #216, because people will have less (no) reason to use purs directly for their functionality. And to me the passthrough is "have this gun, point it wherever you want (including your own feet)" - people can always pass something incompatible with spago. And that's why I think it should be explicit, and not an implicit thing.

(sorry for this reply being all over the place)

[justinwoo]

I hate the -- style args in any tool I use, so I really like passing the args explicitly 👍 But yes, I think there's no way all passthroughs should be removed, because this makes it so that using the tool in any non-cookie-cutter way becomes a total nuisance, to the point of needing to abandon the tool.

I'd rather support both modes of operation between --purs-args and -- for a while though, and if it's not a problem, just keep them. Maybe some see this as the worst option though. I would also think that adding those aliases for the most common commands would be nice enough, since any additional usages should be supported via --purs-args or --.

[f-f]

Alright, then I'd say we can go for adding this flag and removing the passthrough (as this PR implements) 💯

And we should definitely support some common properties, like --output, though in that case we'll really need actual parsing of the content of purs-args because the compiler doesn't like duplicate flags (so we wouldn't be able to pass --output from spago and from the additional args, this is exactly the problem in #216). Anyways we don't have to worry about all of this in here.

So I'll merge this, thanks @googleson78!

[googleson78]

Uh.. not sure if this is my fault?

[f-f]

@googleson78 no it's not, see #378