mdavidsaver
commented
10 months ago I have not had to work with namespace packages before. Reading through PEP420 I find:
... The new namespace package:
Has a __path__ attribute set to an iterable of the path strings that were found and recorded during the scan.
Does not have a __file__ attribute.I read the second point as saying that <ns_mod>.__file__ should not exist (so AttributeError). From #29 I take it that for the version(s) of python you use, instead __file__ exists, but is None. Am I misreading, or is the PEP incorrect?
I have a minimal working example here: https://gitlab.com/Thf772/setuptools-dso-multi-namespace-test
Could you translate this example into a test case? Like project2 under example/. With this, a GHA run should answer my question about portability/history.
$ git grep project2
.github/workflows/build.yml: cd project2
.github/workflows/build.yml: # install project2.
.github/workflows/build.yml: cd project2
.github/workflows/build.yml: (cd example/project2/src && python -m use_dsodemo.cli)
testme.sh:(cd project2/src && python -m use_dsodemo.cli 2>/dev/null) && die "error: worktree must be clean"
testme.sh:cd project2
testme.sh:(cd project2/src && PYTHONPATH=$X python -m use_dsodemo.cli)
testme.sh:cd project2
testme.sh:(cd project2/src && python -m use_dsodemo.cli 2>/dev/null) && die "error: worktree must be clean"
testme.sh:cd project2
Thf772
I have a minimal working example here: https://gitlab.com/Thf772/setuptools-dso-multi-namespace-test
When a namespace package is installed in editable mode, trying to install an Extension depending on a DSO located in the same namespace package will fail, whether that install is editable or not, on both Linux and Windows.
Steps to reproduce:
nsp/core/__init__.pynsp.__init__.pyfilensp/dso/thedso.cnsp/dso/theext.pyxnsp/dso/__init__.pythedso.c, and an extension that depends on this DSO usingtheext.pyxMy MWE above uses different names.
Expected result
The second install succeeds
Actual result
An error occurs while building the second project:
What I think happens
Looking at the source, this exception is thrown while Setuptools-DSO is building the possible locations for an existing DSO. It looks for the init file of the root package (
nspin the reproduction instructions,testnspin my MWE), but since this is a namespace package, this file does not exist. So while the import works (noImportErrorso theexceptclause is not triggered),__file__containsNoneand causes aTypeErrorwhen fed toos.path.dirname.To solve it, I think it should be possible to set up a
while(or even better,for) loop to look first atparts[0:1], see if it's a real package (__file__ is not None), and if it's not, try again withparts[0:2]and so on. Since I'm in this exact situation in a project of mine, I might make a PR for this, if no one does it before.