Jim Fulton wrote: > Ian Bicking wrote: > >> Jim Fulton wrote: >> >>> I seem to remember a threat from from Phillip to make a proposal >>> for installing script-specific ,pth files with scripts, but I don't >>> think I every saw anything. Have I missed anything? If so, what? :) >>> If not, I'll probably write something myself and share it. >> >> >> >> workingenv (http://svn.colorstudy.com/home/ianb/workingenv) doesn't >> use .pth files, but does put in script-specific paths. > > > As I understand it, it is really putting in environment-specific paths. > I think I want script-specific paths.
I don't think I understand the distinction? Specifically, this is what gets put in: #!/usr/bin/python2.4 -S import sys, os join, dirname = os.path.join, os.path.dirname lib_dir = join(dirname(dirname(__file__)), 'lib', 'python%s.%s' % tuple(sys.version_info[:2])) sys.path.insert(0, lib_dir) import site # EASY-INSTALL-SCRIPT: 'Cheetah==1.0','cheetah' __requires__ = 'Cheetah==1.0' import pkg_resources pkg_resources.run_script('Cheetah==1.0', 'cheetah') I.e., it's hardcoding ../lib/python2.4 into the path. The relative directory is right for workingenv (it makes it movable), but an absolute location might be what you want. That's not very different, really. The "environment" is really built off this path override, not the other way around. The path override is in turn picked up from the environment during installation, but that's just a matter of self-consistency. >> As I note in my previous email ("setuptools: hardcoding the path in a >> script and site.py"), I think this would probably be cleanest to do >> through a new installation option, that could also be placed into >> distutils.cfg. Right now what workingenv does is very specific to >> workingenv, and doesn't work off any public setuptools API. > > > I have an intuition that we're thinking about this incorrectly. > We seem to be going through a lot of effort to fake out something, > athough I'm not sure what. Primarily I'm trying to fake out site.py, which is the source of most of my problems. It's a reasonable implementation of one packaging scenario, but it's hard to replace, and the standard implementation isn't what I want. I also want to fake out distutils slightly, mostly to provide my own distutils.cfg, which is again a good idea that is far harder to use than it should be. And then I fake out setuptools, which I'd really rather not do, in part because my faking out keeps breaking. Oh, and faking out of #!, which if it wasn't so obnoxiously useless would be sufficient to handle the path stuff on its own. > I have a growing suspiction that > the traditional model of a large namespace of modules > that is used by many applications serves simple scripting very well > but doessn't work well for applications. Absolutely, that's what I feel as well. I want to opt-in to modules, not get some huge cloud. At this point, setuptools/easy_install actually makes that cloud expand much more quickly with multi-version installations, and that's caused real problems for me. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig