<p dir="ltr"><br>
On 4 Feb 2013 09:22, "David Cournapeau" <<a href="mailto:cournape@gmail.com">cournape@gmail.com</a>> wrote:<br>
><br>
> On Sun, Feb 3, 2013 at 10:34 PM, Vinay Sajip <<a href="mailto:vinay_sajip@yahoo.co.uk">vinay_sajip@yahoo.co.uk</a>> wrote:<br>
> > Simon Cross <hodgestar+pythondev <at> <a href="http://gmail.com">gmail.com</a>> writes:<br>
> ><br>
> >> For the record, all the reasons listed at [1] appear trivial.<br>
> ><br>
> > In Bento's author's own words - "Weak documentation", "Mediocre code quality",<br>
> > "at a lower level, a lot of code leaves to be desired" may be trivial if David<br>
> > is just being self-deprecating, but what if he isn't? Or perhaps that part of<br>
> > the page is out of date, and needs updating? I can certainly agree with the<br>
> > "Weak documentation" part of the assessment, but this makes it hard to assess<br>
> > the package as a whole. Note that I'm not sniping - writing good documentation<br>
> > is hard work.<br>
><br>
> You are putting the words out of the context in which those were<br>
> written: it is stated that the focus is on the general architecture<br>
> and low-coupling which are the main issues I saw with distutils. Bento<br>
> is designed to use multiple build backends (it can use distutils to<br>
> build C extensions, or waf, the latter being how numpy/scipy is being<br>
> built with bento).<br>
><br>
> FWIW, I am not in favor of having bento blessed (or any other tool for<br>
> that matter). The fundamental mistake of the previous attempts at<br>
> packaging has been to formalize too early, or impose de-facto<br>
> standards without much specification. That's why wheel and similar<br>
> efforts are the way forward: they tackle a narrow but well defined<br>
> sub-problem of packaging. Thus, they can be reused by other libraries<br>
> to build higher abstractions. They are also less prone to the<br>
> 'fatigue' that often arise in packaging efforts.</p>
<p dir="ltr">Another couple of key pieces are "Setup-Requires-Dist" and the extension mechanism in PEP 426 - they're intended to make it easier to communicate the use of third party tools for building, packaging and installation, as well as making it easier to provide additional metadata for the benefit of those tools.</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> David<br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/python-dev">http://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>