[Distutils] ANN: buildutils-0.1.0 - Distutils extensions for developing Python libraries and applications.

Ryan Tomayko rtomayko at gmail.com
Thu Jul 7 19:34:55 CEST 2005

On Jul 7, 2005, at 1:12 PM, Phillip J. Eby wrote:
> At 12:02 PM 7/7/2005 -0400, Ryan Tomayko wrote:
>> I'm happy to announce that an initial 0.1.0 version of Python  
>> Buildutils
>> is available.
> Looks nice; I could easily see wanting to steal some of those  
> commands for setuptools.  :)
> Interestingly, there's some overlap between the commands as they  
> exist now.

Yep. I've been meaning to talk to you about that, in fact. Buildutils  
depends on and utilizes setuptools quite a bit. So there's really no  
reason not to move buildutils commands and functionality down into  
setuptools if they seem more relevant there. Ditto with distutils  

We may want to just start a conversation to establish whether  
splitting commands up as we our now is a even the best way to do it.  
Do we need distutils, setuptools, and buildutils? I think there's a  
good and obvious separation but we could probably pound out some  
general guidelines for where different types of functionality should go.

> For example, your 'use' command could use the setuptools "develop"  
> command to install and uninstall development eggs safely on all  
> platforms (note that Windows doesn't do symlinks) and your code is  
> making a false assumption that .egg-info will always be in the  
> package checkout's root.  It might be better to have your 'use'  
> command just be a wrapper for running the 'develop' command in each  
> of the named projects, so that those details will work right.   
> (i.e., AFAICT 'use' is short for cd-ing to each project and doing  
> "pbu develop".)

Absolutely. I need to revisit use now that you've added support for  
develop in setuptools. I didn't even document it because I figured it  
would be retooled or removed completely. I added it back when we  
first had our discussion about development environment layout.

> Also, there's some limited overlap between the new "upload" in  
> setuptools and your "publish"; the difference being that "upload"  
> only does source and egg uploads to PyPI.  (I just implemented a  
> workaround for the absence of egg support in PyPI.)

publish is a bit weird right now and I imagine it will be refactored  
considerably in the coming month. I wonder if if might be better to  
use subcommands here? e.g. publish_pypi, publish_scp, etc. and then a  
top level publish command that determines which subcommands to run  
based on setup.cfg or other metadata.

Ryan Tomayko
                                  rtomayko at gmail.com

More information about the Distutils-SIG mailing list