fixup_namespace_packages
may trigger ValueError
in setuptools 19.4 and newer
#520
Comments
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): I recognize that this behavior appears as a regression from 19.3, but it's also a pretty obscure expectation. It's too late to release 19.4 as a backward-incompatible release, but at this point, I would consider the implementation the new expectation. One could argue that Setuptools should back out this change in order to support this expectation, but given how difficult and painful it has been to get this functionality to (mostly) work, I'm strongly inclined to keep the existing functionality, despite its limitations. That said, I would be happy to accept a patch that additionally supports easybuild, especially if the patch is suitably encapsulated, limiting the complexity it adds to the implementation when easybuild is not relevant. I'll take a look at the test case and see if it reveals any additional inspiration. |
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): Using the attached test case, I get a slightly different error. Same error message, but sooner (before 'atlas' is printed).
|
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): From my pdb session:
|
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): I'm afraid I'm stuck on this one. I think what we desire is a function that takes the Can someone suggest a better way to resolve the sys.path entry for a given |
Original comment by embray (Bitbucket: embray, GitHub: embray): I agree that just because it happened to work before, this is a really exceptional case that was never intended to work. I still think that the
in other words, if a As for easybuild, instead of performing unexpected manipulations of |
I faced this problem (and found this bug) yesterday, after creating fresh virtualenv (which installed setuptools 35.0.1 (and resolved the case by downgrading to 19.3). The backtrace ended in:
Funny thing is that my virtualenv contains both The thing above can be easily reproduced on my Ubuntu 16.04 by simple:
Anyone has suggestion, who is to blame? |
Originally reported by: kehoste (Bitbucket: kehoste, GitHub: Unknown)
We are hitting a problem with setuptools 19.4 and newer, while things are working fine with setuptools 19.3 and earlier. The problem was introduced with the changes in Pull Request #167 .
The problem is that a call to
fixup_namespace_packages
is triggering aValueError
, due to the way in which we 'flatten' our easybuild.easyblocks namespace (see here).More details about the issue we're hitting are available here.
A test case is attached, the problem can be triggered with:
Correct output (which we obtain with setuptools 19.3 and earlier) would be:
With setuptools 19.4 and later we get:
The problem is that the way in which the parent location of the package is determined in the
sort_key
inner function is broken, basically because we 'rewrite' a package name likeeasybuild.easyblocks.a.atlas
toeasybuild.easyblocks.atlas
.So the 'depth' of the location at which the module is actually available (
easybuild/easyblocks/a/atlas.py
) doesn't match the depth of the package name it is imported with (easybuild.easyblocks.atlas
).Since this works fine with setuptools 19.3 and earlier, I consider this a bug introduced in setuptools 19.4.
The text was updated successfully, but these errors were encountered: