[Pythonmac-SIG] Package for building DMG installers from pip requirements
Hi, 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. As usual, I got a lot of useful thinking on this from Min Ragan-Kelly of IPython fame. I've written an package that automates building the installer: https://github.com/matthew-brett/wheels2dmg There are some examples in the README, but the basic idea is: wheels2dmg scipy-stack 1.0 scipy matplotlib ipython[notebook] \ pandas numexpr sympy --python-version 2.7.8 This uses pip to download wheels for the stated requirements, packages them up into a 'wheels' directory, creates an OSX ``.pkg`` installer that will install the wheels using pip, and puts this all into a ``.dmg`` disk image with a suitable README, and a link for downloading Python.org Python. The generated README covers installing into Macports and Homebrew. My hope is that this makes it easy for people who want to provide a whole stack to provide a ``.dmg`` installer that does the right thing in terms of updating dependencies. I'd love to get any feedback on whether this works for people, and missing features. Cheers, Matthew ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Package for building DMG installers from pip requirements
In article , Matthew Brett 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
Re: [Pythonmac-SIG] Package for building DMG installers from pip requirements
On Sep 18, 2014, at 14:03 , Aaron Meurer wrote: > > On Thu, Sep 18, 2014 at 2:21 PM, Ned Deily wrote: >> In article >> , >> Matthew Brett 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 n...@acm.org -- [] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscrib
