On Fri, Nov 16, 2012 at 1:05 PM, Vinay Sajip <[email protected]>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
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
