On Tue, 24 Nov 2020 at 07:47, Christopher Barker
indeed I am. But also, where I need this sort of thing is for desktop GUIs (wxPython in my case), another heavy user of compiled extensions.
I'm still confused what the point is of a zipapp, if it can't be a proper point and click GUI thing, and it can't use any compiled extensions. How it is it better than a console_script and a pip-installed package??
For me (on a purely personal basis) it would allow me to install command line tools *without* having them tied to a specific Python installation. So, for example, I can install a tool like tox or nikola and *not* need to reinstall it every time I upgrade my main Python installation. (Even if I put it in a virtualenv, or something like pipx, that's tied to the system Python). I don't (personally) want a Python interpreter bundled (more accurately, I sometimes do, but not always). But zipapps fail for me because they aren't exes - and I regularly trip up over that problem. To give a very explicit example of what I'm personally thinking of, imagine writing the "diff" command in Python. How would you deploy it so that people could use it as easily as a native executable build? Languages like go and rust are competing in this area, and I'd like to be able to use Python for this sort of thing.
Hmm --maybe 'cause you can bundle specific dependency versions?
That's part of it, as well. But I don't often hit version conflicts, so it's minor.
In that case, conda-execute should be part of the discussion. What it does is fire up a conda environment, and then run your script in it.
The problem is for me, that I actively dislike conda. If I can set up conda-execute as a standalone Python application and use it without knowing it's conda under the hood, then it might be useful. If I can't, then it's basically demonstrated that it can't bundle *itself* the way I want it to bundle my code, so I guess that answers my question as to whether it's useful for me :-) But that does raise a good point. What I'm looking for is essentially the equivalent of `cl /Femyapp.exe myapp.c`. A standalone command that I can run, which creates an executable from my Python code, which I can copy and run anywhere. I don't mind "needing a Python runtime" installed on the target, but I *do* mind if it has to be a specific version (If I write my code on Python 3.8, I want the same exe to run when I upgrade my PC to 3.9). If I try to describe my personal checklist of features, it basically comes down to: * The installer itself must be bundled as a standalone command. I don't want to have to install the installer into every project's venv. * An installer that can't bundle itself makes me suspicious. I don't *actually* insist on "the installer must have created its own executable", but I'd want to know why if it wasn't... * The resulting compiled apps must be Windows native exes (I don't currently have a need for other platforms, but I'd want whatever "native binary" meant there as well). * The compiled apps must depend on nothing but a Python interpreter (and must not be tied to a specific version - only the app's own constraints should apply there). * Must be relatively mature/robust - I don't want to interrupt deploying my script to raise a bug on the installer and wait for a fix. Things I'd like to have: * A mode that *does* use a separately-installed Python interpreter. Most of the time I don't need the interpreter bundled, and I'd like to avoid the extra overheads. * Support for C extensions. Pure python only *is* a real limitation. * A "robust" mode that doesn't try to strip out "unused stuff". I don't need this to be the default, but I want it available. I have no wish to find out months after I deployed the script that a dependency used some weird dynamic loading feature that the installer didn't know about, and my app broke because a plugin was missing. * Related to this, I don't need the installer to guess what packages I'm using. I'm perfectly willing to tell it. And I definitely don't want the installer to look at my currently active environment - there could be all sorts of junk in there. A tool like PyInstaller is pretty close to this. The major problems for me are that it doesn't come as a standalone tool, and it has no "depend on a system Python" mode.
BTW, this all reminds me of a discussion a long while back in the wxPython community -- we thought it would be nice to have a wxPython run-time -- essentially a Python install with wxPython bundled in, so you could make little GUI apps without bundling that massive package. But one trick was that while wxPython was the big one, any given application might require who knows what other dependency as well. I suppose sipassp could help there.
And none of us got around to actually implementing it anyway :-(
... and that's the main problem with *all* of these ideas. No-one is actually implementing them. (FWIW, over the weekend I looked at adding "run an appended zip file" functionality to the Python launcher, and while it's not too difficult in principle, my C skills, and my enthusiasm for things like manual memory management and error handling, have dropped to the point where I really couldn't be bothered spending my free time on it :-() Probably because, most of the time it genuinely doesn't matter. Sharing Python code as scripts, or via `pip install` isn't that bad for most use cases. Paul