--fsiargs switch broken with 3.x usage of FsiEvaluationSession

[bentayloruk]

The --fsiargs switch is broken in 3.x and I'm not sure how best to proceed to fix it (or work around it).

I'm raising this issue as I tried to discuss it with @forki on Twitter and it was too hard :).

In 2.x and before, FAKE ran fsi.exe, which has the following command line:

fsi.exe [options] [script-file [arguments] ] (more details)

The FAKE --fsiargs switch (which I added), allowed us to explicitly specify this fsi command line. It meant we could specify options for fsi (e.g. --checked+), but more importantly (for me) specify arguments for the build script, rather than stuffing them all in environment variables. So, an --fsiargs example might be:

--fsiargs --checked+ build.fsx --myarg someval --myage 41 --etc blah (see FAKE command line Options for more)

In 3.x we directly use FsiEvaluationSession. However, the new version concatenates the fsi options and the script args. When script args are present, the session evaluation fails, as fsi does not recognise my own custom script arguments.

Easy Repro

You can easily repro this by setting the FAKE.exe project Debug Command Line Argument to the following (which would have been fine with 2.x):

--fsiargs test1.fsx --scriptArg a

You will get the error:

FsiEvaluationSession could not be created.
error FS0243: Unrecognized option: '--scriptArg'

My initial fix attempt

I tried to fix by trying to mimic the fsi command line structure. Look at this small diff to see what I did. However, the Run evaluation seems to have different semantics to Evaluate (it does not return execution to FAKE), I get no console output and GetCommandLineArgs returns all the args, not just the script arguments.

I'd really appreciate some thoughts from someone that understands FsiEvaluationSession as to what I should do to fix this. Thanks!

[bentayloruk]

I don't see any easy way to replicate the --fsiargs functionality in FAKE 3. As Don suggests FAKE scripts should not consider the intrinsic fsi object instance to be part of the FAKE API (I agree with this). He also suggests using GetCommandLineArgs. However, calling this will return the raw --fsiargs switch rather than the specific subset of args intended for the script environment.

E.g. --fsiargs checked+ build.fsx --myarg1 --myarg2 --myarg3 will be returned as an array from GetCommandLineArgs which means the script is seeing args not intended for it's use (and it has to understand the --fsiargs format). Previously, it would only get --myarg1 --myarg2 --myarg3.

It would be nice if the script only got the args intended for it. Anyone got a good idea (or do we have to fall back to environment variables only)?

[bentayloruk]

OK. I decided the best bet would be to put these args in their own environment variable. This keeps the subset intact and makes the access explicit. I'll send the PR.