On Wed, 8 Jan 2020, 22:08 Andrew Barnert, <abarn...@yahoo.com> wrote:
> > But that generated zip B doesn’t have a trustable hash on it, so how can > you execute it? > The issue of trust is solved by keys, i did not propose something concrete as i'm still looking into a viable scheme If you keep this all hidden inside the zipapp system, where malicious > programs can’t find and modify the generated zips, then I suppose that’s > fine. But at that point, why not just install the wheels inside zip A into > an auto-generated only-for-zip-A venv cache directory or something, and > then just run zip A as-is against that venv? > The env idea is to be retained, the thread was asking where would the cache directory be located. require pretty frequent updates, Well this proposal goes for dependendency freezing. When an app is shipped, the packages are not expected to be updated. The author can ship another version with updated libs but the end user does not worry about packages updates and it still only lets you run on systems that have wheels for all your > dependencies. > > If you’re already doing an effective “install” step in building zip B out > of zip A, why not make that step just use a requirements file and download > the dependencies from PyPI? You could still run zip B without being online, > just not zip A. > > Maybe you could optionally include wheels and they’d serve as a micro-repo > sitting in front of PyPI, so when you’re dependencies are small you can > distribute a version that works for 95% of your potential users without > needing to do anything fancy but it still works for the other 5% if they > can reach PyPI. > If you can have pypi that's just cool, but the idea of using archives trends towards self-contained apps (But maybe it would be simpler to just use the zip B as a cache in the > first place. If I download Spam.zipapp for Win64 3.9, that’s a popular > enough platform that you probably have a zip B version ready to go and just > ship me that, so it works immediately. Now, if I copy that file to my Mac > instead of downloading it fresh, oops, wrong wheels, so it downloads the > right ones off PyPI and builds a new zipapp for my platform—and it still > runs, it just takes a bit longer the first time. More ideas, did not consider online, but if we do it's a very nice thing I’m not sure this is a good idea, but I’m not sure trying to include every > wheel for every platform is a good idea either…) > Maybe as Mr. Christopher says, i must bring in some demos But there’s a bigger problem than just distribution. Some extension modules > are only extension modules for speed, like numpy. But many are there to > interface with C libraries. If my app depends on PortAudio, distributing > the extension module as wheels is easy, but it doesn’t do any good unless > you have the C library installed and configured on your system. Oh that's a user problem, it's the same as Twisted requiring some C++ redistribuables on windows. I got the impression that the name twisted was really well named as i found the library to be twisted for installation. We were in the midst of our usergroup webscraping presentation when the demo at hand required to install twisted. Some nasty C++ redistribuable error showed which slowed down the whole session. But that was a user side requirement not a lib side one.
_______________________________________________ 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/NWN23FFTB646HFHQSRXHMK7PMGHRZJHI/ Code of Conduct: http://python.org/psf/codeofconduct/
