[BUG] AttributeError: 'PathDistribution' object has no attribute '_normalized_name' with setuptools 60.9.0+
#3452
Comments
edmorley
added
bug
Needs Triage
|
First, let me say a huge thanks for providing a docker-based repro. This one contrib made it possible for me to dive deep on the issue to understand it better. BackgroundThis issue stems from the fact that What this means is that later versions of importlib.metadata that expect for This issue isn't specific to Setuptools. Any calls to The reason the issue doesn't occur older Setuptools versions is because Setuptools 60.9.0 intentionally switched to importlib metadata for loading entry points. InvestigationWhat I don't yet understand is what is causing I can replicate the issue with this simpler repro: I tried uninstalling So it seems the presence of pbr is affecting the build of django-slack-oauth from source, meaning a more essential repro is: I find that surprising, because I would have expected pip to perform an isolated build such that pbr would not be a factor. However, clearly that's not the case. Confirmed that pbr imports importlib_metadata and pbr is probably invoked as part of setuptools as it provides setuptools plugins. Also curiously, I was unable to replicate the issue by building another project like pypa/sampleproject from source or from github. So there's still a factor in django-slack-oauth that's relevant. Aha. After some more investigation, I found that django-slack-oauth is being built using a legacy process because it doesn't declare any PEP 518 build info (pyproject.toml). I can replicate the issue with the sampleproject if I go back to the commit before pyproject.toml was introduced in sampleproject: That also explains why pbr affects the environment: pip is probably including the site-packages for compatibility. For Python 3.9, I had to also pin setuptools as the issue was addressed in 60.9.1. ConclusionI see the _importlib shim mentions #3102, which reports a similar error message, and the workaround there was to provide a better error message to the user. As you've already identified, updating the version of importlib_metadata that's present will fix the issue. Based on the investigation above, I believe there may be several workarounds:
|
jaraco
removed
the
Needs Triage
|
I'm glad the Docker repro helped! Thank you for looking into this and for reducing the testcase further -- the original requirements file had 96 requirements, so I was happy to get it down to 3 at least :-) (I had several false starts when bisecting, due to it needing all three) |
|
In 03da59c, I explored applying the workaround for all Python versions, but it didn't have the intended effect: "invalid command 'egg_info'". I believe what's happening is that when As I think about it more, this change could have made things much worse, because it would cause an import of |
|
I discovered another possible workaround, to force use of pep517 when building (which builds the target project using isolation even though it doesn't declare a pyproject.toml): That command succeeds and is minimally invasive. |
…d to give users better guidance when this condition is present. Ref #3452.
…d to give users better guidance when this condition is present. Ref #3452.
|
In c28caa6, I have another idea which is simply to detect and warn when the conditions are present that could cause problems. I'm not sure how effective a warning will be, because warnings rarely make it to user visibility when running under builders like pip. My temptation at this point is to do nothing and let this bug serve as documentation on what the issue is and what workarounds exist. |
There are two issues fixed in this bug. The first is that the keystone_session exception block does not return on failure. The second, and the reason that create_keystone_session is failing, is due to the use of setuptools 60.9.0+ with the importlib-metadata in wheelhouse.txt that is pinned to <3.0.0. For more details see: pypa/setuptools#3452 Closes-Bug: #2018018 Change-Id: I266c1fb92d531aded2f3253766de0a79accd9577
Ensure setuptools is <60.9, to avoid hitting this issue pypa/setuptools#3452 when testing on py3.10
There are two issues fixed in this bug. The first is that the keystone_session exception block does not return on failure. The second, and the reason that create_keystone_session is failing, is due to the use of setuptools 60.9.0+ with the importlib-metadata in wheelhouse.txt that is pinned to <3.0.0. For more details see: pypa/setuptools#3452 Closes-Bug: #2018018 Change-Id: I266c1fb92d531aded2f3253766de0a79accd9577 (cherry picked from commit 9f221f1)
There are two issues fixed in this bug. The first is that the keystone_session exception block does not return on failure. The second, and the reason that create_keystone_session is failing, is due to the use of setuptools 60.9.0+ with the importlib-metadata in wheelhouse.txt that is pinned to <3.0.0. For more details see: pypa/setuptools#3452 Closes-Bug: #2018018 Change-Id: I266c1fb92d531aded2f3253766de0a79accd9577 (cherry picked from commit 9f221f1)
setuptools version
setuptools==60.9.0
Python version
Python 3.10
OS
Ubuntu 20.04
Additional environment information
Also affects latest setuptools (62.2.0) + Python 3.8 and 3.9.
Description
With setuptools 60.9.0+ this requirements file (reduced from a user-provided report), installs successfully initially, however on subsequent installs (ie: when
site-packagesis already populated), results in an error. With setuptools 60.8.2 and older, this error did not occur.Updating to newer
importlib-metadataor downgradingsetuptoolsresolves the issue.Expected behavior
Either the existing requirements file continues to work, or else a clearer error message is given about what needs to be changed to fix it.
For example, by outputting an error message mentioning that the
importlib-metadataversion should be updated.How to Reproduce
Output
The text was updated successfully, but these errors were encountered: