On Jan 8, 2020, at 12:04, Abdur-Rahmaan Janhangeer <arj.pyt...@gmail.com> wrote: > > >> 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
OK, but I don’t see how any scheme that looks like any of the usual ones could be adapted to work. The whole point of code signing is that I know that you signed the app with a key that nobody else has access to, and nobody has changed the app since then (plus additional stuff, but this is the relevant part). If that new zip B is built on the fly on my machine by normal user software, it can only be signed with a key that’s available to normal user software on my machine. Which includes malicious software that wants to modify and re-sign the zip. (I’m assuming you can’t rely on being online at this point.) >> 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. Why is that a problem? Most platforms have a standard location for putting cache directories. Those that don’t, you just have to use something hardcoded. More importantly, how does your solution make anything easier? Bundling the cache back up into another zipfile and then trying to figure out where that zipfile is the same problem as just trying to figure out where to put the venv would have been. It seems like you’re just adding complexity without any benefit. This is why I assumed you might want the platformized “B zip” to be itself redistributable—then you do get some benefit. But maybe there’s some other benefit I’m not seeing? >> require pretty frequent updates, > > > Well this proposal goes for dependendency > freezing. When an app is shipped, the packages are not expected to be > updated. If you bundled an app with all the wheels that yesterday, and newer wheels are needed to work with the new version of macOS with Enhanced Super Duper Gatekeeper, or the manylinux2021-armv8 that’s recently become a popular platform, or the AIX platform that only 20 people care about so some of the wheels didn’t exist but now they do because 1 of those 20 people wants those libraries, the wheels those people need are on PyPI, but they’re not in your bundle. That’s a solved problem with the current ecosystem, but you’re throwing that solution away, and therefore need to solve it again. Or maybe it’s fine to not solve it. Mac-specific apps often have to be updated when a new macOS comes out, so if platform-agnostic apps also often have to be updated when a new anything comes out, maybe that’s no big deal? >> 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, OK, but it seems like if you’re not solving it, you don’t really have portable apps. An app that can run out of the box on every machine except most Windows systems, or an audio app that runs on every machine but usually only plays audio on Linux, etc., doesn’t seem very portable. Conda, py2exe, py2app, platforms’ package managers, etc. all do solve this problem. Of course most of them don’t do so in a platform-agnostic way, which makes it a lot easier… But still, why would I want to download the zipapp instead of brew install or downloading a Mac-specific py2app app or something else that will definitely work instead of only maybe working and otherwise punting on it as a user problem that I have to figure out how to solve myself? The fact that I can copy that same zipapp to a Windows box and then figure out how to solve the same user problem on a different platform doesn’t seem like a huge win.
_______________________________________________ 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/FT3JRPA776APFDORRDTDQMMFEABNNBBD/ Code of Conduct: http://python.org/psf/codeofconduct/
