https://pantsbuild.org/ logo
Join Slack
Powered by
Hi all: What happens to the dependencies section i...
# general
f
Hi all: What happens to the dependencies section in pants v2?
w
hey Ahmed! can you expand on what you mean? you can still add dependencies lists in BUILD files
e
It hasn't changed except that you need to manually enter things there less often. See an intro over here and let us know if you have more questions: https://www.pantsbuild.org/docs/targets#dependencies-and-dependency-inference
f
@witty-crayon-22786 Yeah, I looked at the examples and I found they are not there for pex_binary types. I use the dependencies for other internal tools such as sharding and continuous deployment.
w
you can run the 
./pants dependencies
goal to dump out the inferred dependencies
f
The sharding in v1 had some issues for multiple targets, so we developed our own sharding for running the tests in the CI server.
@witty-crayon-22786 but it's still backward compatable with pants v1, right?
w
./pants dependencies
? yes, it is
f
No, not that command. Adding dependencies to the targets.
w
you can manually add all of the dependencies to targets if you’d like to… dependency inference (see John’s link) is on by default: if you’d like to only support manually added dependencies, you can turn it off.
but we would recommend using inference. see https://blog.pantsbuild.org/dependency-inference/ for more info beyond what is on the docsite.
f
I have in my code for example an import for dev_constants that I don't include in the final product pex file. That's why I asked. Plus, we use build files to decide what needs to be deployed, or what tests need to run.
How do I turn it off in pants v2?
If I include it in the BUILD file, does it get turned off?
w
it can be turned off globally using https://www.pantsbuild.org/docs/reference-python-infer
adding dependencies in BUILD files doesn’t turn off inference (because as you mentioned, not all dependencies can be inferred).
but we would recommend against parsing BUILD files in your code, and would suggest using 
./pants dependencies
to do that instead. that’s backwards compatible, and supports both inference and manual dependencies.
also, it’s worth noting that Pants v2 will run tests in parallel, so some smaller uses of sharding might not be necessary.
f
Yeah, but that won't work for me. I read the BUILD files from Python via a custom parser I wrote. If I run 
./pants dependencies
, it means I will need to run it via os.system, or a subprocess. That is extramurally slow. It means we will need to run that command on every modified target. We had that originally implemented in first version of our continuous deployment script, and I replaced it with a custom parser. We had almost 100x improvement after I did that.
For the sharding, it won't work. Some of the tests interfere with each others, we run the tests in containers. Where each container runs a shard number.
w
regarding running 
./pants dependencies
once per target: that’s not what we would recommend: see https://www.pantsbuild.org/docs/using-pants-in-ci#recommended-commands instead
try running 
./pants --changed-since=origin/main --changed-dependees=transitive list
in a branch, and see how long it takes
f
😄
Our branching system is kinda ackward
It's like this
mw-4.1.0, mw-4.1.1 and so on
We don't have a single main or master.
w
sure… you can pass in whatever merge-base you would like. the 
--changed-since
flag takes a git-ref as an argument.
f
I will give it a try
Thank you ^_^
w
sure thing!
5 Views
Open in Slack
PreviousNext
Powered by