Fix spurious Products requirements.
Review Request #1662 — Created Jan. 25, 2015 and submitted — Latest diff uploaded
|benjyw, ity, zundel|
The trio of require, isrequired and get - the original members of
products - are tricky and they have invalid semantics in the
This change fixes things such that a `.get(<typename>)` does not have
the effect of causing a subsequent `.isrequired(<typename>)` check to be
Going forward, the idea of requiring a product for a subset of targets -
the role of the `.require` predicate today - will be subsumed by the
src/python/pants/goal/products.py | 20 ++++++++----
tests/python/pants_test/BUILD | 1 +
tests/python/pants_test/goal/BUILD | 10 ++++++
tests/python/pants_test/goal/__init__.py | 0
tests/python/pants_test/goal/test_products.py | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 113 insertions(+), 7 deletions(-)
I ran into this in the ProtobufGen imports handling in a pretty subtle
way when working on an engine change.
In (not so) short, ApacheThriftGen runs 1st, and in the post-processing
phase in the CodeGen superclass where synthetic targets are linked, a
products.get('python')ends up making 'python' products
required. This in turn influences the subsequent ProtobufGen (another
CodeGen sublclass) run, incorrectly telling it that 'python' protobuf
gen products are required.
CI went green here: