hundreds-father-404
10/11/2021, 7:43 PMdir
, vs. having some new syntax?dir/...
Maybe we stick with dir::
and fix the weirdness with address specs and generated targets so that does what the user expectsfast-nail-55400
10/11/2021, 7:44 PM::
Ā orĀ ā¦
) that the user wants recursion. Otherwise, we will likely need a way to signifyĀ notĀ recursing, for example, when the user just wants to run a test in a single Go package.Ā (Also, note that Go is not recursive by default.)proposed copying Go for recursive semantics,ĀTo clarify, I had pointed it out as a type of syntax signifying recursion, but I donāt have a particular care whether that is the syntax or not.dir/...
hundreds-father-404
10/11/2021, 7:45 PM::
or ...
./pants tailor
is recursive, which works great! And we should probably keep. But I think that tailor
and test
have very different use cases, and we can have the semantics diverge possibly. If we don't want to diverge, privilege `test`/`list`/`lint` etc over tailor
witty-crayon-22786
10/11/2021, 7:50 PMhappy-kitchen-89482
10/11/2021, 7:50 PMact on this dir
as act recursively on this dir and all subdirs
witty-crayon-22786
10/11/2021, 7:51 PMgit
. but probably no go
or JVM
tooling doeshappy-kitchen-89482
10/11/2021, 7:52 PMtailor
for example)witty-crayon-22786
10/11/2021, 7:52 PMhappy-kitchen-89482
10/11/2021, 7:53 PM:
hundreds-father-404
10/11/2021, 7:53 PMtailor
for sure.
Others don't seem clear to me. I think it's really useful to say only format src/python/pants
, without recursing into all ~200 files under it. I think it would be more useful to default to current dir, and have 2-3 chars to signify recursionhappy-kitchen-89482
10/11/2021, 7:53 PM"path/to/**"
is understood by users, and would actually work as long as they quoted the glob so the shell didn't expand itwitty-crayon-22786
10/11/2021, 7:57 PMhundreds-father-404
10/11/2021, 7:57 PM"path/to/**"
, either by "fixing" ::
to do the right thing with generated targets, or by adding ...
for examplewitty-crayon-22786
10/11/2021, 7:59 PMdir
being equivalent to dir:
, yea? and the other thread suggests that dir:
should match generated targetshundreds-father-404
10/11/2021, 8:01 PMdir
does not recurse by default
I'm trying to figure out the connection between dir
and `dir:`/`dir::`...
One crucial nuance. Even if you completely ignore generated targets, dir::
only matches targets defined in dir
and below. Whereas file arguments match targets that "own" files even if those targets happy-kitchen-89482
10/11/2021, 8:05 PMhundreds-father-404
10/11/2021, 8:08 PMf.ext
⢠`dir`: all targets that own files in dir/*
, and (per the other thread) also all targets that are defined in dir
(including generated targets that ~live in that dir)
⢠dir:
, all targets that are defined in dir
(including generated targets that ~live in that dir)
⢠dir::
, all targets that are defined in dir
or subdirs (including gneerated targets that ~live in those dirs)
So, dir:
is a subset of dir
.
The generated targets thing is a bug fix we have to make, which was impacting file targets too. Fixing it means that ./pants test src/go/dir:
will test targets even if they were generated from src/go:mod
witty-crayon-22786
10/11/2021, 8:09 PMthere is a lot hanging on the ā~liveā bit⦠but yea. i think itās clear what we want to happen there., all targets that are defined in dir or subdirs (including generated targets that ~live in those dirs)dir::
hundreds-father-404
10/11/2021, 8:10 PMdir
including file-less targets, per the other thread. Otherwise ./pants package dir
wouldn't build go_binary
targets etcthere is a lot hanging on the ~liveAgreed. Does this make sense for implementation? Generated targets gain a new internal mechanism to say what directory/file they "live in". Even though
src/go#./dir
really is defined in src/go
, it can indicate via a property that it ~represents/~lives/~adopts the dir src/go/dir
Our Specs code will generate all candidate targets and inspect that property to determine it should match
I think this is what you've been saying, that we need to change Specs code, not necessarily other places.
I'm trying to avoid having to change the Address syntax. I really like that generated_name
can be anything you want, such as a file-less name like #Django
vs. a file name like #foo.py
vs. ./go_dir
witty-crayon-22786
10/11/2021, 8:14 PMhundreds-father-404
10/11/2021, 8:20 PMdir:
is different than dir
because it does not include targets defined in ancestor BUILD files who "own" files in dir
. dir::
would be different than dir/...
in the same way
And "dir/**/*"
is also not the same thing as dir/...
, given that file arguments don't match file-less targetsdir/...
would make address specs less and less useful. The only time to use them is when you want to avoid Owners
code, to get really precise about which targets to operate on
At that point, does it even make sense to support ::
and :
? (The literal target address probably always makes sense)happy-kitchen-89482
10/11/2021, 9:40 PMdir::
does not incude files whose targets are in a parent?hundreds-father-404
10/11/2021, 9:41 PMwitty-crayon-22786
10/11/2021, 9:42 PMā¦? it doesnāt feel like we need separate, all targets that are defined in dir or subdirs (including generated targets that ~live in those dirs)dir::
dir/ā¦
syntax if dir::
does that�./pants validate "**/*"
) is carrying its weight, given that it basically always needs to be escapedhundreds-father-404
10/11/2021, 9:46 PMit doesnāt feel like we need separateĀ dir/ā¦Ā syntax ifĀ dir::Ā does thatā¦?Indeed, depends if we change
dir::
to include ancestor targets that "own" files in the dirs. Unclear to me what the value of the old semantics is, only that it's more precise than dir/...
witty-crayon-22786
10/11/2021, 9:46 PMā¦
) exclusively for the sake of file-globs)hundreds-father-404
10/11/2021, 9:49 PMa little bit offtopic.Doesn't seem off topic - I think it's very relevant. What do we want
:
and ::
to mean? Do we keep them and add dir
and dir/...
with those subtly different ownership semantics? If we keep them and "fix them", why have dir:
given that dir
is the same thing?happy-kitchen-89482
10/11/2021, 11:34 PMall files in all dirs under this dir
?...
?hundreds-father-404
10/11/2021, 11:49 PMdir/...
? Imo it's much more useful than dir::
. It operates on everything that "lives" in dir
and below, whether that be that the target is defined there, it's generated into there, or it owns a file in there
dir::
is what's weird - why would you only want to operate on what is defined there or generated into there, but not operate on ancestor targets that own files there? Project introspection I think is the only thing I can come upwitty-crayon-22786
10/11/2021, 11:52 PM::
rather than adding ā¦
hundreds-father-404
10/11/2021, 11:55 PM:
? If we "fix" ::
, then we should apply the same fix to :
, which means dir
is identical to dir:
witty-crayon-22786
10/11/2021, 11:56 PMhundreds-father-404
10/11/2021, 11:56 PMwitty-crayon-22786
10/11/2021, 11:57 PMhundreds-father-404
10/12/2021, 12:00 AMyou only want to operate on what is defined there or generated into there, but not operate on ancestor targets that own files thereIt's unclear to me if there is? For example, we use DescendentAddresses in our plugin code a lot. Do we really want it to be using Owners code path?
i guess that one answer to that is: ābecause there is a question of whether a file ā~livesā in its own directory, or ā~livesā in the declaring targetās directoryāReminder that address specs != "files". They operate solely in the domain of targets/addresses/BUILD files
::
and :
, but that the majority of folks wouldn't need it and it would mostly be used for plugin APIhappy-kitchen-89482
10/12/2021, 12:11 AM...
just adds confusion. dir:
should probably be the same as dir
and dir::
should be "the targets for all files under `dir`"dir::
are in a filesystem-centric CLI worldhundreds-father-404
10/12/2021, 12:20 AM:
because dir
and dir:
would be the same. I think dir::
generally makes sense to have two colons as it mirrors **
vs. *