[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