[Distutils] Working environment

Ian Bicking ianb at colorstudy.com
Sun Mar 12 00:10:45 CET 2006

Jim Fulton wrote:
> Ian Bicking wrote:
>> Jim Fulton wrote:
> ...
>>>> lib/python2.4/ is for packages. 
>>> Minor note: this needs to be flexible.  I'd be more inclined to go
>>> with something shallower and simpler, like just "lib",
>> Why?  Top-level packages aren't portable, since .pyc files aren't 
>> portable.  Eggs are portable, since they contain the Python version.
> I have no idea what you are saying or how it relates to whether or not
> packages go in lib/python2.4 or lib.

lib/foo/__init__.pyc is a file that is specific to a version of Python. 
  lib/python2.4/foo/__init__.pyc removes any possibility of conflict. 
Though I suppose it is arguable that a working environment should only 
support one major version of Python.

>>> This brings me to the topic of configuration.  Today, I write wrapper
>>> scripts "by hand",  I may have some application like Zope, or ZEO
>>> or our test runner that is implemented by a an entry point in a module.
>>> Then there's a wrapper script that imports the module and calls the 
>>> entry point.
>>> The wrapper script is written (manually or with some custom installation
>>> script) to include the path to be used and configuration data,
>>> which may be the location of a configuration file.  I really like
>>> the fact that easy_install will generate wrapper scripts for me, but
>>> I really need more control over how these scripts are generated to
>>> include *both* path and configuration information.
>> I'm not sure what to think of this.  I don't think of it as a script. 
>> It's like a specific invocation of the script.  A shell script.  Maybe
>> we can improve on shell scripts, but I think it's a different idea 
>> than the script alone.
> What "it" are you talking about?

This script+config invocation.

Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org

More information about the Distutils-SIG mailing list