Pep 420 style namespace packages

[jcapriot]

Implicit namespace packages

The trame packages are still using deprecated implicit namespace package mechanism. You should switch to using PEP 420 style implicit namespaces. This is causing many ClobberErrors when installing trame from an environment.yml file.

Describe the solution you'd like

Basically, just remove the bits of trame defined in trame-client from this package (the __init__.py), remove all of the text within __init__.py related to __path__ = __import__("pkgutil").extend_path(__path__, __name__) from trame-client (you don't need that line anymore),

and remove all of the __init__.py files within the packages that provide the extended implicit namespaces for trame

this would also then allow you to stop making sure all of the __init__.py files match each other.

Additional context

Relevant setuptools information regarding implicit namespaces: https://setuptools.pypa.io/en/latest/userguide/package_discovery.html#finding-namespace-packages

Pep 420: https://peps.python.org/pep-0420/

[jourdain]

FYI @psavery

[jourdain]

Just to be sure I understand what you are suggesting and not missing anything:

1. Inside trame repo remove the content of the __init__.py that we aim to extend with other packages. (keep empty init files)
2. Inside any trame-* package that extend trame.* namespace remove all the __init__.py. (remove init files)

Is that correct? And I'm guessing that will still work fine in Python 3.8+?

[jcapriot]

Essentially, you do not need to duplicate __init__.py files within the individual repos (setuptools looks for implicit namespace packages by default), and you do not need the __path__ = __import__(…) to make it work.

[jcapriot]

And I'm guessing that will still work fine in Python 3.8+?

I believe it’s been a thing since Python 3.3 at least.

[jcapriot]

I attempted it myself to demonstrate using my forks of trame-client and trame to demonstrate that you can still import trame when installing it (even though there is no trame\__init__.py within the trame repo), here: jcapriot/trame-client#1 and here: jcapriot#1. (The windows build fails due to prettier linting EOL of the node.js app).

[jourdain]

Thanks @jcapriot we need to do some deeper test to make sure all our trame-* are inlined and work as expected with that cleaned up solution.

[psavery]

We should also verify that editable environments (via pip install -e) work properly when mixed with non-editable installs for the various trame packages.

[jcapriot]

We should also verify that editable environments (via pip install -e) work properly when mixed with non-editable installs for the various trame packages.

just added an example testing combinations of editable/non-editable mode trame with editable/non-editable trame-client