A survey of where we are with targets. Lots of ins...
# development
h
A survey of where we are with targets. Lots of insights the past two years + a few open questions still. https://docs.google.com/document/d/1Xx5Vq-3Zl-uGy6Lkghg23ZriWpEsAmPAjHxau-pq-Bo/edit# Comments welcomed, including if you think there are issues with targets that we're not yet capturing
đź‘€ 1
@witty-crayon-22786 @happy-kitchen-89482 This survey leads me to believe targets are less "broken" than we've been making them out to be - we seem pretty close to already being at a really good thing:. I'm no longer as convinced we need to re-envision what a world without targets would look like
w
thanks a lot! will review before end of week.
thanks for doing this: it looks great, and is helpful for thinking about the open issues.
❤️ 1
h
You're welcome! Thoughts on this?
I'm no longer as convinced we need to re-envision what a world without targets would look like
w
i agree. although i think that changes in the area of “`name=` removal” and “how to avoid mostly empty BUILD files” would both head further in that direction from a boilerplate perspective. but i think that we will always need the atomic unit, and so the boilerplate and metadata application changes mostly just make it easier to create them
âž• 1
meaning: i don’t think that it is necessary to “have zero metadata other than `pants.toml`”… requiring at least one BUILD file is fine.
âž• 1
h
That's what I'm thinking too. Another factor there is trying to mitigate breaking changes to existing users. Yes, we should consider what we'd do if designing from scratch. But also take seriously the impact changes have on users
w
yep, for sure.
h
@happy-kitchen-89482 did you have any thoughts on this? also fyi @enough-analyst-54434 with your experience with targets + point that they don't make sense
âž• 1
e
My argument is target types don't make sense, targets - some way to write down uninferrable metada - are of course required.
đź‘Ť 1
h
Got it, thanks for clarifying. The last paragraph of "Field-driven API" is relevant to that argument:
Key point: the identity of a field comes from its Python class hierarchy, not its BUILD file alias. python_sources and go_packages both have the same sources: list[str] field, yet plugins can differentiate from them. Target types declare which Python class to use for each field, so when a user types go_package(sources=), we know to use GoPackageSourcesField rather than PythonSourcesField.
w
@enough-analyst-54434: which goes back to potentially not having any validation that what you put in your BUILD file is even relevant, or any particular thing to document to say “these are the relevant fields for python code”
but it’s relevant to some of the open questions in there: • “How to ergonomically change metadata for multiple targets?” • “How to avoid mostly empty BUILD files?”
it’s a useful summary.