fixup_namespace_packages may trigger
ValueError in setuptools 19.4 and newer
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
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
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:
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.
Using the attached test case, I get a slightly different error. Same error message, but sooner (before 'atlas' is printed).
From my pdb session:
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
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?