`pantsbuild-pants` in PyPI currently provides Pyth...
# general
r
pantsbuild-pants
in PyPI currently provides Python 3.7, 3.8, 3.9 wheels for the macosx/manylinux x86-64 platforms and 3.9 wheel for the macosx-arm64 platform. The missing 3.7 and 3.8 macosx-arm64 wheels are causing problems when I use
pants.backend.plugin_development
and
pants_requirements()
with
resolves_to_interpreter_constraints
option to split the lockfile for my own pants plugins under a mono-repo source tree: • Developers in macosx-arm64 platforms: they face missing package errors when Pants selects Python 3.7 or 3.8 as the interpreter of the "pants-plugins" resolve. They figure out that the fix is to change the target interpreter range of "pants-plugins" in
resolves_to_interpreter_constraints
setting to indicate 3.9 only. • After applying this fix, developers in linux-x86_64, macosx-x86_64 faces another error saying interpreter range mismatch with the requirement when running
./pants generate-lockfiles
. • As the result, I'm now telling developers in macosx-arm64 to remove all Python 3.7 and 3.8 versions from pyenv (as my
pants.toml
is configured to look for Python interpreters only from pyenv-installed ones). • This became problems when some developers want to use TensorFlow in macOS with Metal acceleration because the macOS TensorFlow package requires installation of Python 3.8. I'm getting tired of describing all these backgrounds everytime when people ask. Couldn't we just build and push the py37, py38 macosx-arm64 wheels of
pantsbuild-pants
to PyPI so that all target platforms have the same Python interpreter compatibility range? Also, it would make my life even easier if we have linux-aarch64 wheels as well, because for cases like above, I can just say that "use a arm64 Linux VM using UTM/QEMU/Parallels/VMWare/etc. for the best development exprerience with full speed" to Apple Silicon users.
e
Technical issues aside, I'll let others address those, there are 2 critical bits you write above. It may be true you're getting tired, but not tired enough yet because we includes you! We can use all the help we can get, so please do feel empowered to drive this and any other issue to completion.
h
We have not managed to get Pants working on python 3.7 or 3.8 on macosx-arm64. I can’t remember the details, but I think those Pythons have general issues on that platform. But you’re welcome to try and see if you can get it working. If you can, then publishing wheels for them is not hard.
And re linux-aarch64, we’re waiting for CI resources (https://github.com/WorksOnArm/equinix-metal-arm64-cluster/issues/314) and then should be able to start distributing for that platform
Also note that the plan for the future is to distribute Pants as a standalone binary, with an embedded interpreter, so if you have plugins in your repo you may need separate interpreter constraints for them anyway.
Basically, in the future Pants will use an embedded interpreter of a version that works on all platforms (probably 3.9 at first)
Regardless, you say “when Pants selects Python 3.7 or 3.8 as the interpreter of the “pants-plugins” resolve. ” - you probably don’t want that to ever happen, so picking 3.9 as the single allowed version for your plugins code (using
resolves_to_interpreter_constraints
) is actually the right thing to do, I believe
I’m not sure why
./pants generate-lockfiles
would give an interpreter mismatch
Assuming you’re setting the interpreter constraints on your plugin code’s
python_sources
to be
3.9
?
r
@happy-kitchen-89482 I've re-tested the resolve interpreter constraints and setting
pants-plugins
resolve to use Python 3.9.x only seems working as expected.
h
Great!