

PEP 427 – The Wheel Binary Package Format 1.0 - myko
http://www.python.org/dev/peps/pep-0427/

======
apawloski
For those confused by the relatively unhelpful title change, this is an
official binary format that can be used for cross-platform distribution.

~~~
lawnchair_larry
Yeah, an overwhelming majority have expressed frustration at this title
changing, but they insist on doing it routinely. I understand fixing
editorialized titles, but they are not doing that. In most cases, they change
it to a far more useless title.

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.

~~~
aw3c2
Maybe mods could post the original title and their change as comment for
people to vote on as feedback. That would also mean we would finally know who
the mods are...

------
StavrosK
Can someone explain the situation with eggs and all the installation
utilities? After years of programming in python, I still don't understand why
everyone makes such a huge deal of installation, which is basically copying
things somewhere in the PYTHONPATH.

~~~
lloeki
First, this does not require code to execute (which setuptools require).

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.

[0]: <https://rubygems.org/gems/libv8/versions>

~~~
StavrosK
Oh, so it's more of an improvement rather than "eggs are horribly broken". I
think I'm confused with the "easy_install vs pip" thing, where I also don't
see much of a difference.

Easy binary retrieval sounds fantastic, though.

------
zdw
So, where's the wheel to .deb/.rpm/.msi/.pkg converter?

For real ease of distribution, you have to support a destination platform's
native package format.

See also: <http://xkcd.com/927/>

~~~
inopinatus
I've long thought the better mechanism is to hook into the destination
platform's native package _system_. A la BSDPAN.

[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]

~~~
endgame
Hear, hear.

Though I believe the best way to make that happen is to make your language
play nice with automake. Nobody believes me.

~~~
klodolph
I believe you. This is why I don't use CMake / SCons / Jam / etc -- they're
nice for developers but bad for the package maintainers and sysadmins.

~~~
mpyne
CMake is _widely_ distributed now if only because of KDE, so the package
maintainers and sysadmins have figured it out one way or the other already.

------
pestaa
In the header the following line confused me very much:

    
    
        Content-Type: text/x-rst
    

Took me a short while to figure out it actually marks the type of the PEP
rather than the documented format.

------
polarix
So here's my question: Are things in a wheel allowed to rely on ANY site-
packages? IF not, this is spectacular. If so, another unfortunate attempt in
the long long struggle.

~~~
jessaustin
I'm not sure if this answers your question, but the format includes PKG-INFO,
which includes a "Requires" field. How do you envision disallowing
dependencies for python packages working? Would all packages have to contain
all of their dependencies? I don't think that would ever happen in python-
land. It would break lots of things, for dubious benefit.

~~~
polarix
Thanks. Seems like that may solve the problem, if people actually use it.

~~~
Schiphol
A question to those who know more: for those of us who only target Linux,
isn't it better to leave these things to distro package managers?

~~~
calpaterson
Leaving dependency management to distros can cause problems when they upgrade
a package to a new one that breaks the old API or when they lack a package for
a library you need. Dependency isolation is something that Java got right:
compile everything into one jar and then deployment is just copying the jar
and executing it.

The drawback is that you are responsible for security vulnerabilities in the
libraries you install.

~~~
jessaustin
_Dependency isolation is something that Java got right: compile everything
into one jar and then deployment is just copying the jar and executing it._

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.

~~~
calpaterson
> 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.

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.

~~~
jessaustin
_I'm not advocating it as the right way to distribute libraries. It's the
right way to deploy applications._

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?

------
mcantelon
Why the name "wheel"?

~~~
thruflo

        Because ‘newegg’ was taken.
        Python packaging - reinvented.
        A container for cheese.
    

From
[https://bitbucket.org/aragilar/wheel/src/38ab0c4bca96/docs/i...](https://bitbucket.org/aragilar/wheel/src/38ab0c4bca96/docs/index.rst?at=default)

~~~
mcantelon
Aha! Makes sense.

------
regularfry
I really really really really want this to work out so I can justify trying to
port it to ruby...

------
markov_twain
Literally reinventing the wheel

------
slurgfest
Good, let's just kill eggs now

------
kklimonda
Hmm... How is it different from binary eggs?

~~~
dalke
Does <http://www.python.org/dev/peps/pep-0427/#comparison-to-egg> answer your
question? If not, what would?

