Is there an easy way to indicate a python_source r...
# general
b
Is there an easy way to indicate a python_source requires a torch CUDAExtension to be built?
f
You can always add explicit dependencies on a target.
b
Is there an nvcc build rule in pants I can use?
f
If you are using
python_sources
, you can use the
overrides
field to add the dependency to the
dependencies
field of one of the
python_source
targets generated from it.
Is there an nvcc build rule in pants I can use?
That I do not know.
However, you can use the shell and adhoc backends to write a custom rule.
adhoc_tool
and
shell_command
are the relevant target types
and the various "wrap as resources" adapters will let you turn their output into something a
python_sources
can consume
1
b
Gotcha. Is it alternatively possible to have a python_source dependency that must be called? For background, I'm trying to port a setup.py to pants and it calls CUDAExtension from torch (similar to making a Cython extension). I want to be able to build this CUDAEXtension and package it with pex.
f
What do you mean by "a python_source dependency that must be called"? In what context would you want it called? Is it more like a build script?
b
Similar to manually calling setup.py
f
Also
adhoc_tool
accepts any runnable target and
python_source
targets are runnable.
b
It sounds like I'll have to invest some time in
adhoc_tool
. Are there any cython + pants examples I could look at? That should be a similar enough use case to base a solution on.
f
Alternate solution: Can you just publish the wheel for setup.py distribution to a private PyPI repository? And then have Pants generate its lockfile from that.
b
Unfortunately, no.
Good idea though.
f
Re Cython, this (still open) issue is probably of interest: https://github.com/pantsbuild/pants/issues/14752
🙏 1
(I have not read through it, but it looks like lots of discussion.)
f
python_distribution
might work, although it produces a wheel as its output. I don't know how that interacts with using a lockfile.
Generally
python_distribution
is used for publishing wheels to PyPI for first-party sources. The use case of consuming that wheel outside of a lockfile would be a different use case.
I am also just surmising based on not actually having tried it.
1
So I guess the advice is, try it and see what it actually supports.