I'm not hugely opposed, but I truly do think this sort of thing represents a plugin model scalability problem. Each generic target type that comes up is going to need a mixin added to the core in this model. Isn't `has_sources('*.thrift')` enough to replace the existing predicate at use-sites? Presumably any task that needs to act on thrift is justified in asserting / repeating - "the targets I care about must own thrift files".
Get rid of the 'codegen' target label and associated checks.
Review Request #4316 — Created Oct. 15, 2016 and discarded
|jsirois, kwlzn, zundel|
Instead, use type checks on a new CodegenLibraryMixin, created
to tag codegen libraries.
Note that this mixin lives in src/python/pants/build_graph,
as this is a good central point for it. Putting it in, say,
the codegen backend, would require other backends to depend on
codegen, just to import the mixin. Dependencies between backends
is something we'd like to avoid as much as possible.
So the pants core now recognizes "codegen" as a concept, even
though it doesn't provide any codegen implementations.
That seems fine to me - in any case, the "codegen" backend should
probably be split up anyway, so there's no other natural home
This is part of an effort to get rid of the long-deprecated
target labelling system, and its associated is_* methods.
Closed in favor of the simpler https://rbcommons.com/s/twitter/r/4318/.
CI passes: https://travis-ci.org/pantsbuild/pants/builds/167968323
It looks like https://rbcommons.com/s/twitter/r/4318 is less disruptive and I'm not sure that the new mixins specified here add any value at this point.
In the future there might be some advantage to labeling these separately, so it might be worth going the more complex route, but I don't know what that future need might be.