Toggle --windowed on/off

[fredrikaverpil]

Feature request: it would be useful to actually allow some applications to be frozen with --windowed , but also allow other applications to show this window. Could you add an option somewhere for this?

EDIT: I may add that when you produce binaries using setup.py (when bundling a .whl), you get the option to make such binaries run as console_scripts (windowed) or gui_scripts (not windowed). In my past experience, I've actually had some issues with some Python scripts using PySide and being renamed to ".pyw" (Windows feature only), which will cause them to run in a non-windowed mode. I'm not sure how related this .pyw approach is to the setup.py or PyInstaller approach though.

[mherrmann]

Interesting question. fbs currently "configures" PyInstaller by passing arguments to it on the command line. Another approach however are Spec Files. These are basically separate files for configuring PyInstaller.

What's really interesting? The page linked to above mentions "creating multiprogram bundles with merged common modules". That sounds exactly like what you want to do in fbs-tutorial/#9!

It makes me think that the best approach would be to switch fbs to using Spec Files, and including a default Spec File as part of fbs-tutorial. Then, you could edit this file to change the --windowed flag or create multiple binaries for an application.

What do you think, in particular of the documentation of Spec Files? I personally haven't used them. Would you be comfortable editing them?

Cheers :-)
M

[fredrikaverpil]

Ooh. Interesting! I need to read up on this, but my initial response is yes - this seems to allow for a lot of useful customization.

I see the multibundle stuff is currently broken though: pyinstaller/pyinstaller#1527

[mherrmann]

I see :( pity

[fredrikaverpil]

Hi again Michael!

I used to monkey patch the freeze_windows so that I was able to omit the --windowed PyInstaller option but then stopped doing this because of having to maintain this patch. I offered my app to users without this console. The user feedback I received was that this console window was dearly missed and provided insights into what was going on with the application at certain times. My app is an internal production tool which is not made for "the average consumer", but rather for 3D graphics specialists.

So, I'm now back, forced to maintain a patch of the freeze_windows function. Do you still feel that there is no way I can define e.g. in the settings that I wish to run my application with the console and that my only option will be to maintain this patch?

Just to provide a proposal, how do you feel about the following change in windows.py?

    if not debug and not SETTINGS['force_console']:
        # The --windowed flag below prevents us from seeing any console output.
        # We therefore only add it when we're not debugging.
        pyinstaller_args.append('--windowed')

I could then add force_console: true to a windows.json if we added support for that. I could whip up a PR in no time if you feel this is a viable way forward.

[fredrikaverpil]

Hm. Regarding PyInstaller spec files, as you mentioned further up above here, would that be better to look into, and possibly load using the settings?

I'm open to any solution which basically offers me greater flexibility with PyInstaller but not having to maintain too much patches to your original code.

[mherrmann]

Hi Fredrik,

you may find this an unrelated question, but please bear with me for a second: Are you still using the extra_pyinstaller_args parameter to freeze_windows/freeze_linux, etc.?

[fredrikaverpil]

No, I'm not. I am just removing the --windowed argument.

I have previously found myself overriding extra_pyinstaller_args but went great lengths to avoid doing it by restructuring code in a way which is somewhat undesired. Eventually, I would want to add to extra_pyinstaller_args but currently not doing that.

[mherrmann]

Thanks.

went great lengths to avoid doing it by restructuring code in a way which is somewhat undesired

In which way is the new structure undesired?

Eventually, I would want to add to extra_pyinstaller_args

What would you like to add there?

[fredrikaverpil]

In which way is the new structure undesired?

Could be a corner case because I am also offering my app as a wheel for headless installs.

• I have my main app in src/main/python and I am freezing this into a standalone app using fbs.
• I have a setup.py in src/main/python which I use to build a wheel out of my package. So, let's say this will generate app-3.0.0-py2.py3-none-any.whl. This wheel is used for headless installs of my app.
• I am vendoring a number of third party packages which my app imports as from packagex import something, as if the third party packages would have just been installed with pip into the venv, like any non-vendored dependency is installed. I do not wish to import using e.g. from vendored.packagex import something, as I might not have to vendor some packages down the line when they have certain PRs merged or patches applied etc.

Ideally, I would've wanted to put all vendored packages in a separate directory and pass this extra path to PyInstaller via extra_pyinstaller_args. But instead, I now keep them directly in src/main/python to allow for the type of import syntax I want. This causes my wheel to not only install my package ("app") into a site-packages but it will also install these third party packages into the site-packages folder.
This is undesired behavior, as it is only my app which is meant to use these vendored versions of these packages and there is a chance of conflict if the site-packages folder already contains a regular install of the third party package ...

What would you like to add there?

I think that it mostly comes down to extra paths. Meaning, something similar to adding to sys.path for pure Python modules.

[mherrmann]

Okay. Thank you for clarifying. I just released fbs 0.4.4 that adds a show_console_window setting like you suggested.

I also removed the extra_pyinstaller_args parameter from the various freeze_... functions, because neither you nor anybody else was using them.

[fredrikaverpil]

Excellent, thank you so much for this!

I noticed that in your changelog, you mentioned that this doesn't do anything on Linux. I wonder if this really does anything on macOS either, as I was under the impression you can only suppress the console on Windows ...or am I wrong here? (I don't have a mac to test this on right now)

[mherrmann]

I'm happy if I can help while also keeping fbs's API consistent!

To be honest, I don't know about Mac. I added it there because the PyInstaller docs say that the --windowed command line parameter is also available there. And fbs uses it.