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

[Jim Fulton]

Fred Drake wrote:
> 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.

Yes.

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

I certainly don't want you to check setuptools into the repository.
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.

    (Note that before we can start ziping our eggs, we'll need to deal with
     doctest.  Our version of doctest is out of sync with the standard
     one.  This isn't going to be easy because ours has some significant
     imporovements that the standard one lacks, and the other way around.)

...

>> 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);

As I suspected.

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

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

This needs to be documented.

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

That's not a sentence. :)

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

OK, so it inspects the callers globals to determine the calling package.
Perhaps it would be better to say this more directly.

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

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

An egg need not contain any packages. Or it could contain multiple
packages.  It's name may not match any package that it contains.
pkg_resources allows you to load from eggs as well as packages.

I suggest we ignore this for now.

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