Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

wonder if we should have a standardized `@classmethod` on `Target` subclasses to generate the initial `Payload` object given kwargs - which would be called by `Target.__init__()` rather than taking `payload` as a kwarg. then the `Payload` fields would be the fields we could inherently externalize - so we’d have `SourcesField` and e.g. `DependenciesField` etc.

then beyond the `Payload` the `Target.__init__()` in subclasses could do all of the other stuff that happens there today like setting private attrs and whatnot

`Target.create_sources_field` seems like it should clearly be a `@classmethod` since it carries this warning: `Note that this method is called before the call to Target.__init__ so don't expect fields to be populated!`

that could be a neat inversion, yea. relates to what i had begun thinking with <https://github.com/pantsbuild/pants/issues/3560> last time i looked at it

<https://github.com/pantsbuild/pants/issues/3560#issuecomment-275761545>

Grabbing <https://github.com/pantsbuild/pants/issues/4446> as my next 1.3.0 since it’s related to the things I’m looking at now.

maybe it could be `def payload_factory(cls, kwargs, fields=ALL)` and then given specific fields it would compute and return partial `Payload` objects which would open way to more granular field product requests?

I think that would also clean up some awkward patterns in v1 target class declarations too

it’d be cool if we could inject engine-held complete `Payload`‘s into `Target` subclasses `__init__` methods too so we don’t double compute

so, i'm not sure that Payload itself is a great concept, but PayloadFields are potentially.

it might be nice to avoid having to implement N payload field factory methods

unless we think there will only be a few critical ones?

the only reason i'd call it a "factory" would be if it contained imperative logic

like, one classmethod that emits a `SourcesField` vs another that emits a `DependenciesField`

I think you could represent most payload stuff declaratively

one thing might be: make the `@classmethod def fields` required, and without any parameters (and thus probably no logic)

and then make the "factory" or imperative aspect optional

...hah, nick said what i was thinking while i was typing.

If we had a declarative repr, then we could generate rules to inject into the rulegraph for the payload elements