Created attachment 713373 [details] emerge --info dev-python/virtualenv-20.4.4 BDEPENDs on >=dev-python/pip-20.0.2[${PYTHON_USEDEP}] when the test use flag is enabled. dev-python/pip-21.1.2 BDEPENDs on <dev-python/virtualenv-20[${PYTHON_USEDEP}] when the test use flag is enabled. Many other packages, such as dev-python/setuptools-56.0.0 (which many many packages depend on), BDEPEND on >=dev-python/virtualenv-20[${PYTHON_USEDEP}]. You can see this issue with the following command: FEATURES=test emerge -pv dev-python/virtualenv dev-python/pip You could drop pip from that if it's not already installed -- I included it so you'll get the use change if it is.
FWIW, using FEATURES=test globally is kind of an odd thing to do. I wouldn't recommend running tests on a live system just in case the sandbox doesn't cover some case. Not all tests are well behaved. You haven't attached a log but I assume you're referring to a circular dependency? In that case, you should use emerge --with-test-deps foo in order to get foo's test dependencies without tests being enabled at first.
It's not just a circular dependency -- I'm familiar with how to fix those. It's an unfulfillable circular dependency. I think I included the info needed to see that in the original issue, but let me know if I could make that clearer. How would you propose running unit tests for every package that has them without enabling FEATURES=test globally?
Created attachment 713376 [details] emerge output
(In reply to Kevin Lyles from comment #2) > It's not just a circular dependency -- I'm familiar with how to fix those. > It's an unfulfillable circular dependency. I think I included the info > needed to see that in the original issue, but let me know if I could make > that clearer. To be fair, I was just trying to interpret what you meant, given I don't have all of the test deps needed for virtualenv installed. > > How would you propose running unit tests for every package that has them > without enabling FEATURES=test globally? I would suggest not doing that on your main system, but props to you for doing it. They're worthwhile, I just mean, expect fun cases like this. Anyway, now you attached the output, I see what you mean. But I'd really do this in a chroot or something.
I may look into that, maybe creating the binary packages in the chroot so I don't have to build them twice. I think this particular bug would still affect that chroot, though.
This is now fixed. pip pulls in virtualenv-16 for testing inside its own ebuild, so it doesn't affect the system now.
