https://pantsbuild.org/ logo
Join Slack
Powered by
<@U0N6C2Q9F>: re target usage for Go
# plugins
w
@fast-nail-55400: re target usage for Go
although it probably makes sense to use targets for stuff resolved from third party (as you’re doing with tailor currently), it sounds like you’re now exploring using them for the internal bits of third party artifacts
one thing to keep in mind there: it’s not strictly necessary to ~ever have a `Target`… a target is mostly a handy thing for which you have an 
Address
but to compile random bits of sources, you really just need any kind of key you can think of
so for example, if you want to invoke the compiler for one file in a third party dependency, you could have the “key” for the compile be something like:
Copy code
class GoThirdPartyFileKey:
    # The address of the third party target that this file lives in.
    address: Address
    # The actual filename to compile.
    path: str
cc @hundreds-father-404
h
I think dependency inference is the key thing Tom is after. But true that that type of dependency inference need not happen via the Target mechanism
w
Right... in theory, dependency inference and compilation could both consume the same underlying more fine-grained information about which files are in which third party deps, without actually lifting them into targets
f
right, but I found it hard last week to think how to properly model third-party packages in the build graph as transitive deps of first-party and third-party packages
by treating them as targets, they will now be treated the same as first-party go_package targets
and so the build rules can just request 
TransitiveTargets
and request the engine to build each of the first-party and third-party targets
w
what do the addresses actually end up looking like for sub-components of third party code?
f
I’d be willing to switch to something else, but having to essentially rebuild all of the rules for dependencies just because we don’t want it to be a “target” seems wastefyl
the addresses will be the name of the module concat’ed with the name of the package within the module
I don’t particularly like that part of it but it works for a v0.1
for synthetic targets, it would be nice to have a way to say that a synthetic target is “under” an explicit target and assign an address that reflects that relationship
w
so it is actually possible for first party code to depend on a sub-component of third party, without the entire third party artifact being compiled?
👍 1
f
yes, imagine just importing one package in a third-party module that exports constants and only using the constants
w
ok. yea, i guess that that makes sense then. it’s approximately as if it’s been vendored.
f
Go’s “unit of build” is the package, not the module
👍 1
Bazel rules_go has the “gazelle” tool to handle third-party deps which just downloads the third-party dep and writes BUILD.bazel files for each package in the module
what I’m doing with the Go plugin is similar in some sense but hopefully more elegant
but we do need to track deps at the package level even within third party modules
imagine a syntax for addresses to locate synthetic targets under the target that was used as their input. using 
>>
as the separator: 
src/go/foo>>ext-mod:PATH@VERSION>>pkg:internal/bar
or just having an internal ID number for synthetic targets that has nothing to do with the path on disk
or whatever works, but we shouldn’t force synthetic targets to be addressed only by path and target name
the ability to use a 
dependencies
field to link whatever data structure models the “unit of build” of a language is very powerful
and that seems to be concept of “target” currently
hence why I am modeling packages in third party code as targets
w
so, to be as accurate as possible: 
Address
now allows for modeling file dependencies. as it stands, the expectation is that a file level dependency is for a file that actually exists on disk
h
But you can also have BUILD targets w/ no 
sources
, which is what this would be
w
…but it’s still the case that when you have a file 
Address
, the thing behind it is a 
Target
… so i suppose that that doesn’t actually impact what you’re saying. the value in the key/value is still a 
Target
but the targets created automatically for file `Address`es are in some sense already synthetic targets.
➕ 1
so a totally left field possibility would be for that to be pluggable… ?
f
maybe? I’m agnostic to how exactly I can produce synthetic targets (or even that they be targets, I just need to be able to treat first-party and third-party packages in the same manner for dependency purposes, which targets currently gets me)
But you can also have BUILD targets w/ no 
sources
, which is what this would be
to clarify, the third-party packages do not have a 
sources
field since all of the source files are downloaded and not in any source root (but the package in a third party module of course actually does have source files)
4 Views
Open in Slack
PreviousNext
Powered by