--interpreter-constraint causes the current platform to always be used
#957
Labels
Comments
|
Pants shouldn't do this. The only reasonable interpretation of interpreter constraints is a local PEX build. |
|
Basically --platform implies remote / don't build. Everything else (except --no-build) implies pick a local interpreter. |
Eric-Arellano
added a commit
to pantsbuild/pants
that referenced
this issue
Apr 17, 2020
…specified (#9563) ### Problem When specifying `platforms` on a `python_binary`, you'd expect the built wheel to only have those specified platforms. But, it currently will always include the `current` platform. This is because we are unconditionally passing the flag `--interpreter-constraint` to Pex, which forces `current` to be used, per pex-tool/pex#957. As explained there, Pex is behaving correctly; the issue is with Pants. ### Solution When `platforms` are set, ignore interpreter constraints. Platforms already embed interpreter constraints in them, e.g. `linux-x86_64-cp-37-cp37m` saying that it needs compatibility with CPython 3.7. So, `platforms` is an override over interpreter constraints. This change only applies when using the target with `./pants run` and `./pants binary`. Other goals like `./pants test` will ignore the `platforms` value and use interpreter constraints like normal. [ci skip-rust-tests] [ci skip-jvm-tests]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From a macOS machine, without constraints:
With constraints:
This is a problem for Pants, which always sets
--interpreter-constraint, meaning it is never possible with Pants to create a binary withoutcurrentas a platform.The text was updated successfully, but these errors were encountered: