Ian Bicking wrote: > 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.
Right. I understood this from the links you gave. Every program (script) installed into the environment has the same path. If two programs use the same package, then upgrading the package for one program updates them all. I want to avoid that. ... >> 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, That's one of the things we're trying to fake out. :) ... > 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. Yup, that's another example. > And then I fake out setuptools, which I'd really rather not do, in part > because my faking out keeps breaking. Faking isn't fun. > 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 suspect this is a case of too much automation in the wrong place. We are tiptoeing around trying to trick setuptools/distutils/site into doing the right thing automatically. >> 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. Yup. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
