On 2020-11-19 14:32, Chris Angelico wrote:
On Fri, Nov 20, 2020 at 9:22 AM Eric V. Smith <e...@trueblade.com> wrote:
On 11/19/2020 2:17 PM, Steven D'Aprano wrote:
> On Fri, Nov 20, 2020 at 02:05:02AM +1300, Greg Ewing 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
> 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
_______________________________________________
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/3LIZZWKECJXXJ5ZUMSG4ZEZFLHQP6UDD/
Code of Conduct: http://python.org/psf/codeofconduct/
