hundreds-father-404
10/13/2021, 12:25 AM./pants count-loc ::
count all files, or only files owned by targets? https://docs.google.com/document/d/1WWQM-X6kHoSCKwItqf61NiKFWNSlpnTC5QNu3ul9RDk/edit#heading=h.kwc67nd5ho7mwitty-crayon-22786
10/13/2021, 9:09 PM::
not matching unowned files seems finehundreds-father-404
10/13/2021, 9:10 PMdir
is a synonym for dir:
, and dir::
is the recursive version of that
So, are we sticking to dir:
and dir::
being "address" specs, or they're really now dir specs? (If the latter, I've been pondering for last 15 minutes if address specs vs. filesystem specs even makes sense and we somehow merge Specs)./pants count-loc ::
is only sources owned by targets"**/*"
to mean "all sources, regardless of targets". So I don't think we need to change ::
to now do that./pants count-loc path/to/dir
will fail if there are no targets in that dir. You'd have to use ./pants count-loc 'path/to/dir/*'
witty-crayon-22786
10/13/2021, 9:15 PMcount-loc $dir
would have done beforehundreds-father-404
10/13/2021, 9:15 PMdir:dir
, so it errorswitty-crayon-22786
10/13/2021, 9:18 PMhundreds-father-404
10/13/2021, 9:21 PM./pants count-loc dir
would still error if there were no targets, as dir
is short for dir:
now
It could be that we decide we normally want dir
to act like dir:
, but we make an exception for validate
and sources-snapshot
? You use dir:
if you only want owned sources? That might work. And then I guess you must use 'dir/**/*'
for recursive case, given that we agreed it's not worth it to add dir/...
witty-crayon-22786
10/13/2021, 9:22 PMSpecs
expansion dependent on whether you’re requesting files or targets… which is maybe fine. but right now that’s decided statically at parse time, right?hundreds-father-404
10/13/2021, 9:23 PMcount-loc
! It's great because you don't need any BUILD files to try it
Benjy understandably wants to rewrite it to use files, dirs, and I would imagine dir::
, which are the only 3 address forms you typically would need. (Plus sometimes address literal)witty-crayon-22786
10/13/2021, 9:24 PMSpecs
… it’s more to do with those goals than anything else.dir
to mean “all targets in dir” seems strictly like a step forward for this case, and the fact that it’s always been ambiguous whether dir
was a filesystem spec or an address spec isn’t changing herehundreds-father-404
10/13/2021, 9:25 PMwhich is maybe fine. but right now that’s decided statically at parse time, right?Yeah. I think we would have a new rule somehow wrapping
Specs -> Addresses
, which allows you to set whether to convert DirLiteralSpec
into SiblingAddressSpec
or keep it that. Then a rule that wraps that to return a singleton, such that most callers don't need any changes at allwitty-crayon-22786
10/13/2021, 9:27 PMhappy-kitchen-89482
10/13/2021, 9:28 PM./pants count-loc ::
not to consider files that aren't owned by a targetwitty-crayon-22786
10/13/2021, 9:29 PM::
was going to match all files, then we should remove support for `**`… and that seems like more than we should bite off here.hundreds-father-404
10/13/2021, 9:31 PMFilesystemSpecs
and AddressSpecs
in today's world.
Definitely it does make sense to have the classes FileLiteralSpec
and AddressLiteralSpec
etc, i.e. preserve precisely what the user specified. Then we can lazily interpret the semantics from there. But, yeah, whether we have separate rules for those collection types, vs. everything being in Specs
I agree that I think we can punt on that implementation. I thought I needed it for preworkhappy-kitchen-89482
10/13/2021, 9:38 PMif was going to match all files, then we should remove support for `**`… and that seems like more than we should bite off here.::
**
until we get around to removing support for it::
works the way I want it tohundreds-father-404
10/13/2021, 9:44 PMIt's not doing harmYeah, not a ton of code to support it. And we don't need to document it either