Jim Fulton wrote: >> It's also a reasonable requirement for scripts you don't want breaking >> randomly. These continue to be my bane. >> >> What are the use cases? >
Well, here's how workingenv deals with some of these right now... > I want to be able to install multiple programs ("scripts"), each with their > own dependencies. Note that different programs might depend on > different versions of the same package. Inconsistent requirements in a single working environment rely on setuptool's multiversion install, which should work fine on its own when used in limited places. > I want to be able to update a package for one program without > implicitly affecting the others. (This is a restatement of your > desire not to get implicit updates) This is fine. > I want everything to be installed in a self-contained project, > ala your working environment. I don't want to touch a Python install. Yup. > I to be able to use a simple install script, like easy_install. Except for frequent breakage, this works. I hope that breakage is transitional. Also, the python console works fine and represents the working environment, not the larger environment. With workingenv, I also am playing around with --requirements, which is kind of a complete installation plan. I think an external list of requirements is much easier to maintain than packages that carry their own requirements; at least for a certain set of problems, like co-developed packages, and building consistent development environments from code that is actively developed. Or just building a development environment at all, as when you are building a web application. > I don't want to have to set environment variables or provide funny > options when I run programs. I'd like to minimize this when installing > things. When the setuptools monkeypatch works, this is fine. > I want the system to be simple and understandable. I'm willing to > sacrifice > a lot of automation for this. "Explicit is better than implicit." :) Except for some (IMHO necessary) faking out of bits and pieces, workingenv is really just a matter of setting the path and keeping the path from being implicitly extended. So I think it's quite simple. It would be nice if Python proper was so simple to work with, but I'm not 100% sure what I really want yet, and I really don't feel like the grief of proposing anything on python-dev. And anyway, I need this to work with old Python versions. Perhaps one personal motivation is that I don't like to give lots of options to tools, I would rather they just work correctly, because any option I give is something I might give incorrectly. That said, having to use /path/to/env/bin/easy_install doesn't bother me, even though easy_install --prefix=/path/to/env *does* bother me, so maybe workingenv can be a little simpler if I give up completely on integrating with any larger system of packages. > It should be possible to move or link scripts around. It is not a > requirement > for me to be able to move an environment without running some program to > adjust paths, as long as such a program exists. Scripts can't be moved at this time. The entire environ can be moved, though the activation scripts have to be adjusted, because I haven't figured out a way to do script-relative paths in a shell script that is sourced. If you don't use the activation script, then that's fine. And maybe the only thing that really needs the activation script is the python interactive interpreter. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig