Possible to wrap the python interpreter call in another executable (winpty)?

[sdbbs]

I use Python 3 on MINGW64 on Windows 10, and I just discovered this weird bug (unrelated to PyInstaller)

• https://stackoverflow.com/questions/78342289/very-bizarre-tzlocal-get-localzone-different-output-based-on-python3-aliasing

Basically, if I call my python3, which is alias for winpty python3, I get correct timezone:

$ python3 -c 'import tzlocal; print(tzlocal.get_localzone())'
Europe/Copenhagen

$ winpty \python3 -c 'import tzlocal; print(tzlocal.get_localzone())'
Europe/Copenhagen

However, if I escape the aliasing - either by backslash, or by using full path - I get a wrong timezone:

$ \python3 -c 'import tzlocal; print(tzlocal.get_localzone())'
Europe/Paris

$ D:/msys64/mingw64/bin/python3.exe -c 'import tzlocal; print(tzlocal.get_localzone())'
Europe/Paris

Have no idea how this bug could be solved, but my pyinstaller .exe ends up with the "raw" python, and thus obtains wrong local timezone.

So I thought: it would be an easy workaround, if it was possible to include winpty.exe in the zip on the final pytinstaller .exe, and then instruct pyinstaller to have the build .exe call winpty.exe python3.exe ..., instead of python3.exe ..., when it needs to call the Python interpreter.

Is this possible as some setting in the pyinstaller .spec file?

[rokm]

PyInstaller-built executable doesn't call python3.exe, though - it loads the Python shared library (python3x.dll) and sets up isolated/embedded python interpreter. If it had to call python3.exe from your environment, then it wouldn't be portable at all...

[sdbbs]

I see, thanks for the clarification ... Is there a way, then, to maybe somehow say to pyinstaller, to first run some other executable to set up an environment, and then loading the python3x.dll and the embedded interpreter into that environment? It seems all this has to do with, that winpty sets up a correct TZ environment variable ...

[rokm]

Just run PyInstaller-built executable via winpty? Either again via alias, or via launcher script.

[sdbbs]

Thanks for the suggestion @rokm:

Just run PyInstaller-built executable via winpty?

Just tried that - and it works! Although, now that I'm going through all this trouble to get pyinstaller working, just so I can get 1 (and only 1) .exe file I could run, I'm not really keen on wrapping it in yet another file - I'd therefore rather have it "built-in" the single exe ...

[bwoodsend]

Welcome to customised packaging...

[rokm]

Thanks for the suggestion @rokm:

Just run PyInstaller-built executable via winpty?

Just tried that - and it works! Although, now that I'm going through all this trouble to get pyinstaller working, just so I can get 1 (and only 1) .exe file I could run, I'm not really keen on wrapping it in yet another file - I'd therefore rather have it "built-in" the single exe ...

If you have to rely on a 3rd-party executable to set up your environment for you, then I fail to see how you can avoid running that 3rd-party executable before running the actual program executable. This is exactly the same scenario as you have with python3.exe and its alias.

[sdbbs]

Thanks @bwoodsend - is there a "customized packaging" part of pyinstaller documentation that I could look up?

Anyways, a possible idea is: pack winpty.exe and env.exe from MINGW64 in the packaged .exe as resources; they try using subprocess to call the equivalent of winpty env at start of python program packaged by pyintaller, then try to grep for the TZ variable there ...

[rokm]

Thanks @bwoodsend - is there a "customized packaging" part of pyinstaller documentation that I could look up?

There is no such thing - but the bootloader code is out there, so you are free to tailor it to your use case and wishes.

Anyways, a possible idea is: pack winpty.exe and env.exe from MINGW64 in the packaged .exe as resources; they try using subprocess to call the equivalent of winpty env at start of python program packaged by pyintaller, then try to grep for the TZ variable there ...

You'll probably have more luck with this approach than trying to mess with bootloader code.

[sdbbs]

Thanks for this (and other) comment @rokm - I think I now have enough information: nothing "easy" that I hoped for, but there are chances to do this if different approaches are tried, consulting also the source code

[FObersteiner]

For the record, I don't think the bug described in the OP is even related to Python; it's a "Windows/timezone thing" - see my comment on stackoverflow.