[Pythonmac-SIG] Package for building DMG installers from pip requirements

[Ned Deily]

In article 
<CAH6Pt5rQ0XwY86Rt5trZzzirGvdvh25C8_avk4MqVK7xVn1X-w at mail.gmail.com>,
 Matthew Brett <matthew.brett at 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,
 nad at acm.org