[Distutils] ANN: buildutils-0.1.0 - Distutils extensions for developing Python libraries and applications.
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
>> 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.
rtomayko at gmail.com
More information about the Distutils-SIG