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

[Fred Drake]

On 10/23/06, Jim Fulton <jim at zope.com> wrote:
> I assume that this is directed at Fred and the ZIPImportSupportForZope3.

The code needed for resource loading from ZIP files or other packages
that provide the right __loader__ interfaces is pretty minimal.
pkg_resources includes a lot of other stuff.  In an egg-rich
environment, it's reasonable to rely on pkg_resources, but it looked
like just another dependency at the time.

I just tried the pkg_resources from setuptools 0.6c3, and the
resources APIs work for non-egg packages, including conventional
directory-based packages and ZIP files that aren't eggs, so there's no
reason we can't use pkg_resources if we're willing to live with the
dependency.

(Just checking everything we use into the Zope 3 repository isn't a
pattern I want to encourage.)

> I think we need to think harder about the file-access API.

I expect there are improvements to the API that could be made, as well
as to the implementation.

> I'm not sure
> what the point of making file references string subclasses is.

This is done so that code that hasn't been modified to to work with
file references (to support backward compatibility); 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.

> Some other questions on the file-resource API:
>
> - What is the basepath argument to the new method used for?

This is used to compute a final path, and is most important when
resolving references from ZCML that does not have a package context.

> - What is the "context" of the caller to packageReference?

The intent is that code that creates objects such as the
ViewPageTemplateFile or anything else that creates objects that store
filenames for later use.  The packageReference constructor captures
the package information from the calling context, returning a
reference that can be used later, possibly by code that isn't
filereference aware.

> 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.

> - loading from eggs who's names are not package names.

I'm not sure what this is about; I'd have to dive in again to even
understand what


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Every sin is the result of a collaboration." --Lucius Annaeus Seneca