Hi all: What happens to the dependencies section in pants v2?

hey Ahmed! can you expand on what you mean? you can still add dependencies lists in BUILD files

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

@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.

you can run the

./pants dependencies

goal to dump out the inferred dependencies

The sharding in v1 had some issues for multiple targets, so we developed our own sharding for running the tests in the CI server.

./pants dependencies

? yes, it is

No, not that command. Adding dependencies to the targets.

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.

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.

it can be turned off globally using https://www.pantsbuild.org/docs/reference-python-infer

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.

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

😄

sure… you can pass in whatever merge-base you would like. the

--changed-since

flag takes a git-ref as an argument.

I will give it a try

sure thing!