Phillip J. Eby wrote: > At 11:50 AM 5/17/2006 -0400, 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. > > > I haven't done it yet, mainly because I haven't decided how it should work, > exactly. Mostly I'm concerned that it seems to need a bunch of options in > order to support all the use cases that have been requested. > > For example, you've asked mainly that all the requirements be pre-baked, > and Ian has asked also that nothing "leak into" the current environment > that isn't pre-baked. (Which is also a reasonable requirement for > high-security scripts.)
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? My use cases can be done by inserting something into the beginning of the path before site is imported. The "something" can be absolute or a script-relative path. Except for the script-relative part, it's equivalent to setting PYTHONPATH. If you don't have a custom site.py, then it's equivalent to just appending it to the path after site.py is imported. If this is done through an installation option, then this covers me (where I have a distutils.cfg controlling this). It can cover script customization (with setup.cfg), maybe that can be improved by doing some variable interpolation as well. What variable interpolation I don't know, as I'm unsure what the actual use case is. I can imagine a use case where a script represents a complete application, and wants specific control of all its libraries. But I'm not sure how that fits in with eggs -- more the basket idea where you get a bundle of things, and you install the bundle and include it (and only it?) on the path. I'm all for that too, but there's more to it than just the path issue. I see the working environment idea as complementary -- the working environment is what you develop in, and more attention is placed on making tools like easy_install work in that environment. But if you want to package it up, you get something more like a basket. So I can imagine implementing it the same way as the working environment -- you add a specific path before importing site.py, and the environment/basket gets to take over there. So... I guess custom site.py's seem to give script authors a great deal of flexibility. Except that isn't really a per-script kind of control, it's more per-basket. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
