PackageLoader doesn't depend on setuptools#1082
Conversation
|
PyPy's Implementation on Windows has some path issues, I'll have to address those once I can boot into Windows. |
|
I am not sure this method works with pyinstaller's way of packaging jinja, while mine does :) |
|
|
|
I'm assuming you mean pyinstaller's way of packaging package data, not packaging Jinja, since how Jinja is packaged shouldn't affect how other things are loaded. I'm not familiar with PyInstaller, if you have a simple example of a package with a templates directory, I can take a look. |
|
that's not something very problematic, you know, it is just a file to add. And I recommend letting people decide which method is the best for them. If you need to package jinja in pyinstaller like i do, I am pretty happy with this init.py (it is actually not the more weird thing to do). At least I have the option to choose this loader if I want to. |
Yes, packaging jinja and a template folder as data inside a pyinstaller executable, so that this executable can render the template. I use importlib resource and yes, it's tricky to do, but at least it works |
|
If you need a specific loader for your project, you can always add a loader, we don't need to cover every possible case in the built-in loaders, that's the whole point of it being an interface. |
|
Just checked, However, this new implementation does support PyInstaller (unintentionally). |
|
Great, so it's even simpler that mine :) Will check on it once released ! |
fb7cc2f to
4b6077a
Compare
|
will this be part of the upcoming release? |
Fix the issue that was preventing us from upgrading pytest. pytest does some manipulation of test packages that prevents `pkg_resources` from loading resources from them, but used to contain a workaround for the problem. That workaround was [removed](pytest-dev/pytest#5392) in 4.6.0 as a performance enhancement when pytest switched from `pkg_resources` to `importlib-metadata` for its own entrypoint handling. This tripped up one of our test modules which defined classes that loaded templates from inside a test package. Moving these resources to the parent package fixes the problem. More and more, `pkg_resources` is being abandoned in favor of `importlib-metadata` and `importlib_resources` as they have a simpler design with much better performance. However, `importlib_resources` doesn't support loading files from any directory which isn't itself a Python package (and doesn't allow direct use of paths including directories within the package). Jinja2 chose a [different approach](pallets/jinja#1082) that we may want to emulate in our resource handling. Also fixed usage of a removed `pytest.raises()` parameter and a bug in our configuration of the `common/lib` tests that became a problem after the upgrade.
closes #970
closes #976
Based on pallets/werkzeug#1647. Uses
pkgutil.get_loaderinstead ofpkg_resources.pkg_resourcesrequired an implicit dependency on setuptools, and was is slow to import.importlib.resources/importlib_resourcesmakes some unhelpful decisions, such as requiring every directory to have a__init__.pyfile, and only loading one level deep. Python 3'sloader.get_resource_reader()API suffers the same issue for the most part. Python's resource API in general is still too limited for us to support arbitrary types of installations, so only directories and zip files are supported, and it's mostly done manually rather than with the loader/reader API.