-
-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using --platform manylinux2010
includes pyarrow wheel for manylinux2014
#1355
Comments
@Nimayer I'm missing two bits of information that would be useful debugging this:
|
I get the expected result without the items above:
|
Thank you for the reply!
uploader_core is a local project with the following
Before launching the pex command I generated a wheel for uploader_core by using the following command
I can add that I am using pex 2.1.42 installing using pip3 20.0.2 on Ubuntu 20.04 I see in your later reply that you cannot reproduce the problem, since in your case the correct Can it be a problem related to the pex/pip3 version I am using? |
I don't think its relevant, but is it correct to say that that
I was also using Pex 2.1.42. The local Pip version is not relevant, Pex vendors its own copy of Pip. So, I notice these paths in your output now that I read more closely: |
Sorry for the late reply. Yes, I am using Ubuntu 20.04 under WSL 1, and I am able to reproduce the issue on WSL1/Ubuntu 20.04 and an amd64 VM running Ubuntu 20.04. I'm also able to reproduce the issue on a
output:
Notice how the Let me know if you are able to reproduce the issue on docker using my commands. P.S.: I'm using rootless docker but it shouldn't matter
Yes, you are right, I will look more into it to avoid having to use |
Thanks @Nimayer that was what I needed to repro and figure this out. The specific circumstance in-play is when the interpreter you're using to run Pex happens to support the platform string you've written. Since that interpreter is a CPython 3.8 interpreter on a manylinux2014 host, it does, in fact, support the full set of CPython 3.8 manylinux2010 tags. When Pex sees that situation, it just does a normal resolve using the current interpreter instead of the strict platform you indicated. That's a bug and it's easy enough to fix. |
Previously, if a `--platform` resolve was being executed with an interpreter that matched the platform, a regular full-featured interpreter resolve was performed. This prevented, for example, resolving using a CPython 3.8 interpreter on a manylinux2014 capable host for deployment to a host that is only manylinux2010 capable. The `--resolve-local-platforms` option exists to force this sort of fallback to a full-featured interpreter resolve when that is desired. Fixes pex-tool#1355
Previously, if a `--platform` resolve was being executed with an interpreter that matched the platform, a regular full-featured interpreter resolve was performed. This prevented, for example, resolving using a CPython 3.8 interpreter on a manylinux2014 capable host for deployment to a host that is only manylinux2010 capable. The `--resolve-local-platforms` option exists to force this sort of fallback to a full-featured interpreter resolve when that is desired. Fixes pex-tool#1355
Previously, if a `--platform` resolve was being executed with an interpreter that matched the platform, a regular full-featured interpreter resolve was performed. This prevented, for example, resolving using a CPython 3.8 interpreter on a manylinux2014 capable host for deployment to a host that is only manylinux2010 capable. The `--resolve-local-platforms` option exists to force this sort of fallback to a full-featured interpreter resolve when that is desired. Fixes #1355
I'm building a pex file for a project with the following command
This is the content of
requirements.txt
This is the output of the pex command above
As you can see from the log, pex includes the pyarrow wheel for
manylinux2014
, even though amanylinux2010
wheel is available.Relevant log line:
The resulting binary gives an error on CentOS 6 which is
manylinux2010
I've also tried the
--manylinux=manylinux2010
option without success.The text was updated successfully, but these errors were encountered: