Repository navigation
contents() of a zip file package returns incorrect results #44
Description
In GitLab by @encukou on Dec 8, 2017, 15:18
Packages (directories) inside .pyz archives seem to confuse importlib_resources 0.1.
importlib_resources.contents() can return content for unrelated directories -- even for directories that aren't packages.
importlib_resources.read() fails to find resources that .contents() found -- even those that are in the archive.
Here is reproducer -- run on a *nix, in an empty directory, with importlib_resources installed:
#! /bin/bash -ex
rm -rf demo.pyz demo unrelated
mkdir demo
echo "
import importlib_resources
def main():
for resource in sorted(importlib_resources.contents(__name__)):
print('Resource:', resource)
for resource in sorted(importlib_resources.contents(__name__)):
print('Reading:', resource)
importlib_resources.read(__name__, resource)
" > demo/__init__.py
echo > demo/resource.txt
mkdir unrelated
echo > unrelated/unrelated_resource.txt
python -m zipapp -o demo.pyz . -m demo:main
python demo.pyzResult:
Resource: __init__.py
Resource: resource.txt
Resource: unrelated_resource.txt
Reading: __init__.py
Traceback (most recent call last):
...
FileNotFoundError: '__init__.py' resource not found in 'demo'
Expected (and what I get when I use pkg_resources by “anti-following” the Migration Guide):
Resource: __init__.py
Resource: resource.txt
Reading: __init__.py
357
Reading: resource.txt
1
Activity
jaraco commentedon Oct 21, 2020
In GitLab by @warsaw on Dec 8, 2017, 17:48
I had a related private report from an early adopter. He noticed that if you ask for
contents()in some cases you get everything in the zip. I'm not surprised there's some wonkiness here. The problems may be related; thanks for the reproducer!jaraco commentedon Oct 21, 2020
In GitLab by @warsaw on Dec 8, 2017, 17:49
changed title from {-Support packages/directories in pyz (zip) file-}s to {+contents() of a zip file package returns incorrect result+}s
jaraco commentedon Oct 21, 2020
In GitLab by @encukou on Dec 8, 2017, 18:14
No problem! And thank you for your work; using the new clean API is a joy :)
But, note that it's not just about
contents();read()also misbehaves.jaraco commentedon Oct 21, 2020
In GitLab by @brettcannon on Dec 8, 2017, 18:51
Does this happen in all versions of Python or is this special to Python 2?
jaraco commentedon Oct 21, 2020
In GitLab by @warsaw on Dec 8, 2017, 18:57
Yeah, I was wondering the same thing.
jaraco commentedon Oct 21, 2020
In GitLab by @encukou on Dec 8, 2017, 19:04
I tested this with 3.5, 3.6, 3.7a2.
I didn't test on 2.x; the PyPI package requires python >= 3.4.
jaraco commentedon Oct 21, 2020
In GitLab by @warsaw on Dec 12, 2017, 15:03
assigned to @warsaw
jaraco commentedon Oct 21, 2020
In GitLab by @warsaw on Dec 12, 2017, 15:30
mentioned in commit 8366d2bc8b2dcccad4caeac6cfe61efad133bff8
jaraco commentedon Oct 21, 2020
In GitLab by @warsaw on Dec 12, 2017, 15:32
mentioned in merge request !48
jaraco commentedon Oct 21, 2020
In GitLab by @warsaw on Dec 12, 2017, 15:35
It's definitely a bug in both the Python 2 and 3 implementations of
contents(). A check was missing.jaraco commentedon Oct 21, 2020
In GitLab by @warsaw on Dec 12, 2017, 16:03
closed via commit afe14c3
jaraco commentedon Oct 21, 2020
In GitLab by @warsaw on Dec 12, 2017, 16:03
closed via merge request !48