TypeError: dist must be a Distribution instance #11256
Labels
C: tests
Testing and related things
Comments
zhuofeng6
added
S: needs triage
|
This is caused by setuptools having issues with your environment and not something pip can help. |
uranusjr
added
resolution: wrong project
|
if i test with version=22.0, the case of test is ok. but version=21.3.1 is occurred an error, maybe it is something wrong with 21.3.1. am i right? |
|
Are you checking out the test suite of 21.3.1, to test 21.3.1? |
yes, of course |
|
I believe the difference you observe is due to pip changing the default editable build method to use isolated environments and masking the setuptools bug. The root issue is in setuptools. |
|
i don't know, but how do you explain if i test is ok with version>=22.0, and i occurred many error with version=21.3.1, i don't change other. test command: test command: |
|
The log is too long and can't upload, so I deleted the part |
|
My setuptools is automatically downloaded during the test, and the environment related should also be automatically set. It should be downloaded automatically when pip test it. So why do you say it's a problem with the environment of my setuptools? |
|
Let's put this another way. It's not happening on anyone else's system, so it's fairly likely to be something about your system that's the issue here. The information you've provided so far suggests that something outside of pip is causing the types not to match up. In our experience this is typically down to the complexities in how setuptools and distutils interact (which is something the setuptools team are familiar with, but we are not). There's nothing the pip team can do here. If you can demonstrate a bug in pip that can be reproduced on environments other than your own PC, then that would be useful. But the pip team can't help you with that. The setuptools team might be able to - as I say, they are familiar with how the relevant interactions work - so you may get somewhere by reaching out to them. But you're not going to make much progress asking here, as we're the wrong people to ask. |
|
I thought I had seen that before and this issue encouraged me to try and reproduce. It turns out I can reproduce reliably:
Running I'll try to understand where and when distutils is imported. |
|
Raising a RuntimeError in the stdlib So distutils is imported indirectly by our testsuite, via But actually our noxfile session has |
|
Digging further, it appears the "bug" is triggered by our use of |
pradyunsg
added
C: tests
Pretty much.
Maybe? |
@pradyunsg maybe that explains why our tests did not catch #11294 ? |
|
Aha! Indeed, it does, yes. IIRC, I'd added this because our tests started failing with this error when the new setuptools release came out which didn't default that way, and none of us had the bandwidth to investigate what exactly had changed on setuptools' end -- especially how it interacted with our quirky test isolation setup. |
|
Thanks for reporting, @alittlesir ! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
when i run tests with
nox -s test-3.9 -- -n auto tests/functional/test_bad_url.py -vit is occurred an error, and can not passed. a lot of errors occurred when running the full number of test cases. i seek the answer on the internet, and some man say the reason is that setuptools is too new.
my setuptools is : 59.4.0Expected behavior
it should be running test
PASSEDpip version
21.3.1
Python version
3.9.9
OS
x86_64 linux
How to Reproduce
nox -s test-3.9 -- -n auto tests/functional/test_bad_url.py -v
Output
Code of Conduct
The text was updated successfully, but these errors were encountered: