[Catalog-sig] [Distutils] accept the wheel PEPs 425, 426, 427

[Daniel Holth]

On Fri, Nov 16, 2012 at 1:05 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk>wrote:

> Daniel Holth <dholth <at> gmail.com> writes:
>
> > The Bento author has his own informed opinions about the  way packaging
> should
> > work which do not necessarily include the packaging PEPs.
>
> That's all well and good, but there needs to be a common infrastructure for
> interoperability, which is what the PEPs are about. Bento has ploughed its
> own
> furrow because of the difficulty of extending distutils. But packaging
> seems to
> be an area when a particular approach can't succeed (other than in a niche)
> without some level of consensus; setuptools, it seems, managed it because
> it was
> number one in a field of one.
>
> I've seen you being complementary about Bento's beautiful design, but I
> haven't
> been able to find enough documentation about this design to allow me to
> make my
> own assessment. I've looked at the documentation linked to from the GitHub
> home
> of the project, which leads to http://bento.readthedocs.org - is that the
> most
> current documentation?
>
> I found myself generally in agreement with that documentation when it
> refers to
> the drawbacks of distutils and "why Bento". However, details on the design
> itself seem a little too light to make an assessment about "how Bento". For
> example, I get the sense that Bento's main focus is on building packages
> rather
> than installing them (which is fine, since that's the harder part,
> particularly
> when you are working with complex packages like numpy and scipy). However,
> I
> can't for example see how you would configure compiler options. Of course
> the
> source is available and I've cloned it to have a look, but those kind of
> things
> are in "bento/private" and "bento/backends" and it's not really clear what
> public APIs might look like. Of course one of the problems with distutils
> was
> under-documentation, leading to everything being regarded as "public API",
> and
> we know where that's led. The heavy lifting in Bento seems to be in
> something
> called "yaku", to which I see only passing references in the Bento
> documentation and not much apart a README on the yaku GitHub page.
>
> I'm probably being dense, so I'd be grateful if you'd share how you
> arrived at
> your very positive assessment of the quality of Bento's design: was it by
> grokking the source, or is there some documentation I've missed?
>
> Just to be clear: I've nothing at all against Bento, I'm just trying to
> understand how it's put together.


He did say he will support the PEPs when they are done. IIUC David would
prefer, for example, a more rpm-like design with an actual database of
installed packages rather than files scattered everywhere. In the meantime
it's fairly easy to support eggs and wininst and sdist and wheel.

My informed opinion comes from writing a build_wheel command for Bento at
https://github.com/dholth/Bento/commit/66c457685009de46f2d36a6e016e498ab783ceeb

It was much easier than writing bdist_wheel for setuptools because the
Bento code is much cleaner and the different phases of build / compile /
install / etc. are nicely separated.

The setuptools bdist_wheel has to grab the install command and overwrite
all the install_* properties to get the paths right. It has to run in the
same process. I should probably mention that all the inconvenience is due
to the underlying distutils design; setuptools makes bdist_wheel possible
because it has a plugin architecture.

The Bento build_wheel declares a dependency between itself and the build
command. When you run build_wheel the build command and all of its
dependencies run, writing internal Bento metadata about the build to disk.
After build has run, build_wheel does not have to touch the other commands.
It just reads the internal metadata and creates the archive.

yaku is one way Bento can build C extensions. Bento can also use waf or
distutils' own compiler abstraction.

One potential deal breaker: David uses \ in his code. You will have to get
over it if you want to use Bento. :-)

Daniel Holth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121116/04792498/attachment.html>