I would like to remove the support for module declaration from entry-points and rely only on the path
Supporting this feature is a real burden and painful due to the complexity of the Python packaging.
We got issues like Entrypoint modules are being loaded twice (#12884) · Issues · Tryton / Tryton · GitLab and Tryton 7.0 does not find module installed via entrypoints (#12900) · Issues · Tryton / Tryton · GitLab.
I never used the entry-points to declare modules but only installation in
trytond.modules.* (which works also in editable mode).
I would like to know how many people are actually using entry-points and why?
Indeed entry points are needed for installation in editable mode.
So we will have to deal with it
I am using entrypoints because I don’t package my modules whatsoever. I lay python sources in a src folder which is prepended to a PYTHONPATH, then a
mytrytondmodule = my.python.module
will make my sources available as trytond modules.
This has been the aftermath of many years struggling with the legacy setup.py files from the Tryton ecosystem causing multiple issues to pipenv and poetry resolvers and venv managers.
Eventually, I discovered I didn’t need to package the modules at all, which was the comon practice in my organisation for non-tryton applications, and I was happy everafter (until the issues you linked rose).
I had gone as far as prototyping a Hatch plugin (GitHub - pypa/hatch: Modern, extensible Python project management plugin) that could replace all those setup.py files, but abandoned that initiative because I never felt Tryton has any interest in keeping up with the Python packaging evolution. I still believe it is doable.
This post kind of startled me. Like, how can a project that aims for modularity consider removing the only module registration mechanism? I’d expect moves in the quite opposite direction!
E.g. pytest plugins can be made discoverable either via the
pytest11 entrypoint (e.g. pytest-trytond/setup.cfg at 30afd1f9030ba31d8033c832c18574a3a12c563b · calidae/pytest-trytond · GitHub), a
PYTEST_PLUGINS environment variable or some simple attributes in a
pyproject.toml file. Requiring all plugins to be package under a
pytest.contrib module of sorts would be rather weird. Same goes for Tryton IMHO.