On 11/19/2020 5:32 PM, 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.
I think I'm perfectly capable of making these decisions for my use
cases. I don't consider this an attractive nuisance, I consider it a
feature.
It's really no different from any other static vs. dynamic linking
scenario. To my knowledge, the world has not abandoned static linking
(although I'll admit I might live in a bubble that could have missed
this trend). Static linking has its uses.
Python can be installed from the Microsoft App Store or whatever it's
called. Just get people to do that and then double click on the .pyz
file. Is it really that hard?
In some corporate scenarios, yes, it is hard or likely impossible. There
are no users on the systems I'm concerned about, so no one to double
click anything. Instead, the programs need to be invoked with the moral
equivalent of subprocess.run from other (non-Python) software.
(Yes, I know that there will be specific situations where that's not
possible. That's why the various .exe creation tools need to exist. It
does NOT mean they need to be in the stdlib.)
That I mostly agree with, given what I know about the state of the art
in this space. But if there was a mature tool that could be included
(for all of the various reasons given elsewhere), I might be convinced
otherwise.
I'm not familiar with the various 3rd party options to know which one(s)
to turn to or recommend under various scenarios. Usually I just give up
on Python in the cases I mention above. It would be good if Python had a
better, or at least more widely known, story here.
I just don't think we need to be immediately dismissive of people's
desire to create a platform native executable that disguises the fact
that the code is written in Python.
Eric
_______________________________________________
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/QQMX3HKI3URHNGJJVUAQVARCQU4EOQCP/
Code of Conduct: http://python.org/psf/codeofconduct/
