<@UB2J9BQA0>: there will be a few test failures (a...
# development
w
@hundreds-father-404: there will be a few test failures (at least one related to the “go_package defined in the same directory as a go_mod case”), but here is a draft: https://github.com/pantsbuild/pants/pull/13245
👀 1
the diff doesn’t really tell the story as well as running
./pants dependencies ::
will, but the Address constructor edits all fix errors like:
Copy code
ValueError: The address `foo#./pkg` is not generated by the `go_mod` target `foo`, which only generates these addresses:

  * foo/cmd
  * foo/pkg

Did you mean to use one of those addresses?
and
Copy code
ValueError: The address `//:mod#./greeter/quoter` is not generated by the `go_mod` target `//:mod`, which only generates these addresses:

  * //:mod
  * //:mod#<http://golang.org/x/xerrors|golang.org/x/xerrors>
  * //:mod#<http://golang.org/x/xerrors/internal|golang.org/x/xerrors/internal>
  * //greeter:mod
  * //greeter/quoter:../mod

Did you mean to use one of those addresses?
h
Thanks! So,
foo/cmd
could conflict with a "default" target at
foo/cmd
, right? Looks like
//:mod
is ambiguous if it's the generated target vs. target generator, also. (Indeed, how to handle the same directory was one of the hardest edge cases for generated address syntax)
w
Mm, yes: good point. Might need to add or require a trailing slash to disambiguate.
h
I think that would actually allow us to know only based off an Address if something is a dir vs. file! No need to consult the filesystem Would we enforce that you must have the leading
/
when using an address literal, like in
dependencies
field? Could be a common gotcha
w
trailing slash probably. And yea, we would... but by virtue of the other thing not existing, probably.