https://pantsbuild.org/ logo
Join Slack
Powered by
According to `InjectDependenciesRequest` you use t...
# development
b
According to 
InjectDependenciesRequest
you use the 
Dependencies
field, but most target types just use the vanilla field, right? That means if I only care about 
FortranDependencies
I can't tell the engine not to give me every 
Dependencies
field, only the Fortran ones? Should we subclass 
Dependencies
for each language to reduce the overhead of these requests? E.g. 
fortan_source
stops using vanilla 
Dependencies
and instead declares and uses 
FortranDependencies
.
✅ 1
a
This is a unions problem, right?
b
I don't think so. I think it's just a declaration problem. As per the docstring:
Copy code
This will
    cause the class, and any subclass, to have the injection. Register this subclass with
    `UnionRule(InjectDependenciesRequest, InjectFortranDependencies)`, for example.
Really I'm being generic, but I'm pointing the finger at 
python_sources
using 
Dependencies
.
f
many of the other language backends already have specific subclasses when they need it, e.g. 
ScalaDependenciesField
, 
GoThirdPartyPackageDependenciesField
is the question rather whether we should have a standard set of 
Dependencies
subclasses so out-of-tree plugins have a place to hook in?
b
Oh yeah, I wasn't aware Python was an odd duck. I'll file an issue for us to audit and fix
a
Every language implemented since Python was developed with a lot of hindsight
✅ 1
b
Ah turns out I can't use 
Inject...
because I need the evaluated Deps anyways 🤷‍♂️ I can get this via the provided address
Actually this brings up a good point. How can I inject dependencies using the set of dependencies without my injection as an input. I assume (and maybe I should try this) trying to request the dependencies in my injection rule would cause a rule cycle
I suppose in this case I can just make it an InferX rule, and then await the Python Infer flavor, knowing that will get cached when Pants engine also requests it
But that wont' handle other inferred/injected/explicit deps 😕
f
Is there a particular reason why your injection rule would need the current set of dependencies?
b
Given an option I want to inject the GPU flavor of a module everywhere the CPU version is used
f
and those are represented by targets?
b
So the user specifies 
--foo-bar-use-gpu
and the dependencies on the CPU-bound 
foo-bar
package are replaced with the GPU package. (Techincally all I can do is insert, not replace, see my recent issue but I have a workaround)
Specifically I want to replace 
"3rdparty/python/deps:repository#mxnet"
with `"3rdparty/python/deps:repository#mxnet-cu102`"
(but in this case just adding it is sufficient)
In reality, I can probably assume that the explicit deps and the inferred deps from the built in rules is sufficient (as I contorl my own plugins). But I think this smells of a logic flaw 😕
f
or just the limits of the current abstraction
b
yeah, thats a better phrase
OK confirmed its a rule graph cycle at least:
Copy code
Exception: The dependency graph contained a cycle:
Open in Slack
PreviousNext
Powered by