https://pantsbuild.org/ logo
Join Slack
Powered by
How do I satisfy a dependency infer/inject where I...
# plugins
b
How do I satisfy a dependency infer/inject where I eject a dependency? Alternatively, how do I ensure everywhere we use a 
pex_binary
that it doesn't depend on some address?
✅ 1
On Pants 2.11. I know 
main
has 
ValidateDependenciesRequest
Nevermind, I think i'm just going to add more hacks for this 😂
🤣 1
I guess I could ask the question, should the 
target
generic target support transitive excludes in its dependencies field? Would that work (infer a dep on that, and then it transitively ejects some target for me)?
h
no I don't think it should - the only reason 
target
exists is as a "bag of dependencies" -- we don't want to allow 
!!
mid-way in the dep graph as that makes things too hard to reason about
we only allow it for "root" targets like binaries and tests, i.e. what is not depended upon by other stuff
b
Fair enough
h
no technical limitations - just trying to keep things understandable for users
✅ 1
w
it almost crosses over into a technical limitation though
(in the sense that it would fail to work in a bunch of cases… if one of the things that was 
!!
excluded was reachable in multiple ways, in particular)
👍 1
b
Yeah I actually removed several of my hacks and replaced it with one hack here.
w
the current implementation of 
!!
should probably be moved into an explicit request other than TransitiveTargets… because currently it ends up affecting multiple roots in some cases, which is really weird
for example, right now 
./pants dependencies --transitive ::
will end up applying 
!!
excludes to all of the roots, which is just a bug.
❗ 1
…i’ll file that. this thread just made me remember a yakshave.
b
Basically, we're generating a file containing git metadata pertaining to the branch/commit. Previosuly I re-used the shell file we use for Bazel, and that involved the build file root, a rule to invalidate based on git state, and implemented the shell_command -> resource issue. The "plan" was to eject the cached, stale 
build_info.txt
and replace it with a git-commit-sensitive one for every relevant 
pex_binary
. Now, in one plugin i have a 
build_info
target generating the file (instead of re-using the Bazel shell script) and dep inference to inject it to relevant `pex_binary`s. Then I 
# pants: no-infer-dep
the string in our parser.
The end result is the file isn't in the sandbox (and the code is tolerant of that), unless we're building a 
pex_binary
that needs it. I lose caching on all my `pex_binary`s but I guess that's OK 🙂
w
mm, yea. that’s super parallel to what Benjy needed to do for `setuptools_scm`… wish that that was more general.
✅ 1
b
Yeah FYI @happy-kitchen-89482
Really I probably only want this to happen when I'm packaging my docker image, but adding the dep to the image is "too late"
4 Views
Open in Slack
PreviousNext
Powered by