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 Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com