-
-
Notifications
You must be signed in to change notification settings - Fork 234
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
Reading Python source files with importlib.resources #237
Comments
This would be a very useful feature! I'm thinking that we'll want to expose some control over this though. Here's what I'm thinking:
|
It's hard to tell if any of the new resource options have made this possible - could you confirm that Python source files are still invisible to |
Is there a reason why we don't support this? https://docs.python.org/3/library/importlib.html#importlib.resources.files |
The Traversable interface has been on my radar for a few years. See https://gitlab.com/python-devs/importlib_resources/-/issues/90. Since the API did ship, it should probably be implemented. Although I'm still not thrilled about the proliferation of resources APIs in the standard library and the fact that the Traversable interface is tightly coupled to behavior of filesystems. But that ship has sailed. |
In trying to make virtualenv compatible with PyOxidizer, it seems Python file support is required. Example: I get: |
Note that PyOxidizer has support for the Python 3.7 era What isn't yet implemented is the To be honest, I'm surprised people are running into problems here. Given that the Traversable interface and corresponding APIs like It is possible some code somewhere (including in the Python standard library) is buggy and assumes presence of a 3.9 API (e.g. |
Looking through the code of CPython 3.11, it looks like ~everything in |
That is seemingly related to https://github.com/pypa/virtualenv/blob/a8fd40f6f6b1b20af1293c926a191d61ad4f5098/src/virtualenv/create/via_global_ref/_virtualenv.py#L7 and therefore #69. Virtualenv should ween off While I'm here, what does |
The failing code is |
In that case, it might be due to the fact that The solution for this is for PyOxidizer to expose Python modules to resources APIs. I thought I wrote patches for this already. But they may be languishing in my unmerged commit series to overhaul how resources work, as it is clear PyOxidizer's model isn't compatible with Python's view of the world. It should be possible to ship a quick fix that makes Python modules available via the resources APIs. A workaround until that lands is to use the |
I'd prefer to wait for that 🙂 |
This should nearly work afterward: pypa/virtualenv@main...ofek:resources |
Anything I could do to help? Both CLIs I want to oxidize (Hatch for PyPA, another for work) both depend on virtualenv |
Just today I ran into this exact issue with the latest certifi release. As a workaround, I'm planning to downgrade the Python version in my PyOxidizer-built executable from 3.10 to 3.8 to evade certifi's version detection.
Unfortunately that adapter only exists on 3.11. On 3.9 and 3.10, trying to use the Traversable /
|
(To be clear, the issues I mention aren't specific to the ostensible topic of this issue of reading bundled Python source files with |
The adapter is in a different place for Python 3.10: https://github.com/python/cpython/blob/3.10/Lib/importlib/_adapters.py. And using the version of importlib_resources used at the time of Python 3.10.8 fixes jsonschema too, so something else is going on. |
Unlike in CPython, it is not possible to read Python source files using
importlib.resources
from within PyOxidizer.The text was updated successfully, but these errors were encountered: