On Fri, Nov 16, 2012 at 1:05 PM, Vinay Sajip <span dir="ltr"><<a href="mailto:vinay_sajip@yahoo.co.uk" target="_blank">vinay_sajip@yahoo.co.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">Daniel Holth <dholth <at> <a href="http://gmail.com" target="_blank">gmail.com</a>> writes:<br>
<br>
> The Bento author has his own informed opinions about the  way packaging should<br>
> work which do not necessarily include the packaging PEPs.<br>
<br>
</div>That's all well and good, but there needs to be a common infrastructure for<br>
interoperability, which is what the PEPs are about. Bento has ploughed its own<br>
furrow because of the difficulty of extending distutils. But packaging seems to<br>
be an area when a particular approach can't succeed (other than in a niche)<br>
without some level of consensus; setuptools, it seems, managed it because it was<br>
number one in a field of one.<br>
<br>
I've seen you being complementary about Bento's beautiful design, but I haven't<br>
been able to find enough documentation about this design to allow me to make my<br>
own assessment. I've looked at the documentation linked to from the GitHub home<br>
of the project, which leads to <a href="http://bento.readthedocs.org" target="_blank">http://bento.readthedocs.org</a> - is that the most<br>
current documentation?<br>
<br>
I found myself generally in agreement with that documentation when it refers to<br>
the drawbacks of distutils and "why Bento". However, details on the design<br>
itself seem a little too light to make an assessment about "how Bento". For<br>
example, I get the sense that Bento's main focus is on building packages rather<br>
than installing them (which is fine, since that's the harder part, particularly<br>
when you are working with complex packages like numpy and scipy). However, I<br>
can't for example see how you would configure compiler options. Of course the<br>
source is available and I've cloned it to have a look, but those kind of things<br>
are in "bento/private" and "bento/backends" and it's not really clear what<br>
public APIs might look like. Of course one of the problems with distutils was<br>
under-documentation, leading to everything being regarded as "public API", and<br>
we know where that's led. The heavy lifting in Bento seems to be in something<br>
called "yaku", to which I see only passing references in the Bento<br>
documentation and not much apart a README on the yaku GitHub page.<br>
<br>
I'm probably being dense, so I'd be grateful if you'd share how you arrived at<br>
your very positive assessment of the quality of Bento's design: was it by<br>
grokking the source, or is there some documentation I've missed?<br>
<br>
Just to be clear: I've nothing at all against Bento, I'm just trying to<br>
understand how it's put together.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>My informed opinion comes from writing a build_wheel command for Bento at <a href="https://github.com/dholth/Bento/commit/66c457685009de46f2d36a6e016e498ab783ceeb">https://github.com/dholth/Bento/commit/66c457685009de46f2d36a6e016e498ab783ceeb</a></div>
<div><br></div><div>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.</div><div><br></div>
<div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>yaku is one way Bento can build C extensions. Bento can also use waf or distutils' own compiler abstraction.</div><div><br></div><div>One potential deal breaker: David uses \ in his code. You will have to get over it if you want to use Bento. :-)</div>
<div><br></div><div>Daniel Holth</div></div></div>