Jim Fulton wrote:
>> Jim Fulton wrote:
>>>> Concretely, what do you think about making lib/python in a Zope 3.3
>>>> instance a site for now (calling site.addsitedir())?
>>> I think it's a bad idea, mainly because it's too late to make such a
>>> change for 3.3. I tell you what I will do though, I'll promise, by
>>> the end of EP, to have a buildout that lets you define Zope 3.3
>>> instances with the eggs of your choice.
>> That sounds very interesting. However, zc.buildout is clearly aimed at
>> large deployment. A *simple* way of deploying eggs in instances would
>> still be needed (*I* need it, in fact);
> I'm confident that zc.buildout will serve simple cases well. The
> zc.buildout project itself *is* an example of a simple buildout and I
> think it is serving itself rather well. :)
Good. I shall invest some time in playing with it then.
>> if not in Zope 3.3, then at
>> least later. Currently you only have to drop package directories into
>> INSTANCE/lib/python, something similar with eggs should also be possible.
>> I frequently get lost between sys.path, sys.prefix, .pth files and the
>> site.py module. The fact that a one line fix gets what we want seems
>> simple enough to me. As said, I'm not the expert here, though :)
> I doubt we are going to make our release target as it is. I don't think
> any feature change, especially one with such far reaching ramifications
> is justified.
> Adding a call to addsitedir won't accomplish your stated goal of
> dropping eggs into lib/python and having them get used. For addsitedir
> to have any impact, you have to also manage the .pth files. The fact
> that you "requently get lost between sys.path, sys.prefix, .pth files
> and the site.py module" is not at all surprising. There is a lot
> of magic there. We certainly don't want to toss any of this in at the
> last hour (I wish) of a release.
I wasn't actually pushing for this to be added to the 3.3 release. (As
for the release target, a beta2 would be nice as a first step).
Zope3-dev mailing list