On Tue, 24 Nov 2020 at 07:47, Christopher Barker <python...@gmail.com> wrote: > 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 _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SJTOYUGKDEK6NO3B3BWYZHANIU3VYVZD/ Code of Conduct: http://python.org/psf/codeofconduct/
