Tricky case: pyrax==1.9.8 -- pip._vendor.resolvelib.resolvers.ResolutionTooDeep: 100

[AndydeCleyre]

Tricky case: pyrax==1.9.8 -- pip._vendor.resolvelib.resolvers.ResolutionTooDeep: 100

[pradyunsg]

Yup -- this was used to collect interesting test cases during new resolver work that was undertaken in 2020. Before that, this was where I was drafting an implementation that ended up being very similar to resolvelib. :)

[pradyunsg]

Whee! Thanks for trying out the new resolver @AndydeCleyre and for filing this report! ^>^

[pradyunsg]

@AndydeCleyre Could you try out pip's current master branch (installable via pip install https://github.com/pypa/pip/archive/master.zip)? It contains pypa/pip#8275 which should result in this error not occuring for any reasonable configuration.

[AndydeCleyre]

@pradyunsg

This eventually fails:

Collecting PyYAML>=3.12
  Using cached PyYAML-5.3.1.tar.gz (269 kB)
Collecting PyYAML>=3.12
ERROR: pip can't proceed with requirements 'PyYAML>=3.12 from https://files.pythonhosted.org/packages/3d/d9/ea9816aea31beeadccd03f1f8b625ecf8f645bd66744484d162d84803ce5/PyYAML-5.3.tar.gz#sha256=e9f45bd5b92c7974e59bcd2dcc8631a6b6cc380a904725fce7bc08872e691615 (from oslo.serialization>=1.4.0->python-novaclient==2.27.0->pyrax==1.9.8)' due to a pre-existing build directory (/tmp/pip-install-duyjcj9m/PyYAML). This is likely due to a previous installation that failed. pip is being responsible and not assuming it can delete this. Please delete it and try again.

It creates that dir during the process, and the result is the same with --no-cache-dir.

[pradyunsg]

@pfmoore @uranusjr looks like a bug to fix. :)

[uranusjr]

I feel I’ve seens this before… @pfmoore is this the error you managed to avoid by aggressively caching the candidates? I wonder why it’s coming back.

[uranusjr]

I filed pypa/pip#8282 with a minimal reproduction of the failure.

[pfmoore]

I got that today while testing something. I'm pretty sure it's a symptom of preparing the same ireq twice, but I'm not sure what triggers that - we'd need two candidates built from the same ireq. I'll try to take a look.

[notatallshaw]

I'm not familiar with this repo but FYI this particular example pyrax==1.9.8 seems to have been fixed in pip by pypa/pip#10479