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.
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.
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.
> 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.
> 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.
>> 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. ;-)
So you can't read data by package. You can read data from an egg.
I suggest instead that we ignore this use case, at least for now.
Agreed. I don't see that we have a real use-case for
non-package-related data from eggs. That's also something where eggs
and conventional directory-based data handling are substantially
different, as are the use cases. I don't see that we have any need to
worry about those cases in something like file references at this
time.
If we want to pursue this in the near future, there are a couple of
things that are needed:
- We need to decide if we want to commit pkg_resources.py to the Zope
3 repository, or otherwise decide how to deal with the dependency.
- 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.
-Fred
--
Fred L. Drake, Jr. <fdrake at gmail.com>
"Every sin is the result of a collaboration." --Lucius Annaeus Seneca
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
