[Distutils] Working environment
ianb at colorstudy.com
Sat Mar 11 22:39:18 CET 2006
Jim Fulton wrote:
>> Each of the scripts in bin/ should know what their working environment
>> is. This is slightly tricky, depending on what that means. If it is
>> a totally isolated environment -- no site-packages on sys.path -- then
>> I feel like the script wrappers have to be shell scripts, to invoke
>> Python with -S (which is hard to do portably on the #! line).
> I'll note that this isn't important to me at all. I'm not opposed
> to allowing it, but I don't need it.
I can go both ways. I think this should be configurable when you set up
the working environment, hopefully someplace where it is easy to change.
>> lib/python2.4/ is for packages.
> Minor note: this needs to be flexible. I'd be more inclined to go
> with something shallower and simpler, like just "lib",
Why? Top-level packages aren't portable, since .pyc files aren't
portable. Eggs are portable, since they contain the Python version.
> > I'm almost inclined to say that
>> --single-version-externally-managed makes sense on some level, with a
>> record kept in some standard place (lib/python2.4/install-record.txt?)
>> -- but I'm basically indifferent. I at least don't see a need for
>> multiple simultaneous versions in this setup, and multiple versions do
>> lead to confusion. Version metadata is still nice, of course.
> Increasingly, projects I work on involve multiple Python applications
> with each application requiring different sets of packages and, sometimes,
> different package versions. Basically, I want a single version for each
> application, but multiple versions in the environment. What appeals to me
> is a compromise between the single-version and multi-version install.
It's probably not important to get rid of an existing feature of
setuptools. The problems I have are better served with better tool
support. Mostly I get a huge number of old and expired eggs sitting
around, and there needs to be a collection process, probably a process
that is run on every installation. I guess the collection would start
from all the packages listed in .pth files, and maybe a collection of
scripts, and then anything those packages require. And anything left
over is garbage.
In part I'm personally moving to using setup.py develop installs for
more software, and that's more naturally single-version (though I
suppose it doesn't have to be).
>> Installation as a whole is an open issue. Putting in env/setup.cfg
>> with the setting specific to that working environment works to a
>> degree -- easy_install will pick it up if invoked from there. But
>> that doesn't work with setup.py develop, or setup.py install, or some
>> other scenarios.
> I don't follow this. It seems to work for us, at least for
> setup.py develop. The main lamosity is depending on the current working
I don't want users to have to give particular options to manage the
installation. I want them to activate a specific environment, and for
everything to just work. working-env.py mostly works like this.
> This brings me to the topic of configuration. Today, I write wrapper
> scripts "by hand", I may have some application like Zope, or ZEO
> or our test runner that is implemented by a an entry point in a module.
> Then there's a wrapper script that imports the module and calls the
> entry point.
> The wrapper script is written (manually or with some custom installation
> script) to include the path to be used and configuration data,
> which may be the location of a configuration file. I really like
> the fact that easy_install will generate wrapper scripts for me, but
> I really need more control over how these scripts are generated to
> include *both* path and configuration information.
I'm not sure what to think of this. I don't think of it as a script.
It's like a specific invocation of the script. A shell script. Maybe
we can improve on shell scripts, but I think it's a different idea than
the script alone.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Distutils-SIG