PEP 427 – The Wheel Binary Package Format 1.0
python.org
python.org
This is just getting absurd.
Often the article title will have some implied context, and that is completely lost when it is posted to a general aggregation site like HN. This is just one of many cases where changing the title makes no sense at all.
Second, the problem is to know what to copy, or rather what to get. even when it's pure python it can be a problem (e.g py2 vs py3) and it's even more of one with e.g C extensions, where you have a choice of building it from source (thus requiring gcc and all build dependencies such as headers) or getting a pre-built binary tied to a given platform.
Ruby gems support that since quite some time, and it's a bliss to install e.g the libv8 gem in a few seconds vs a lengthy build.
Easy binary retrieval sounds fantastic, though.
For real ease of distribution, you have to support a destination platform's native package format.
See also: http://xkcd.com/927/
[Such that installing your language-specific package causes appropriate entries to appear in the system's global database of installed packages. Thus making it easier to identify candidates for upgrade, ensure dependencies are correct, remove redundant libs and so forth]
Though I believe the best way to make that happen is to make your language play nice with automake. Nobody believes me.
The future, it's not with automake.
I think of automake as being more part of the build process. But if things worked as you and inopinatus suggest, and you have taught something like pip 2.0 to bypass the rpm package manager and instead add records directly to the RPM database for a binary wheel package that pip has installed, aren't you kind of routing around any problems of a distribution's compatibility with a language's custom build process entirely?
Or did you mean to reply one level up? Though, again, I'm not sure where automake would help with converting one binary package format into a distribution-specific binary format.
The thing with automake is:
1. Distros know how to package it. With cdbs, a debian/rules file for a properly autotooled package is only a couple of lines.
2. Because everything boils down to shell and makefile fragments, you can extend it to fit your corner cases fairly easily.
Content-Type: text/x-rst
There's no way to do that using the standard package managers, except by the much more complicated solution of having multiple OS instances available.
The drawback is that you are responsible for security vulnerabilities in the libraries you install.
So that's why jars are always 100 MB! I don't think the python community will ever perceive this as the "right" way to distribute libraries. (Actually I'm not sure even java thinks jars are the right solution for libraries.) You'd probably get more agreement if it were declared the right way to do AMIs or buildout recipes or whatever.
The drawback is that you are responsible for security vulnerabilities in the libraries you install.
It's one thing to say that the sysadmin is responsible for security, but it's another to make sure they have access to fifty rebuilt binary distributions every time a library upon which those depend has a security update. There's dependency isolation and then there's dependency isolation.
I'm not advocating it as the right way to distribute libraries. It's the right way to deploy applications. Compiling everything into one simplifies deployment. It does not simplify public distribution.
> the sysadmin is responsible for security [...]
It just means that whoever is responsible for security (which should be operations _and_ development, IMO) need a list of the libraries used as part of an application. In Python this is normally stored in the file "requirements" in the root of the source tree. Java projects have similar things, so does Haskell.
OK, I agree that's a different case, one for which jars may be appropriate whenever you don't have access to an OS-level package manager. But when is that? When using Windows, but not in the enterprise? Surely most would avoid that grim situation. Since I use apt or the equivalent to install and update apps (unless I have a reason to be closer to the current version), I primarily think of python distributions as providing libraries, although of course they may include applications as well.
It just means that whoever is responsible for security (which should be operations _and_ development, IMO) need a list of the libraries used as part of an application.
Of course it's nice when the applications one installs are supported by developers in the same organization, but it's a rare luxury that doesn't obtain for the typical sysadmin. Even in that case, however, aren't you proposing to make a lot of work for yourself that your package manager is happy to do instead?
That is a much larger problem than most people realize. It makes vulnerable dependencies fairly impossible to deal with.
If an OpenSSL bug comes out, I upgrade OpenSSL on all systems in my enterprise. Everything linked to it is automagically taken care of. If a vulnerable library is buried into jar files (or whatever equivalent in your language of choice), I'm screwed. You'll never find those, and there is no assurance that your systems are patched.
If I put on my developer or end-user hat, I totally agree with you. But for most software, this is dangerous.
Because ‘newegg’ was taken.
Python packaging - reinvented.
A container for cheese.