https://pantsbuild.org/ logo
Join Slack
Powered by
I saw that pex is going to get a newer pip, but I ...
# general
a
I saw that pex is going to get a newer pip, but I recently learned that pip changed the behaviour of find-links/extra-index (https://github.com/pypa/pip/issues/9959) is it going to be possible to work around that with pex or is that something I will have to just work around? I have a test case to share if it's something that's considered a bug, I just want a wheel that is available both on pypi and find-links, with find-links having a larger build number to be preferred
✅ 1
e
Pex never (knowingly) breaks users! The new Pip will be behind `--pip-version 22.2.2`and the default will remain 
--pip-version vendored
which is the same as `--pip-version 20.3.4-patched`with the old Pip `--find-links`ordering.
There is no way I can think of to both use 
pip-version 22.2.2
and work around though. AFAICT that requires patching Pip itself.
More generally, I'd like Pex to simply reflect the Pip it uses. Any fixes needed to Pip should go upstream. The initial motivator to drop the original Pex bespoke resolver was to fix a bunch of bugs and give people the behavior they were - presumably - used to with the industry standard resolver, for better or worse.
a
that makes sense, would it be possible to extend pex (at least the lockfile creation) to accept a mapping of distribution to index like Pipenv files? With that information, for each distribution to resolve one would just call pip with pip --no-index --extra-index <selected index> <requirements>, and once those were downloaded and we recurse into the transitives check the index mapping again
just an idea, I just accept that pip loves to change how it works, I can work around it locally by using https://github.com/uranusjr/simpleindex
e
I'm missing how a resolve algorithm works if you 1st resolve pieces in isolation and then try to combine.
I guess that's just buyer beware. It might work and it might not, but you chose to do this.
👍 1
Backing up - in what way is PyPA broken or the packages in question broken such that they build to a given version wheel such that the wheel name and METADATA in it do not reflect everything about it uniquely? I assume its that sort of non-uniqueness that causes you the troubles in the end.
I mean, on the issue you referenced mboisson shouts: https://github.com/pypa/pip/issues/9959#issuecomment-877336183 but I have no clue what that means. What is "DO NOT WORK on clusters"?
a
in my case I have to rebuild a wheel to dynamically link in a dependency instead of using a static embedded lib
I just increment the build number but another work around is changing the version to have '+zmanji' or similar to it which would uniquely identify it
e
Hrm, OK. Yeah using a '+' seems like the way to go.
You are building a different version after all. I guess that's debatable, but you're fighting the system as it exists.
a
yeah, exactly
4 Views
Open in Slack
PreviousNext
Powered by