-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace ZConfig.loader.openPackageResource with pkg_resources? #28
Comments
That would add a dependency on setuptools, which ZConfig doesn't have now. I know there's a plan for pkg_resources to become (more?) independent (which I support), but I'm not entirely sure of the current status of that, or if Python 2.7 is on the radar for packaging folks these days. I have a slight preference for avoiding a dependency on setuptools, but I'll admit it's slight, especially after going back to take a look at that function. |
True. Though in practice it's probably there anyway. If pip is installed, setuptools is installed.
There is, yes. pypa/setuptools#863 says its blocked on not requiring setuptools to be self-installable, which was accomplished earlier this year in pypa/setuptools#581 when setuptools started taking dependencies on other projects (packaging, six and appdirs so far, most of which actually seem to be dependencies of pkg_resources). So I'd say we're closer than ever. Asymptotically, maybe, but still 😄
It's not a real urgent need for me right now. But I did have reason to notice how complex it was when I was trying to debug a problem with it (Python 2 and non-absolute |
Perhaps. Though there are still those of us happy to live in a pip-free world. Some parts of openPackageResource could be simplified using pkgutil. Whether that buys enough cleansing, I don't know offhand. |
|
This is what it looks like when all the tests pass using def openPackageResource(package, path):
data = None
v, tb = (None, None)
extra_path = []
def make_error(msg):
v = ZConfig.SchemaResourceError(
msg,
filename=path,
package=package,
path=extra_path)
tb = sys.exc_info()[2]
return v, tb
try:
data = pkgutil.get_data(package, path)
except Exception as e:
v, tb = make_error("schema component not found: " + repr(e))
if data is None:
__import__(package)
pkg = sys.modules[package]
extra_path.extend(pkg.__path__)
loader = pkgutil.get_loader(pkg)
for pkg_path in extra_path:
loadpath = os.path.join(pkg_path, path)
try:
data = loader.get_data(loadpath)
except Exception as e:
v, tb = make_error("error opening schema component: " + repr(e))
else:
break
if data is None:
if v is not None:
try:
reraise(type(v), v, tb)
finally:
del tb
raise make_error("schema component not found")[0]
assert data is not None
return StringIO(data.decode('utf-8')) |
Ouch. Right, not a clear win. |
I've been thinking about it, and I guess my question at this point is: Why is this Here's the test that uses it. Given the directory structure:
The test wants to be able to do The natural way to write that would be Or, to not change the So given those two different ways to do this same thing, why would one want this extra indirection of extending My best guess is trying to avoid conflicts with (namespace) packages and single-file modules. Suppose you were distributing a single-file module inside a namespace, let's say If both But let's suppose they're not part of the same source directory or distribution and both just use In the world where every distribution is installed as a separate egg---meaning buildout and old versions of setuptools---this will work fine. You'll wind up with However, there's a problem. Modern versions of setuptools and pip have stopped installing namespace packages as separate eggs. Instead, they're all merged into one directory ("zope" here). Conflicting data files are simply overwritten and whatever distribution was installed last wins. There will be a The only way to be sure that I looked through the zopefoundation and Plone packages on github. I didn't locate any uses of it for this purpose, but I only did a spot check. Thoughts? I'm probably missing something. |
Agree that messing with the <import
package="ZConfig.tests.library.thing"
file="extras/extras.xml"
/> and not do anything to manually update Unfortunately, |
Of course, Needless to say, my frustration with Python package-resources APIs remains strong. |
I'm not aware of any actual ZConfig component.xml that isn't located directly in a normal package, alongside the init.py file. If we're able live with that constraint, switching to I'm not sure how best to determine if anyone has a component that would not work using this, however. |
The scream test is traditional: release a new version with this change and see if any users scream. |
The
openPackageResource
function is fairly complicated. It may or may not support things like zipped imports and all the complicated ways that namespace packages work these days (it's not immediately clear to me).Can we replace its guts with pkg_resources? Something like this:
Running the test suite with that shows only one real failure: There is a module that deliberately manipulates its own
__path__
to point to a non-package subdirectory. I know that's technically allowed, but it's also discouraged these days. If we still need to support that we could have that in a small fallback handler---that would still let us remove a third of the code.Thoughts?
The text was updated successfully, but these errors were encountered: