On 26 July 2014 15:27, Wichert Akkerman <[email protected]> wrote: > I suspect that for Linux you mean “system-provided Python”? Looking at > https://www.python.org/downloads/release/python-341/ there is no python.org > binary installer for Linux. Even if there was I would expect only a small > number of people to use that over the system-provided version, considering > Linux distributions generally do a excellent job packaging Python.
Yes, by "system Python" on Linux, I mean the distro provided one. (Technically Apple provide one as well, but binary compatibility there is still governed by the python.org installer rather than the Apple version) > An /etc/os-release approach does sound like a reasonable approach. Will that > also allow me to put ‘macports’ or ‘homebrew’ in there you can create an > Cython-0.20.1-cp27-none-lmacosx_x86_64-macports_10.10.whl distribution? That > might be useful. It would be slightly abusing the spec though since macports > does not have releases itself so we’re mixing an OSX version number in, but > that does not feel any worse than the other binary compatibility guarantees. > > For Linux why not use the existing /etc/lsb_release instead of creating a > new file? Distros don't necessarily install their LSB support by default, and the design is really weird for looking up some basic distro info. So the freedesktop.org folks came up with os-release a couple of years ago - see http://0pointer.de/blog/projects/os-release for more details. While the format was originally motivated by systemd's needs, Debian adopted /etc/os-release long before it adopted systemd. > Another way to go, if softwarecollections.org (aka "virtualenv for your > distro package manager") gets any traction whatsoever on the Debian/Ubuntu > side of the world, would be to publish wheels based on *software collection* > compatibility, rather than distro compatibility. > > I had never heard of that; I’ll need to take a look at it. A quick look at > the website doesn’t really tell me what problem it is trying to solve or how > it works. It might be in the same space as things like debootstrap, docke or > PPSar. Or perhaps NixOS really is a better way to handle this. It's designed to provide a standard way to install independent runtimes (e.g. language interpreters, databases, web servers) in parallel with the system ones. In terms of level of isolation from the host OS, it's at the same level as rolling your own custom package, just with some naming conventions to help avoid conflicts, rather than the greater separation provided by things like Docker containers. The tooling is very, very Fedora/RHEL/CentOS specific at the moment, but the core concepts apply to any package manager, since it's ultimately just some conventions around installing things into /opt rather than into the normal system directories. The distro specific nature of the system is why I suspect something based on /etc/os-release is a far more likely path for wheel to take (since Debian/Ubuntu et al already support it), but the idea of greater standardisation of runtimes across distros is still a nice dream. > That would be appealing to me wearing both my packaging hats - making > prebuilt binaries for libraries more readily available to Python users in a > way that maps to Python versions rather than distro variants, while at the > same time encouraging them to get their end user applications the heck out > of the system Python so they aren't tied so closely to the distro upgrade > cycle :) > > Isn’t that already handle in the Debian/Ubuntu world with PPAs? Those do > make it completely trivial to install extra things on a system, and you > could easily make PPAs that provide custom builds that don’t overlap the OS. Yes, software collections are essentially just a more formalised way of handling parallel installs. For example, the Python 3.5 nightlies that Miro & Slavek now publish for Fedora are delivered as a software collection, so they don't interfere with the system Python 3 installation: https://lists.fedoraproject.org/pipermail/devel/2014-July/200791.html As Miro's post about that illustrates, one key benefit of standardising the "custom package" approach as SCLs is that it makes it possible to build additional tooling that assumes that particular approach to parallel installs. In our case, by SCL enabling other packages, we make it possible to test those packages against Python 3.5, even though it hasn't been released yet (and ditto with unreleased pip, setuptools and wheel commits). Users don't have to mess about manually figuring out how to build extensions against a different version of CPython, they can just use the SCL utilities. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
