OK. Next fun bit of BUILD file madness around awkw...
# general
p
OK. Next fun bit of BUILD file madness around awkward fixture usage. There are several files that glob over the fixtures like this: https://github.com/st2sandbox/st2/blob/pants/st2api/tests/unit/controllers/v1/test_pack_config_schema.py#L24-L26 That glob uses fixtures from this directory (specifically all of the packs that include a
config.schema.yaml
file): https://github.com/st2sandbox/st2/tree/pants/st2tests/st2tests/fixtures/packs For the tests that use individual fixtures, I can import from a python file in the pack's subdir to make pants include the fixture. Is there a way to have a generic target that depends on all the targets with a
*/config.schema.yaml
file (the globs vary slightly, but the one I linked to above is looking for fixture packs that include this file)? If so, I could probably have another subdir (maybe called
config_schema_glob
) that says it depends on all such targets. If not, any good ideas on how to make this pants-friendly?
w
there isn’t a way to depend on a glob of targets, but targets can own globs of files… so the most obvious fix would be to define a single target that owns all of the
config.schema.yaml
files, and then explicitly add a dep on that
files
target to the code that depends on it
if it is a common pattern to have a set of loose files with a particular name next to a test target, you could add a macro that creates both a
files
target and the
python_tests
target in one invoke: https://www.pantsbuild.org/docs/macros
h
Targets can own lists of files, and lists of globs of files, so you can also enumerate, you don't have to concoct a single glob that covers all the files (I wasn't clear in your case if that was practical or not)
1
p
All of these config.schema.yaml files are already owned by targets which are used individually by a bunch of tests.
And I don't just want the
config.schema.yaml
files, I also need everything else in the current target that includes that file.
If I add my own target, could I dynamically generate its dependencies so that it depends on the appropriate targets in subdirs?
ok. I found something that'll work. I have to register all of the packs in a generic
target
but it seems to be the simplest approach. https://github.com/st2sandbox/st2/commit/4fc6347d6d4812610e2fc6560362e1568cd3c8f4#diff-0a765a0e1409bcce280bee085b[…]219b4c63a442696f8d23216a525d882a
👍 1