Support a non-inlined lazy resolve mode in Graph.
Review Request #2944 - Created Oct. 8, 2015 and submitted
|2283, 2308, 2342|
|2945, 2947, 2952, 2950|
|benjyw, ity, kwlzn, patricklaw, stuhood|
The fundamental restructuring is moving from Addressed values to a class-housed schema of addressable fields powered by a @property-like `AddressableDescriptor` with write-once semantics and that can contain `Resolvable` values in addition to opaque address strings and concrete values. This move reduces the memory requirements of parsing objects, they are now just an object with a single `_kwargs` dict of unadorned string address values in the addressable field case. With the `Resolvable` type plumbed into addressable schemas, both the json encoder and the Graph gain the ability to materialize or serialize shallow or inlined graphs bringing the testable space of the noun side of the experiment up to 3 parsers x 2 graph modes. src/python/pants/base/BUILD | 4 - src/python/pants/base/address.py | 2 - src/python/pants/engine/exp/BUILD | 1 + src/python/pants/engine/exp/addressable.py | 342 ++++++++++++++++++++++++++++++++++++-------------- src/python/pants/engine/exp/configuration.py | 47 ++++--- src/python/pants/engine/exp/graph.py | 117 +++++++++++------ src/python/pants/engine/exp/objects.py | 19 ++- src/python/pants/engine/exp/parsers.py | 44 ++++--- src/python/pants/engine/exp/targets.py | 40 +++--- tests/python/pants_test/engine/exp/BUILD | 1 + tests/python/pants_test/engine/exp/test_addressable.py | 303 +++++++++++++++++++++++++++++++++++++------- tests/python/pants_test/engine/exp/test_graph.py | 96 +++++++++++++- tests/python/pants_test/engine/exp/test_parsers.py | 70 +++++++++-- 13 files changed, 835 insertions(+), 251 deletions(-)
CI went green here: https://travis-ci.org/pantsbuild/pants/builds/84361801
The single-file target style came up in https://rbcommons.com/s/twitter/r/2914/ so I attached the graph I keep generating (in my head looking at the BUILD) to sanity check structure is right. In particular not that the only component that cares about resolution of objects is the graph, the mapper/parser system only deals in thin Serializable objects as the dep edges demonstrate.
Hey John, I'm finally back from my travels (well, at least as far as NY), so I can start catching up on all this new code.
Maybe it's best if you push this (and anything else outstanding) TBR, as it's all experimental anyway. Then when it's quiesecent (at least the build graph part) I will deep-dive into it all as one chunk, and we can create a faux RB for it.
Does that make sense?