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 - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
