Fred Drake wrote:
On 10/24/06, Jim Fulton <[EMAIL PROTECTED]> 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  We want to load resources
for but wants to be a namespace packages.  There are
2 possibilities, we could move configuration files out of,
or we could load configuration files out of the *egg*
rather than from the package.  We'd need pkg_resources for


- We need to decide if we want to commit 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).


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 Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to