From the beginning, it was clear that one of the major hurdle for bento would be transition from distutils. This is a hard issue for any tool trying to improve existing ones, but even more so for distribution/packaging tools, as it impacts everyone (developers and users of the tools).
Since almost day one, bento had some basic facilities to convert existing distutils projects into bento.info. I have now added something to do the exact contrary, that is maintaing some distutils extensions which are driven by bento.info. Concretely, it means that if you have a bento package, you can write something like:
import setuptools # this comes first so that setuptools does its monkey dance import bento.distutils # this monkey patches on top of setuptools setuptools.setup()
as your setup.py, it will give the “illusion” of a distutils package. Of course, it won’t give you all the goodies given by bento (if it could, I would not have written bento in the first place), but it is good enough to enable the following:
- installing through the usual “python setup.py install”
- building source distributions
- more significantly: it will make your package easy_install-able/pip-able
This feature will be in bento 0.0.5, which will be released very soon (before pycon 2011 where I will present bento). More details may be found on bento’s documentation
Nothing to say 
I’m curious: what issues arise when using this conversion? It’s hard to imagine that it can (even theoretically) be completely flawless.
The conversion from distutils -> bento.info is indeed far from flawless. There are just too many weird cases, some of which I will never support (pkg_dir, for example). Certainly, it will never support converting complex packages such as twisted or numpy automatically.
But the other way around, this is not a conversion per se: this is a set distutils commands which know about bento.info, a bit like bentomaker is a set of commands around bento.info. This gives you “pip install” for a near-zero cost even if your package does not use distutils at all.
In both cases, the goal is to make the transition as easy as possible for both developers and users, and work well enough for simple packages (most python softwares are, to be honest). As you know, bento was started to support the more complex packages where distutils limitations are just too overwhelming, but it is important to keep things simple for the simple cases – I don’t want bento to be limited to the more complicated cases.
+1 for later changing the monkey patching to be explicit, rather than done on import. I hated setuptools doing monkey patching (and sys.path munging) on import; it causes no end of problems.