Fred Drake wrote:
On 10/23/06, Jim Fulton <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
