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

[Ned Deily]

On Sep 18, 2014, at 14:03 , Aaron Meurer <aaron.meurer at continuum.io> wrote:
> 
> On Thu, Sep 18, 2014 at 2:21 PM, Ned Deily <nad at acm.org> wrote:
>> 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
> 
> Why do you say that it's deprecated? Can you reference some Apple docs
> that say this?

Not by Apple necessarily, but, IME, in the greater OS X ecosphere.  As I mentioned below, I consider Dropbox to be leading the way here but I don't see that many third-party apps or packages any more that are installed using the naked Installer.app interface.  Some do install flat packages under the covers, of course.

> If you are distributing an "app" (a .app package that gets installed
> in /Applications) it is overkill, because you can just distribute a
> dmg with the app itself and have users drag it to /Applications. But
> for files that need to be installed into an esoteric location on the
> system, it is still supported.
> 
>> 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
> 
> But if a user downloads a wheel and double clicks it doesn't install.

Today, yes, but the point of the installer apps or Python.app that I proposed is to be the target applications for wheel files so that double-clicking on a wheel file would cause that app to be launched and install it with necessary interaction.  Without further investigation, I *think* that is technically possible but I haven't tried it yet.  If that can't be made to work, then this would not be as attractive an option.  And a wheel file isn't supposed to be installed in disparate parts of the file system: it's supposed to be following the Distutils installation schemes.

In general, to install into the python.org system site-packages dir would require any installer app to authenticate for admin privs.  But a wheel installer app could also provide a user-friendly option to install into the appropriate per-user location (~/Library/Python or ~/.local) without admin privs.  While optional --user installs could probably be supported in .pkg installs, the smarts to do so would have to be duplicated in every package.

> I guess an advantage of DMG is that it verifies itself, although in
> this day and age that's not really as big of an issue.

Signed package files should verify themselves as well, no?  And there is the option for signed whl files although, as I understand it, that does not include a trust model.

> At any rate, +1 for moving to flat (new-style) installers, since these
> are the ones that you can actually build with the commands that ship
> with the newest versions of OS X, and are the ones actually documented
> in Apple's docs (although most of the stuff you'll find around the
> internet refer to the old format).
> 
> Most importantly, though, you can actually sign new-style installers
> with a developer key (PLEASE do this. If the PSF can't afford a
> $100/yr. Apple developer account then they've got bigger issues to
> worry about).

Well, yes, that's the main reason for moving to flat packages :)  The two issues have been that building bundle installers is deeply ingrained in the existing python.org installer build process and that we have been supporting older OS X versions (e.g. 10.3) that do not support flat packages.  We retired 10.3/10.4 installer support with Python 3.3 and now on track to retire that support with the next Python 2.7 release (2.7.9): 10.3/10.4 installer support is deprecated as of 2.7.7.

> The obvious use-case here is users who don't want to touch the command
> line. If you care about being user-friendly to the most technically
> challenged users, you should 1, use a GUI, and 2, sign that GUI with a
> developer key. It's not possible to have a GUI installer that
> Gatekeeper doesn't block by default, because that's the way Gatekeeper
> works.

Yes, that's why I said the wheel installer or Python apps would need to be signed.

--
  Ned Deily
  nad at acm.org -- []