https://pantsbuild.org/ logo
Join Slack
Powered by
<@U0N6C2Q9F> and I are finding that the new Go sup...
# development
h
@fast-nail-55400 and I are finding that the new Go support is awkward to use without directory specs. Because Go is directory-based, it's weird to say 
./pants test src/go/foo_test.py
as a way to test all of 
src/go
. It's natural to use 
./pants test src/go
. 🧵
@happy-kitchen-89482 has proposed directory args before. But it's blocked by how 
path/to/dir
is currently shorthand for 
path/to/dir:dir
. That applies to both CLI args and BUILD files with 
dependencies
field etc. https://github.com/pantsbuild/pants/issues/12286 discusses removing that shorthand entirely, but it got stuck in discussion about whether to always require 
name=
vs. make target generators be address-less vs. other ideas. That will require a lot more design to resolve, they're big changes Instead, @fast-nail-55400 and I are thinking that we should punt on the bigger question about what to do with 
name=
, and go ahead fixing CLI specs. BUILD files will still (for now) use the shorthand, but we add an option so that CLI specs no longer treat dirs as target addresses Thoughts on decoupling the CLI specs change from the bigger discussion?
cc @witty-crayon-22786, we might want to try to land this in 2.8 so that 2.9's default behavior can be using directory specs. (With an option to keep old semantics)
w
shouldn’t 
./pants test src/go
work via default targets?
but also, note that as @fast-nail-55400 mentioned elsewhere, 
go
is not recursive by default, so defaulting to recursive as https://github.com/pantsbuild/pants/issues/12286 suggests would actually diverge from `go`’s behavior (while aligning with `git`’s)
h
shouldn’t ./pants test src/go work via default targets?
No because the 
spec_path
of generated targets is the target generator's 😐 And "fixing" that would be really hard to land. It would break our 
Address -> WrappedTarget
, which requires knowing the Address of the target generator - if we no longer have that Address, we have to start using 
Specs
in the 
Address -> WrappedTarget
rule
w
No because the 
spec_path
 of generated targets is the target generator’s
sure, but it will match the generator, which depends on the generated targets, right?
h
go is not recursive by default, so defaulting to recursive as https://github.com/pantsbuild/pants/issues/12286 suggests would actually diverge from go’s behavior (while aligning with git’s)
Yep, whether dir specs should be recursive or not is a separate, related question. I think we should keep that to a separate thread. Here, only focus on "Should we implement directory specs before we figure out what to do with 
name=
and address-target generators?"
w
i don’t think it’s a separate topic… adding that semantics for a language that has different semantics would be… odd
h
sure, but it will match the generator, which depends on the generated targets, right?
Not quite. Let's say you have 
<root>/go.mod
and 
dir/foo_test.go
. You'll have the generated target 
//:mod#./dir
. When you say 
./pants test dir
, that will look look for a target called 
dir:dir
, which does not exist
w
@hundreds-father-404: targets at the root are a bit different, because they don’t have default names
❓ 1
h
Okay, let's consider then 
src/go/go.mod
and 
src/go/dir/foo_test.go
. You have a generated target 
src/go#./dir
. Specificying 
./pants test src/go/dir
looks for 
src/go/dir:dir
, and fails
vs directory specs would look for the 
Owners
of 
src/go/dir/*
(or 
src/go/dir**/*
if we use recursive specs), and it will work
w
You have a generated target 
src/go#./dir
. Specificying 
./pants test src/go/dir
 looks for 
src/go/dir:dir
, and fails
shouldn’t the generator have the default name in this case? why would it be named?
oh, i see what you are saying.
👍 1
h
Concretely, a directory spec would be shorthand for file specs. 
dir/
is shorthand either for 
dir/*
or 
dir/**/*
, depending on how we approach recursion Like file specs, it uses 
Owners
code path
w
this relates to the second half of my comment from https://github.com/pantsbuild/pants/issues/13086 … changing how 
Specs
work so that they can also match generated targets
but the directory-matching aspect is different.
👍 1
h
Yeah, related, but I think different. Changing how Specs work for generated targets would impact the behavior of 
./pants test src/go/dir::
, which is totally broken if your 
go_mod
is in 
src/go
. That is, "address specs". That will be important to figure out, but I think is a much harder problem I'm talking about the behavior of 
./pants test src/go/dir
. No longer meaning 
dir:dir
(address spec), and instead all targets (that own sources?) in 
dir
, and possibly subdirs (filesystem spec)
h
Thoughts on decoupling the CLI specs change from the bigger discussion?
I have been advocating for this for a while, including repeatedly on that issue...
➕ 1
I think fixing the CLI specs has immediate positive impact on users, dealing with that quirk in BUILD files is far less important
👍 1
h
True. Great. So if we can agree to implementing directory specs (via an option gate), then I think it's actually really easy to implement, like 1-2 days
w
as recursive, or not?
h
Will start a dedicated thread to bikeshed that
h
Not sure about even an option gate
That might add more complexity than it's worth
h
Option gate is solely to handle backwards compat. Will be deprecated
Open in Slack
PreviousNext
Powered by