https://pantsbuild.org/ logo
Join Slack
Powered by
Hello, some questions on the story around Target A...
# development
h
Hello, some questions on the story around Target API backwards compat for V1. 1. Is it true that Pants must still work with custom V1 targets without writing V2 bindings? Right? 2. For V2-only goals like 
list
and 
filter
, they must be able to meaningfully operate on V1-only targets, correct?
w
re 1: no, i don't think that that is a requirement. in your doc you mention BUILD file level compatibility: that's sufficient, i think.
and i think that the implies that 2 isn't a concern.
..., so, re: 1: there is a bit of subtlety there that i missed.
we will definitely be in a state where python is ported, but JVM is not.
so in that regard, yes... both of those symbols will need to be able to parsed from BUILD files.
but it might be reasonable to say (for example), that "Structs are Structs, and are common across v1 and v2"
h
For 1, do we go through the normal deprecation cycle? My concern with making people write V2 bindings is that we lose substantial ability to change the Target API. Maybe once the dust settles in two weeks, that’s fine? Writing the bindings can be as trivial as:
Copy code
class CustomField(BoolField):
   alias = "custom_field"


class JavaVersion(StringField):
   alias = "java"

class JavaLibrary(Target):
  alias = "java_library"
  core_fields = (JavaVersion, CustomField)
That is, I don’t expect bindings to take much time and I would be happy to commit to writing high-quality documentation (already on my roadmap) -- NB: this is only bindings - we are not expecting you to actually use V2. The bindings will convert back down into V1 targets automatically.
w
but that a v2 target could not depend on a v1 target
h
It would be much much easier to keep goals like 
list
and 
filter
working, i.e. goals that must work on V1 targets, if we required bindings, even if over a deprecation cycle
w
re: bindings: that would be one option, but it doesn't help with internal targets
h
internal targets?
w
closed source
h
Like, custom targets written by internal plugin authors?
w
yes
h
The expectation would be that they need to write bindings before 1.29. Again, no need to actually use V2, only that they need to write the minimum amount of bindings
For complex fields, they could even subclass `UnimplementedField`:
Copy code
class Provides(UnimplementedField):
   alias = "provides"
(That’s it)
w
yea, potentially.
and the advantage to bindings over "lowest common denominator being Struct" is that v2-ized goals like 
list
cannot operate on struct, and need something higher level?
h
Without requiring bindings, the only path forward I see is to keep around 
TargetAdaptor
or a variant of it. Then, we’d need V2 list to request both 
Targets
and 
LegacyTargets
and know how to work with both the Target API and this backwards-compatibility shim
and the advantage to bindings over “lowest common denominator being Struct” is that v2-ized goals like list cannot operate on struct, and need something higher level? (
Precisely
I mean, we could make it work. But it would make V2 goals that need to operate on all target types really tricky to implement without breaking V1
w
i think that bindings would be ok.
👍 1
especially if it allowed for simplifying the symboltable situation sooner.
💯 1
especially if that meant replacing the "Adaptor" abstraction, which was always supposed to be temporary.
h
Awesome. FWIT, I wouldn’t advocate bindings if I thought it would be a high burden for plugin authors (e.g. requiring actually using V2). But, it’s extremely easy to write them and we’ll write great documentation on how to do it. They don’t need to actually add any custom validation etc - all we care about is that they explicitly register every field alias and target alias so that we can wire it up to the SymbolTable
especially if that meant replacing the “Adaptor” abstraction
Exactly my thoughts. Without requiring bindings, we not only need to keep around Adaptor, but we also need to teach our V2 rules to handle both adaptor and the Target API, which would be a net loss from the situation 2 weeks ago
w
sounds good
💯 1
Open in Slack
PreviousNext
Powered by