A while back I saw some proposal on having differe...
# development
f
A while back I saw some proposal on having different dependency graph types for different goals. (For example, in Python, check deps might include more modules than a test type). Has this gone anywhere?
Motivating context for question: I'd like mypy config changes to trigger all mypy checks but not necessarily all tests
I assume "normal" pants usage would be to just rely on the cache for this rather than the
changed
subsystem
b
Well the OP is referencing my proposal, I think. No, it hasn't made explicit progress, although @proud-dentist-22844 is laying the groundwork, which is really cool. As for your
mypy
thing, that seems different. If you change the
mypy
config, that likely wouldn't be invalidating the process runs for tests, unless you have the config modeled in your Pants targets.
👍 1
f
The problem is that I'm basically doing:
Copy code
pants \
  --changed-since=main \
  --changed-dependeeds=transitive \
  lint check test
So if my mypy config gets changed (itself not a pants target), but nothing else, that commands won't trigger any lint check or test actions because according to Pants nothing has changed.
And I don't have caching set up well enough to rely on bare
pants lint check test
being efficient (and I don't have time to work on that right now)
b
You'll need to wire up Pants' "synthetic targets" support then. Currently (IIRC) that's only wired up for lockfiles.
f
So theoretically what I'd like to be able to do is model
mypy.toml
as a check-only dep
b
And now my original message comes full-circle. This would invalidate all targets that depend on it
f
yeah that's what I thought
I don't need synthetic targets to do that, I could just do
file(source="mypy.toml")
b
Then you'd also need the "tagged dependencies" proposal I made a while back. I envision several flavors of tags. One would be which goal(s) a dependency is relevant for.
f
okay that's exactly what I was looking for
and those tags would affect how the dep graph gets traversed for building transitive targets for different goals
b
.............umm what if you did the
file
thing (or the synthetic target if you're feeling generous) and made a dependency from the
mypy
requirement? It may or may not work. ALso try with
resource
f
hmmm
Doesn't work... "mypy" isn't a target so it's not knowable to the changed subsystem
b
It can be in the 2.16. world if you use the new "user resolve" feature for tools
oh... yeah I see
f
I've played with that but I don't think it will work
I could wrap the mypy invocation in an adhoc_tool maybe 😄
I mean... I can deal with this outside of Pants, but I'm starting to understand kinda the limits of the
--changed
subsystem vs relying on caching completely. Obviously if you just run
pants check
and rely on caching to get it right, the mypy configs are part of the cache key for the mypy process executions, so if they change you get a cache miss, and this "just works." But using
--changed
is easier when you don't have the time to invest in getting distributed caching working right. I suppose I could implement a poor man's tagged dependency plugin
p
@bitter-ability-32190 where is that "tagged dependencies" proposal? I just looked in "Pantsbuild Design Docs" folder in Google Drive and searched github for issues/discussions, but I must be searching for the wrong thing.
b
It was never called that, but that was the eventual conclusion.