I would like to be able to use wildcards when decl...
# general
l
I would like to be able to use wildcards when declaring dependencies in a BUILD file. For context we have a bunch of django apps in one repo which are part of one django project. When running migrations I would like to be able to depend on
src/django_apps/::/migrations
, but it seems that I can't do that in a BUILD file. Is there a good way around this? Or will we need to manually manage that list?
w
Can you give an example of what your BUILD file might look like? I assume each of these migrations are py files? Like, is there anything wrong with using the
files
or
resources
target and depending on that?
l
i have resource targets for each of the migrations directories, i just have 42 of them
and I need manage.py to depend on all of them
i want to be able to write a build file like
Copy code
python_sources()

pex_binary(
    name="manage",
    entry_point="manage.py",
    dependencies= [
        "src/django_apps/:/migrations:migrations",
    ]
)
but the
:
in the middle won't work as a wildcard
w
So, if you had a resources or files target with a glob to grab your migration files, that won't work for your usecase?
More specifically, something like this?
Copy code
files(
    name="mymigrationstuff", 
    sources=["**/migrations/*.py"]
)

# This is just here so I could sanity test this glob
archive(
    name="arch", 
    format="zip", 
    files=[":mymigrationstuff"]
)
l
yeah I think the problem with that is that I will end up with overlapping file ownership
like I already have targets for all these files, I just need to depend on a large number of targets
w
Ah okay, then I'm less sure of a solution
e
Would we be able to write a small target plugin that determined the deps for us using our own logic?
h
Hey late to this thread, but check out discussion at https://pantsbuild.slack.com/archives/C046T6T9U/p1646345506591589 Yes @eager-dress-66405, see near the end of the thread for instructions on how to do so 🙂 I'm definitely curious y'alls feedback on Josh's
dependencies_globs
field - the idea of having a distinct field is a really interesting one imo that resolves my major concern
e
How timely! A plug-in that would add a dependency_globs field to existing targets without further overloading the target syntax is both a very clever solution and a great example of the flexibility of the plug-in system.
🙌 1
h
Definitely if folks are interested, there's potential for
dependency_globs
moving into Pants core! A big question I'd have is whether
dependency_globs
should be sources paths -> finding the
Owners
of those sources, vs. some new glob syntax for `Address`es. That new glob syntax is what I'm less confident on, given how complex Address syntax already is. I don't love the idea of inventing Yet Another Syntax to learn. I guess we do have
dir:
and
dir::
globs for addresses tho
e
I hear you. Prefix globs+regex match? 😑 What about flipping the relationship- add a way for a target to depend on everything with a particular tag
h
I could see a use for that. I think what that suggests to me though is this might be one of those times it's too hard to generalize well, so instead we have several essentially prebuilt plugin hooks you can copy & modify. That's what we tried to do with the custom
setup_py()
kwargs plugin hook, for example. Unclear to me
👍 1