Packages installed with setuptools with identical entry points are loaded incorrectly
#3989
-
|
I have two packages that have been installed using the for dist in list(importlib_metadata.distributions()):
for ep in dist.entry_points:
....
plugin = ep.load()
....The issue is that when creating the >>> import importlib_metadata
>>> for dist in list(importlib_metadata.distributions()):
... for ep in dist.entry_points:
... if ep.name.startswith('pytest_plugin'):
... print(ep)
... print(ep.load())
...
EntryPoint(name='pytest_plugin1', value='src.plugin', group='pytest11')
<module 'src.plugin' from '/home/user/pytest_plugins/pytest_plugin1/src/plugin.py'>
EntryPoint(name='pytest_plugin2', value='src.plugin', group='pytest11')
<module 'src.plugin' from '/home/user/pytest_plugins/pytest_plugin1/src/plugin.py'>Is this expected behaviour after installing a package using |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 11 replies
-
|
Hi @dgard1981, if I had to guess, I would say that it seems that the configuration of the packages you are creating is a bit off, and as a result they are overwriting each other. For both cases, both projects seem to want to install the I would recommend the following layout structure: <pytest_plugin1_project_dir>
├── pyproject.toml
└── src
└── pytest_plugin1
├── __init__.py
└── plugin.py
<pytest_plugin2_project_dir>
├── pyproject.toml
└── src
└── pytest_plugin2
├── __init__.py
└── plugin.pyThen if you are using # <pytest_plugin1_project_dir>/pyproject.toml
...
[project.entry-points.pytest11]
pytest_plugin1 = "pytest_plugin1.plugin"
# <pytest_plugin2_project_dir>/pyproject.toml
...
[project.entry-points.pytest11]
pytest_plugin2 = "pytest_plugin2.plugin"
# Ref: https://packaging.python.org/en/latest/specifications/declaring-project-metadata/#entry-pointsIf you are using You might also have to change your If in doubt, you can always double check by installing the projects without using the |
Beta Was this translation helpful? Give feedback.
-
There might be something off in the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your help so far. I've come to the conclusion that something odd is going on with my Everything works when using your example above in a user@computer:~$ mkdir /tmp/tests
user@computer:~$ .venv/bin/python -m pytest /tmp/tests -q
Plugin2
Plugin1
no tests ran in 0.00sHowever, if I install the unchanged packages locally (which works just fine) and then start a Full stack traceTraceback (most recent call last):
File "/home/user/.local/bin/pytest", line 8, in <module>
sys.exit(console_main())
File "/home/user/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 189, in console_main
code = main()
File "/home/user/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 147, in main
config = _prepareconfig(args, plugins)
File "/home/user/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 328, in _prepareconfig
config = pluginmanager.hook.pytest_cmdline_parse(
File "/home/user/.local/lib/python3.10/site-packages/pluggy/_hooks.py", line 433, in __call__
return self._hookexec(self.name, self._hookimpls, kwargs, firstresult)
File "/home/user/.local/lib/python3.10/site-packages/pluggy/_manager.py", line 112, in _hookexec
return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
File "/home/user/.local/lib/python3.10/site-packages/pluggy/_callers.py", line 133, in _multicall
teardown[0].send(outcome)
File "/home/user/.local/lib/python3.10/site-packages/_pytest/helpconfig.py", line 103, in pytest_cmdline_parse
config: Config = outcome.get_result()
File "/home/user/.local/lib/python3.10/site-packages/pluggy/_result.py", line 108, in get_result
raise exc.with_traceback(exc.__traceback__)
File "/home/user/.local/lib/python3.10/site-packages/pluggy/_callers.py", line 80, in _multicall
res = hook_impl.function(*args)
File "/home/user/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 1075, in pytest_cmdline_parse
self.parse(args)
File "/home/user/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 1425, in parse
self._preparse(args, addopts=addopts)
File "/home/user/.local/lib/python3.10/site-packages/_pytest/config/__init__.py", line 1305, in _preparse
self.pluginmanager.load_setuptools_entrypoints("pytest11")
File "/home/user/.local/lib/python3.10/site-packages/pluggy/_manager.py", line 364, in load_setuptools_entrypoints
plugin = ep.load()
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 171, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
File "<frozen importlib._bootstrap>", line 992, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
File "<frozen importlib._bootstrap>", line 1004, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'pytest_plugin1'Additions+ .venv/bin/python -m pip install -U pip importlib_metadata pytest
- .venv/bin/python -m pip install -U pip importlib_metadata# Add a hook to the plugin so the we can see it works with a pytest run.
# Also do the same for pytest_plugin2 with 'Plugin2' printed.
+ cat <<EOF > /tmp/pytest_plugin1_project_dir/src/pytest_plugin1/plugin.py
+ def pytest_terminal_summary(*_) -> None:
+ print('Plugin1') |
Beta Was this translation helpful? Give feedback.
-
|
Further to my previous reply, I note the following differences when using What could cause this difference in behaviour? To confirm, all user@computer:~$ pip --version
pip 23.2 from /home/user/.local/lib/python3.10/site-packages/pip (python 3.10)
user@computer:~$ python -m pip --version
pip 23.2 from /home/user/.local/lib/python3.10/site-packages/pip (python 3.10)
user@computer:~$ .venv/bin/python -m pip --version
pip 23.2 from /home/user/.venv/lib/python3.10/site-packages/pip (python 3.10)
|
Beta Was this translation helpful? Give feedback.
-
This is a "cached build temporary artifact" generated by setuptools. It should not be very relevant and if you remove it the only thing it does is to clear the cache.
If you want the behaviour to be consistent you can run [build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"
# Ref: https://setuptools.pypa.io/en/latest/userguide/quickstart.html#basic-use.If you are seeing an |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed description. Unfortunately though, using the pyproject.toml file has not worked. Now after an install I see a directory and two files added to site-packages, both locally and in a virtual environment:
However, trying to use the packages results in the same error as I was seeing locally, but this time both locally and in the virtual environment. Even after removing to TOML file and deleting/recreating the virtual environment, the behaviour is still the same (failing), while locally the behaviour returns to that which I initially described.
|
Beta Was this translation helpful? Give feedback.
-
|
I don't understand how you ended up with In a Can you paste here the contents of your files, the project layout and the commands you are running in the terminal? |
Beta Was this translation helpful? Give feedback.
-
|
Sure, give me some time and I will add everything here. |
Beta Was this translation helpful? Give feedback.
-
|
Happily the issue is now resolved. The pyproject.toml file did in fact work. I'd been messing around with Thanks for taking the time to help me out. |
Beta Was this translation helpful? Give feedback.
This is a "cached build temporary artifact" generated by setuptools. It should not be very relevant and if you remove it the only thing it does is to clear the cache.
pipis a complicated (very useful) beast on its own...pipwas supposed to always adopt the "isolated builds" behaviour (e.g. PEP 517 and PEP 660) by default after23.1. However they are still holding it back to avoid breaking old distributions that have not adapted yet. They have a custom logic that…