> Initially, I thought it is only for testing o...
# general
h
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