https://pantsbuild.org/ logo
#development
Title
# development
h

hundreds-father-404

03/21/2020, 10:58 PM
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

witty-crayon-22786

03/21/2020, 10:59 PM
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

hundreds-father-404

03/21/2020, 11:04 PM
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

witty-crayon-22786

03/21/2020, 11:04 PM
but that a v2 target could not depend on a v1 target
h

hundreds-father-404

03/21/2020, 11:05 PM
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

witty-crayon-22786

03/21/2020, 11:05 PM
re: bindings: that would be one option, but it doesn't help with internal targets
h

hundreds-father-404

03/21/2020, 11:05 PM
internal targets?
w

witty-crayon-22786

03/21/2020, 11:06 PM
closed source
h

hundreds-father-404

03/21/2020, 11:06 PM
Like, custom targets written by internal plugin authors?
w

witty-crayon-22786

03/21/2020, 11:06 PM
yes
h

hundreds-father-404

03/21/2020, 11:07 PM
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

witty-crayon-22786

03/21/2020, 11:07 PM
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

hundreds-father-404

03/21/2020, 11:09 PM
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

witty-crayon-22786

03/21/2020, 11:09 PM
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

hundreds-father-404

03/21/2020, 11:12 PM
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

witty-crayon-22786

03/21/2020, 11:14 PM
sounds good
💯 1