On Thu, Jun 21, 2012 at 10:04 PM, Tarek Ziadé <ta...@ziade.org> wrote:
> On 6/21/12 10:46 PM, Dag Sverre Seljebotn wrote: > ... > > I think we should, as you proposed, list a few projects w/ compilation >>> needs -- from the simplest to the more complex, then see how a standard >>> *description* could be used by any tool >>> >> >> It's not clear to me what you mean by description. Package metadata, >> install information or description of what/how to build? >> >> I hope you don't mean the latter, that would be insane...it would >> effectively amount to creating a build tool that's both more elegant and >> more powerful than any option that's currently already out there. >> >> Assuming you mean the former, that's what David did to create Bento. >> Reading and understanding Bento and the design decisions going into it >> would be a better use of time than redoing a discussion, and would at least >> be a very good starting point. >> > > What I mean is : what would it take to use Bento (or another tool) as the > compiler in a distutils-based project, without having to change the > distutils metadata. I think there is a misunderstanding of what bento is: bento is not a compiler or anything like that. It is a set of libraries that work together to configure, build and install a python project. Concretely, in bento, there is - a part that build a packager description (Distribution-like in distutils-parlance) from a bento.info (a bite like setup.cfg) - a set of tools of commands around this package description. - a set of "backends" to e.g. use waf to build C extension with full and automatic dependency analysis (rebuild this if this other thing is out of date), parallel builds and configuration. Bento scripts build numpy more efficiently and reliable while being 50 % shorter than our setup.py. - a small library to build a distutils-compatible Distribution so that you can write a 3 lines setup.py that takes all its info from bento.infoand allow for pip to work. Now, you could produce a similar package description from the setup.cfg to be fed to bento, but I don't really see the point since AFAIK, bento.infois strictly more powerful as a format than setup.cfg. Another key point is that the commands around this package description are almost entirely decoupled from each other: this is the hard part, and something that is not really possible to do with the current distutils design in an incremental way. - Command don't know about each other and dependencies between commands are *external* to commands. You say command "build" depends on command "configure", those dependencies are resolved at runtime. This allows for 3rd parties to insert new command without interfering with each other. - options are registered and handled outside command as well: each command can query any other command options. I believe something similar is now available in distutils2, though. Bento allow to add arbitrary configure options to customize library directories (ala autoconf). - bento internally has an explicit "database" of built files, with associated categories, and the build command produces a build "manifest". The build manifest + the build tree defines completely the input for install and installers command. The different binary installers use the same build manifest, and the build manifest is actually designed as to allow lossless convertion between different installers (e.g. wininst <-> msi, egg <-> mpkg on mac, etc…). This is what allows in principle to use make, gyp, etc… to produce this build manifest > > "It can deal with simple distutils-like builds using a bundled build tool" > => If I understand this correctly, does that mean that Bento can build a > distutils project with the distutils Metadata ? > I think Dag meant that bento has a system where you can basically do # setup.py from distutils.core import setup import bento.distutils bento.distutils.monkey_patch() setup() and this setup.py will automatically build a distutils Distribution populated from bento.info. This allows a bento package to be installable with pip or anything that expected a setup.py This allows for interoperability without having to depend on all the distutils issues. David
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
