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

[Phillip J. Eby]

At 11:16 AM 7/8/2005 -0400, Ryan Tomayko wrote:
>If I want to use the development version of kid from buildutils, I
>would do:
>
>     cd devel/kid
>     python setup.py develop --install-dir=../buildutils --script- 
> dir=../buildutils -m

FYI, --script-dir defaults to --install-dir if you explicitly set 
--install-dir, so the above could read:

     python setup.py develop --install-dir=../buildutils -m

or for the ultimate in cryptic brevity:

     python setup.py develop -md../buildutils

:)


>I may still leave the use command in tact and have it perform these
>commands on multiple projects the way it does today. For example, if
>I wanted to use the development versions of kid and pudge from
>buildutils:
>
>     pbu use --projects=kid,pudge
>
>And to no longer use those projects:
>
>     pbu use --stop --projects=kid,pudge

I'm not sure if you're saying you're going to keep having 'use' do what it 
does now to implement this, or whether you mean you're going to have it run 
"setup.py develop" with the right options in its targets.  I'd recommend 
the latter, since your current implementation doesn't work for projects 
that put their source code in a subdirectory of the project directory (e.g. 
a "lib" or "src" subdirectory).  If you make it a wrapper for "develop", 
then any setuptools-using project should be able to use it, without being 
forced to follow your personal choice of project directory layout.  :)

If you do this, you should also use the current package's:

      os.path.abspath(self.get_finalized_command('egg_info').egg_base)

as the --install-dir for the develop commands, so that projects with "src" 
or "lib" dirs can be the target of the use command, as well as their 
source.  (egg_base is the directory where the project's .egg-info will be 
located; getting it from the 'egg_info' command allows advanced users to 
override it in setup.cfg if it can't be determined from the distribution 
package_dir setting(s).)

By the way, the whole idea of using develop to link one package to another 
is quite interesting; I hadn't thought of making one package the target of 
another like this, but it seems useful and ought to work.  Even more 
interesting is that if you run "develop" on the package that has had other 
projects develop-linked to it, then the whole tree of dependencies becomes 
available in the target.  However, you should be careful to avoid creating 
a cycle of develop-links, because it will cause an infinite loop at 
runtime.  pkg_resources does not have any ability to detect such link 
cycles at the moment, although I could probably add something without too 
much difficulty.