In article <cah6pt5rq0xwy86rt5trzzzirgvdvh25c8_avk4mqvk7xvn1...@mail.gmail.com>, Matthew Brett <matthew.br...@gmail.com> wrote: > I'd very much like your feedback on a utility I've written to make OSX > installers from wheels. > > For my own course, and for matplotlib, I wanted to make an double click OSX > installer which would install a series of requirements into Python.org Python.
Thanks for looking at this. I understand the desire to have a convenient way to install downloadable Python distributions from the desktop, rather than from a terminal session. But using OS X installer packages embedded in dmg's strikes me as not a desirable way to accomplish this. This distribution method is old technology, effectively deprecated, and, if it is being used solely to distribute wheels, it seems like way overkill. The primary use case for installer packages is when you need to install files in various disparate parts of the file system, particularly in system areas that require admin privs to do so. Wheels are themselves a packaging format, managed nicely by pip. Bundling that into a another packaging format, one that doesn't even provide an uninstall capability unlike pip, seems wasteful and even confusing. And then embedding *that* in a dmg just makes it more complicated, what with mounting images and dismounting and deleting the dmg. If the installer package is a 10.5+ flat package, there's no need to embed it in an dmg; that was only necessary for the original, bundle format installer packages, which are a collection of directory trees with files, rather than a compressed container file. (Curiously enough, I'm working right now on finally transitioning the python.org installers away from bundle packages with dmgs to flat packages.) Another issue with installer packages is that they need to be signed by someone with a Mac Developer account from Apple to avoid users having to figure out to override Gatekeeper security settings (control-click -> Open (Installer), rather than double click), a less than ideal user experience. Ideally, IMO, I would like to see us come up with a Python.app that acts as a double-clickable GUI front end to Python for OS X. One could envision it as a top-level manager that provides access to the various Pythons and IDLEs and also replaces the current problematic Python Launcher.app. It could handle wheels by registering the .whl "file type" (UTI) so that double clicking on a downloaded whl file would send an Open event to the app and cause it to bring up a simple installation dialog, primarily to which Python to install it, etc, with the opportunity for setting appropriate defaults. The Python.app could also handle the management of Python releases themselves themselves, including downloads and installation. (Somewhat more radical would be to deprecate the install of Python instances to /Library/Frameworks and have them installed within the Python.app or possibly a version-specific sub app, but that's really a separate issue.) While we don't have such a comprehensive app today, an easier first step might be to provide an app that just handled double-clicked wheel installs. Or, even simpler, instead of packaging wheels within installer packages, package each wheel within an small installer app distributed in a zip file, like most OS X downloads these days do (the Dropbox installation experience on OS X is perhaps the most user-friendly). In either case, the apps would need to be signed. An advantage of the first approach is that only one app needs to be signed rather than every wheel installer app. -- Ned Deily, n...@acm.org _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
