Personally I think you’re better off attaching an executable stub to get sane behaviour anyway, as that’s far more general than any particular shell. (I also dislike trying to modify environment variables for this kind of thing.)
I haven’t forgotten that feature request to make py.exe stubbable, BTW Though I’m still hopeful to see something come along that embeds the runtime so that users don’t have to preinstall anything at all.
This looks like a good tool. I was looking for something a bit like this a few years back and ended up creating snoap (link in profile) just for my own use and my work at the time. The concept is a similar, but pyempaq looks to really double down on the ease of use aspect by doing the installation step on first run rather than having an explicit installer. I’ll definitely give it a try.
This feels like a practical approach to getting a cross-platform ‘just double click’ application experience, with the various caveats above. The only additional caveat I’d add is that the relying on the system Python eventually breaks down if your users use platforms like SLES 12 or RHEL 7 that use old Python versions that may not be supported by PyPI packages. That takes us back towards the ‘embedding the interpreter’ model.
Hello @sonotley ! Glad you liked it, please give it a try and let me know your opinions! Thanks
Regarding old Python versions in old platforms… yes, it may be a problem. From the developer side, note that you can specify the minimum Python required to run (so the unpacker will refuse to run your program unless the restriction is bypassed by an environment variable).
In any case, it’s not important. If you’re running RHEL7 for sure you will have the knowledge to get that program in some other way, or install a more modern Python, etc. PyEmpaq aims to make the life simpler for casual end users, and most of them will be using modern Pythons in their laptops / desktops.