Make command-line options accessible within spec file

[sveinse]

I have an application that I'm building twice: a onefile version and a onedir version. The spec files for doing this are very similar, but there are some differences. E.g. onedir calls EXE and COLLECT, while onefile calls EXE with some other options.

Is there a way I can programmically detect the --onefile or --onedir command-line option in the spec-file code? This way I would only need to maintain one spec file.

[danyeaw]

@sveinse I don't think this is currently a supported feature.

[htgoebel]

Interesting point. You should at least be able to access sys.argv from within the .spec-file.

If you think, this might be useful for other, to, I suggest to implement a more generic solution and provide a pull-request.
You could add an element ARGUMENTS (name to be discussed) to the namespace of the spec-file (like there are currently e.g. PYZ, EXE) containing all (or the relevant= command line arguments. For course this need to be documented in the manual, too.

The place to implement this is around https://github.com/pyinstaller/pyinstaller/blob/develop/PyInstaller/building/build_main.py#L642. You would add the new element to spec_namespace.
Most command line-args result into a value in CONF.

I'm lloking forwar for the pull-request :-). See our Development Guide on how to create pull-requests for PyInstaller. Thanks.

[DemiBSel]

I am not sure how this would/should play out with the ArgumentParser rejecting unknown options and now that #6660 prevents non-default option values to be used along with .spec files.
Allowing command-line options would still be a convenient feature to avoid having to choose between multiple .spec files.

[bwoodsend]

What would you do with these extra command line arguments? I can't say I'm excited by the idea that users would then be reporting failing build commands with random user defined arguments involved.

[DemiBSel]

As @sveinse said, this would allow using only one .spec file to bundle one app in multiple ways, enabling the console without modifying the spec file.
Might be made safer if only arguments with a specific prefix are allowed ?

[bwoodsend]

There's always the option to squirt parametrisation in via environment variables.

Might be made safer if only arguments with a specific prefix are allowed ?

That would be less messy. I wouldn't mind that being a feature.

I have this vague idea which I doubt I will ever implement that the spec file should just be a self contained Python script with from PyInstaller import Analysis, EXE, PYZ, Bundle at the top which you'd then invoke with python your-code.spec. It would require purging the hidden CONF class but it would solve this issue because you'd be free to stick your own CLI parser at the top and do whatever you want with the parameters.

[bwoodsend]

What actually is the required scope for this? i.e. How complex is the information you want to get into the spec file? If all you need is some simple string or boolean switches (e.g. --debug-mode=on or --include-some-optional-dependency=true) then this is a lot more achievable than arbitrary argparse-like options.

gradle (a build system) has a -P flag which you can use to pass in string key/value pairs e.g. -Pdebug_mode=1 which makes the variable available in its build scripts. We could have something similar provided that people don't need to pass anything more complex in than that?

[rokm]

What is being asked for in the original request can be readily achieved using environment variables, though: example. (And as a sidenote, passing --onefile or --onedir on CLI when building with spec now raises an error, so trying to infer build mode from CLI arguments in the spec file is rather moot).

I suppose one could pass whole custom/additional command-line string via an environment variable, split it in the spec file using shlex.split() and feed it to argparse, without having to touch PyInstaller's CLI option parsing...

[bwoodsend]

I suppose one could pass whole custom/additional command-line string via an environment variable, split it in the spec file using shlex.split() and feed it to argparse, without having to touch PyInstaller's CLI option parsing...

Well then you've got the joys nested quoting/escaping to navigate. I'd rather use something that's at least semi-platform/shell independent by default.