Example situation. Package A defines some integration tests that need to run the binary from package B. I would expect that it would be sufficient to add a dependency on B_dist (python_distribution providing the binary) into A/tests/BUILD and the B package respectively the binary will be installed in the A/tests environment. But it seems that the required binary is not available there (call to subprocess.Popen fails). Do I need to start that binary using another approach? What would you recommend?

To clarify the role of B_dist - it's just a way of providing metadata that gets passed to

setup.py

. Depending on it doesn't do anything. If you want to depend on a published version of B then you do so like any other "3rdparty" requirement (but you have to have published it first). But I'm guessing that's not what you want? Typically since

A/tests

and

B

are in the same repo you would have

A/tests

depend on

B

as an internal dependency. That is,

A/tests

's

python_tests

should depend on B's

python_library

(not its

python_distribution

). Then the test can invoke B's code directly (rather than spawning a process to run it).

There are also unit tests where I'm using imported code... But certain integration tests where inter-process communication happens rely on spawning processes (e.g. mock of database, etc.). You are right - depending on a published version is not what I want here. These integration tests (among others) should be run for each PR/push, during development...

Would this be what you’re looking for? https://www.pantsbuild.org/v2.0/docs/rules-api-testing#approach-4-run_pants-integration-tests-for-pants This test utility allows you to run full Pants commands as an integration test. In your test, you could run ./pants setup-py for example. You could then do whatever you want with the result, including inspecting the files that were created.

@hundreds-father-404 Could be! Initially, I thought it is only for testing of plugins but it can probably be used to run any script within the project, right? With something like:

run_pants(["run", "src/python/package_A/script"])

Using this approach, is it possible to run multiple binaries at the same time? I will give it a try, thanks for the tip!

Initially, I thought it is only for testing of plugins but it can probably be used to run any script within the project, right?

Typically, it’s designed for running on synthetic test projects created via

setup_tmpdir()

. I imagine you want to run on your actual project, rather than some contrived example, right? This is where things would start to fall apart. Tests run in a chroot (tmpdir) in Pants, meaning that they will only copy over files that are known about through the

dependencies()

field. (Why? This allows us to safely run tests in parallel and remote execution). So, your test would not have access to

src/python/package_A/script

. You could put a dependency on the

python_binary

target in

src/python/package_A/script

, but that won’t do what you’re expecting. That will copy over the Python files with the source roots stripped, like

package_A/script

. It won’t copy over the raw file, and it won’t copy over the BUILD file either. So,

run_pants(["run", "src/python/package_A/script"])

would complain “No BUILD file in src/python/package_A/script”. You could work around that by declaring a

files()

target owning that script, and owning its original BUILD file. A

files()

target doesn’t strip source roots - the files get copied exactly as-is. Then, add a dependency to the

files()

target to the

python_tests()

. That works fine, and we do that for several Pants integration tests. Unless…`src/python/package_A/script` depends on a bunch of other files, like most projects do. You would need a

files()

target owning all of its transitive dependencies..which we’ve found is not feasible to do. So, my suggestion is only helpful if either a) you’re okay with creating a synthetic target, or b)

"src/python/package_A/script"

has very few dependencies. I suspect neither of those are true, unfortunately. -- Given the above, Benjy is thinking through more robust ways to do what you’re asking

Thanks for the exhausting info!

I imagine you want to run on your actual project, rather than some contrived example, right

Exactly. Unfortunately, scripts have quite a lot of dependencies. Looking forward to hearing about some more robust way 🙂 At the moment I had to disable integration tests. Many thanks!