[Zope3-dev] Re: Fwd: Re: RFC: Zope Configuration Egg Support

Jim Fulton jim at zope.com
Tue Oct 24 09:58:51 EDT 2006


Fred Drake wrote:
> On 10/24/06, Jim Fulton <jim at zope.com> wrote:
>> I certainly don't want you to check setuptools into the repository.
> 
> Certainly not!  For pkg_resources, we don't need setuptools.
> setuptools depends on pkg_resources.

Actually. the setuptools egg contains both.

> 
>> But this brings up a good point.  In the future, I want dependencies
>> handled via eggs, rather than by including them into the respository.
>> We have a little bit of a python and egg problem here. ;)  We need
>> setuptools to leverage eggs and we need eggs to leverage setuptools.
>>
>> I guess we need to porceed in the following fashion.
>>
>> 1. Create a buildout-based Zope 3 project using non-zipped eggs.
>>     This should be a separate project than the current Zope 3 project.
>>
>> 2. Once we have the buildout-based project working to our satisfaction,
>>     we can introduce the dependency of zope.configuration on setuptools
>>     and start converting eggs to be zip-safe.
> 
> As I noted, there's no need to depend on setuptools, only on
> pkg_resources.  There shouldn't be a requirement on setuptools for
> runtime behavior at all.

They are the same thing.

> I don't see a need to proceed in this order.  Whether Zope 3 itself
> uses eggs for it's own dependencies is independent of whether eggs of
> other application dependencies can be used.  The work from the sprint
> allows Zope components, including configuration, templates, and other
> resources, to be pulled from zipped eggs.

Right, but if we switch to using pkg_resources, then we'll need pkg_resources.
The easiest way to get it is via the egg. Perhaps you had another idea.

>>  > in the case of
>> > applications that contain only non-zipped packages (egg or otherwise),
>> > the string-based references can be passed directly to open() or other
>> > Python APIs that take strings, exactly as they are today.
>>
>> I think this is a mistake that will lead to subtle, or at least,
>> confusing bugs.
> 
> Then we have some backward compatibility issues to think about.

I don't think so.  It means that some directives won't work
with eggs until they get updated.

>> > The intent is that code that creates objects such as the
>> > ViewPageTemplateFile or anything else that creates objects that store
>> > filenames for later use.
>>
>> That's not a sentence. :)
> 
> Ouch!  No more late-night emailing for me.
> 
> The intent is that code that creates objects that hold on to paths be
> able to pass in a file reference that will "work" regardless of
> whether the code it is passed to understands file references.  The
> code need not be concerned with whether it is contained in an egg,
> zipped or otherwise.  If the code using the file reference uses the
> zope.filereference APIs, the reference can be handled even if the
> provider is in a zipped package.  In many cases (not all), this is
> useful for things like defining views that use ViewPageTemplateFile or
> similar constructs.

The code it is passed to has to be aware of file references because it
has to use filereference apis to do anything with it.  For example, open
would work with some file references and not others.  This would be a
recipe for very confusing errors.

I'm not opposed to file references, I just don't want them to try to
be backward compatible.

> 
>> >> Finally, we need to be able to deal with some cases that pkg_resources
>> >> will deal with that I think the API you used won't, namely:
>> >>
>> >> - setuptools namespace packages, and
>> >
>> > I'm not sure about this; it might not support that case.  I'd have to
>> > write a test to be sure.
>>
>> setuptools namespace packages aren't allowed to contain data files.
> 
> That's fine; if there can't be any data files to load, nothing will be
> found.  Sounds like this is supported to me.  ;-)

The issue I was alluding to was zope.app.  We want to load resources
for zope.app but zope.app wants to be a namespace packages.  There are
2 possibilities, we could move configuration files out of zope.app,
or we could load configuration files out of the zope.app *egg*
rather than from the zope.app package.  We'd need pkg_resources for
that.

...

> - We need to decide if we want to commit pkg_resources.py to the Zope
> 3 repository,

We don't.

 > or otherwise decide how to deal with the dependency.

We should deal with it as an egg dependency.  Thus the bootstrapping
issue I tried to deal with in my note.

> - The changes on the branch need to be ported to work on the trunk
> (shouldn't been too much work).

Yup.

> zope.filereference still doesn't address the larger issue of breaking
> apart what's in the Zope 3 repository and assembling the dependencies
> from eggs or other separate packages.

Isn't that orthogonal?

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


More information about the Zope3-dev mailing list