On Thu, 19 Nov 2020 at 22:55, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > > On 20/11/20 11:32 am, Chris Angelico wrote: > > 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? > > There seems to be an assumption here that having a natively > installable app automatically means bundling everything, > including the Python executable. It doesn't have to be that > way. There's no reason the installed app can't use a > previously installed Python or other libraries.
Agreed, although there are use cases for bundling. > I still think it would be useful to have some kind of basic > installer-creating functionality in the stdlib. Not bundling > Python could be the default, or even the only option if > you're that concerned about it. I'm not sure about an installer. To me that means integrating with system "installed apps" mechanisms. But I *would* support building an "unzip and run" style of distribution. It would be possible to design/develop the interface outside of the stdlib, but as the person who wrote zipapp, I'd be completely in favour of making it part of zipapp once the details are thrashed out. On Thu, 19 Nov 2020 at 22:59, Chris Angelico <ros...@gmail.com> wrote: > > You mean... zipapp? No. Definitely not. There are fundamental differences between .exe files on Windows and other filetypes. And people have already explained that MacOS app bundles are different from zipapps. You can argue against providing "native bundles" if you want (I'll disagree with you, but that's fine) but please stop insisting we mean zipapps. We don't. I certainly don't, and I should know as I was involved in the zipapp design. On Thu, 19 Nov 2020 at 23:12, Chris Angelico <ros...@gmail.com> wrote: > > On Fri, Nov 20, 2020 at 10:05 AM Eric V. Smith <e...@trueblade.com> wrote: > > 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. > > > > I never said it shouldn't happen. But having zipapp in the standard > library and all native executable creators as third party apps gives a > clear indication that a .pyz file should be considered first, and a > native executable only if that isn't suitable. And I don't agree with that. If anything, I believe that .pyz zipapps are the attractive nuisance. People on Windows (to give a specific example, me, who should know better!!!) try to use them, and then trip up over the fact that you really can't persuade the OS to treat anything other than an actual .exe file as if it were a native executable. You can get it to *almost* work, and almost is often sufficient, but it's not seamless, and in my experience, you usually end up hitting an edge case where things go wrong. Maybe you need to run the application via subprocess, maybe you didn't set PATHEXT in your shell, maybe the filetype associations are incorrect. But what you end up with is someone discovering that the file you sent with doesn't work "because it's written in Python, not in <pick another language that writes native exes>". 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/BYUL3H7DFWJ2NV4MWDFIDIGN52REXTHT/ Code of Conduct: http://python.org/psf/codeofconduct/
