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.