On 2020-11-19 14:32, Chris Angelico wrote:
On Fri, Nov 20, 2020 at 9:22 AM Eric V. Smith <eric@trueblade.com> wrote:
On 11/19/2020 2:17 PM, Steven D'Aprano wrote:
On 20/11/20 12:24 am, Chris Angelico wrote:
Have you considered the value of using zipapp You get all the advantages of a single runnable file, and all the advantages of NOT including the full Python interpreter with it. It won't have all the properties of an app bundle on MacOSX, though. Firstly, does that matter? And secondly, what would it take to give it
On Fri, Nov 20, 2020 at 02:05:02AM +1300, Greg Ewing wrote: those additional properties?
It does matter. On Windows, for example, you can't use subprocess.run on a zipapp. See https://docs.python.org/3/library/zipapp.html#making-a-windows-executable. This is similar (but different) from not using .bat file wrappers for console entry points via pip, and instead creating a .exe file.
But even that doesn't help with the use case of wanting an executable without having to install Python first. I've had need to ship an executable to users who have no idea what Python is. I just want a normal Windows .exe file that's self contained.
And that's exactly why I say it's an attractive nuisance. It's very tempting to think "oh, I could just make it easier for my users, and then they don't have to think about anything". But what happens when there's a security patch for Python? Are they going to continue to not think about the dependency? Until you (manually) push out an update, they can't do a thing to fix the problem. And if they get multiple of these statically-linked Python executables, they have to have independent duplicates of all of Python, each one a snapshot at the version that someone chose to publish.
Yes, that's correct. All of what you described is how ordinary apps work. If I install a program and it has a bug or security vulnerability, then I am affected by that vulnerability. Having a way to install a Python program as a program in its own right means that it will also work that way. So what? That's how programs work. The fact that my program happens to depend on Python under the hood doesn't magically make it any different than other programs. So, again, an executable-creating library is just a way to make Python programs work like ordinary programs work. You've mentioned this objection at least twice now and I still don't see it having any real relevance. All kinds of programs have bugs and vulnerabilities. There is no special reason why someone should expect a program to shield them from bugs or vulnerabilities in that program's underlying components, whether that program is written in Python or any other language. I agree with others on this thread that a collaboration between these executable-wrappers and PyPA would be useful. I agree that installing Python APPLICATIONS (not libraries) is a problem for which there is not really a robust solution right now. I also think it would behoove us to look at conda, which is also a dependency management system and can be used to install certain apps (such as Spyder), with discussion underway for a way to create isolated environments for individual apps. In my experience, even supposedly "dependency-bundling" solutions are not reliable when using something like Qt, which tends to want to infiltrate the system on a global level. Even with conda, in the past (and perhaps and in the present) there have been bugs that caused a PyQt install within a supposedly isolated environment to be influenced by a system Qt install. Does zipapp work with PyQt (and by "work" I mean "work no matter what versions of Qt and/or PyQt the user already does or does not have installed")? The goal of such an application-distribution mechanism is to detach the program as fully as possible from any dependence on the existing software environment (i.e., ideally all it needs to know is what OS it's being installed on), so that the user can install it without giving any thought whatsoever to what other programs they might or might not have installed before or after. I think that is an important goal for making Python competitive in the realm of user-facing applications. Whether that's to be achieved with PyInstaller or something else isn't clear to me, but I disagree strongly with the idea that dependency-bundling and native-installing shouldn't be in the stdlib. It would be great if they were included in some form or fashion. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown