and I are finding that the new Go support

Question

< 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` thread

hundreds-father-404 · Answer

< 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 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

hundreds-father-404 · Answer

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

witty-crayon-22786 · Answer

shouldn t ` pants test src go` work via default targets

witty-crayon-22786 · Answer

but also note that as < fast nail 55400> mentioned elsewhere `go` is not recursive by default so defaulting to recursive as suggests would actually diverge from `go` s behavior while aligning with `git` s

hundreds-father-404 · Answer

gt shouldn t pants test src go work via default targets No because the `spec path` of generated targets is the target generator s neutral face And fixing that would be really hard to land It would break our `Address gt 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 gt WrappedTarget` rule

witty-crayon-22786 · Answer

gt 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

hundreds-father-404 · Answer

gt 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

witty-crayon-22786 · Answer

i don t think it s a separate topic adding that semantics for a language that has different semantics would be odd

hundreds-father-404 · Answer

gt sure but it will match the generator which depends on the generated targets right Not quite Let s say you have ` lt root gt 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

witty-crayon-22786 · Answer

< hundreds father 404> targets at the root are a bit different because they don t have default names

hundreds-father-404 · Answer

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

hundreds-father-404 · Answer

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

witty-crayon-22786 · Answer

gt 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

witty-crayon-22786 · Answer

oh i see what you are saying

hundreds-father-404 · Answer

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

witty-crayon-22786 · Answer

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

witty-crayon-22786 · Answer

but the directory matching aspect is different

hundreds-father-404 · Answer

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

happy-kitchen-89482 · Answer

gt Thoughts on decoupling the CLI specs change from the bigger discussion

happy-kitchen-89482 · Answer

I have been advocating for this for a while including repeatedly on that issue

happy-kitchen-89482 · Answer

I think fixing the CLI specs has immediate positive impact on users dealing with that quirk in BUILD files is far less important

hundreds-father-404 · Answer

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

witty-crayon-22786 · Answer

as recursive or not

hundreds-father-404 · Answer

Will start a dedicated thread to bikeshed that

happy-kitchen-89482 · Answer

Not sure about even an option gate

happy-kitchen-89482 · Answer

That might add more complexity than it s worth

hundreds-father-404 · Answer

Option gate is solely to handle backwards compat Will be deprecated