-
Notifications
You must be signed in to change notification settings - Fork 585
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
New (backwards compat) CLI for FAKE that includes FSI cmd args passing #455
Conversation
* New CLI for FAKE that uses UnionArgParser. * If new CLI cannot parse, use old CLI for backwards compat. * Strongly typed and easy to read and modify. * Less brittle in face of changes needed for fsprojects#438 etc. * Generates documentation. * Supports combination with app.config settings. * Support long and short switches (e.g. --version or -v). * Support multi-values (e.g. --envVar key value --envVar key value). * Make env flag switches explicit (i.e. --envFlag nameWhoseValWillBeTrue). * Print old and new help.
Conflicts: src/app/FakeLib/FSIHelper.fs
This looks pretty cool. The build script arg in first position is actually used very frequently. Especially from a cmd prompt. Think of things like "fake clean" or "fake test". |
Thanks for the feedback. I'll update the PR with support for the positional, non-switch arguments (and fix up the target usage). |
* Update usage documentation strings and usage print function. * Add basic tests for CLI positional argument parsing.
@forki I've added back support for the positional arguments. You now have:
I've updated the PR description with a new image and current switches. I've also added a few simple tests. I didn't create a new test project, but added them (and ref to fake.exe) in the FakeCore test lib. Hope this is OK. It appears the build is failing, so I'll have a look at that. |
The build does not like the DU field names I've used on FsiArgs. Guessing this is some Mono F# build version/support issue... |
It's probably not supported in the F# version which is used by mono. I don't know if we can change that version. |
I'll remove the usage for now then. |
Building. I'm not planning on doing anything else on this for now. Think it is good to go, so will await the feedback! |
New (backwards compat) CLI for FAKE that includes FSI cmd args passing
I'll release a prerelease version and check our build infrastructure against this. |
Great, thanks! Glad to finally start putting something back into FAKE after all the use I have had from it. |
I see the problem. I handle |
thanks for fixing. next cool step would be to improve https://github.com/fsharp/FAKE/blob/master/help/commandline.md - are you interested? |
Yes, I will do this. OSS without good docs is not good OSS! |
Wonder what the world would be like if PRs got rejected without good docs... |
BTW - did you see this nice Markdown extension for VS? http://visualstudiogallery.msdn.microsoft.com/0855e23e-4c4c-4c82-8b39-24ab5c5a7f79 |
Then we would probably have no OSS at all. |
Maybe, maybe :) |
Do you think |
sounds good |
While working on #438, I realised that the feature would make the existing FAKE command line brittle. The existing code looks for argument strings regardless of their position or relation to switches. Adding support for passing arbitrary string args to FSI, could easily break this. Therefore, I have added the support I needed for #438 and created a new CLI for FAKE that I think will be much easier to understand and extend in the future. I hope you agree. If not, I would be happy to discuss and fix an concerns.
This PR makes FAKE.exe dependant on the UnionArgParser library. If figured this would be ok as FAKE includes other assemblies and this one is fairly small and focused. Using it to specify the FAKE CLI args is really clean.
An example usage now looks like this:
fake.exe build.fsx clean --envvar key1 val1 --envar key2 val2
We also support the short switches:
fake.exe build.fsx -ev key1 val1 -ev key2 val2 -ef blah
fake --help
now looks like this:I don't think too much is outstanding, although I appreciate it is important that this is tested well, do we don't break old scripts. If the new CLI args don't parse, we fall back to exactly the same code as before the new CLI, so I hope this provides the safest experience.
TODO:
I appreciate that previously the build script arg was first and did not require a switch. I could add support for this, but thought I would find out how important this is first.Look forward to feedback!