Add support for merging products produced by multiple promises #2526
Comments
|
Post #3377, this amounts to |
stuhood
added a commit
that referenced
this issue
Feb 17, 2016
This review deals with the "partially specified configuration" issue described on [#2869](#2869) and [#2525](#2525). It addresses (what I think is) the last issue blocking integration of the new engine. I will begin working on integration while this is under review. - Reintroduced usage of `PartiallyConsumedInputsError`, which allows for useful errors in cases where only some of a task's required (literal*) inputs were specified. See [r3245](https://rbcommons.com/s/twitter/r/3245/) for the original implementation of this check. - Example error received when a target has ThriftSources, but none of the configuration types that might be necessary to consume it: ``` pants.engine.exp.scheduler.PartiallyConsumedInputsError: Some products were partially specified for `src/thrift/codegen/selector:selector`: To consume `thrift` and produce `java`: gen_apache_thrift also needed (`apache_thrift_java_configuration`) gen_scrooge_thrift also needed (`scrooge_java_configuration`) To consume `thrift` and produce `scala`: gen_scrooge_thrift also needed (`scrooge_scala_configuration`) ``` - Add the `Noop` state to differentiate missing inputs from actual user-relevant failures. This allows all `Throw` nodes to be considered actual errors, so they are now rendered in the visualizer. Many errors that used to be synchronous now fail via Throw instead. See the attached "multiple sources of product" graph, which is much more usable than it would have been otherwise. - Allow inputs to be marked 'optional' for tasks via `SelectOptional`. Optional inputs will be `None` if they cannot be produced. - Associate all "goals" with a single product type, which makes a "goal" just an alias for a particular product. In cases where a goal represents multiple products, a synthetic product type extending `Goal` is used, with a task to validate that at least one of the products was produced. See the example of `GenGoal` which, depends on all of the Sources classes. - Reintroduce the failure when multiple tasks are able to produce a product for a subject (at least until [#2526](#2526) is implemented and we can merge them instead). * A 'literal' input here is considered to be anything recorded in the `SymbolTable` that is used to parse BUILD files. Since users can only actually specify literal values, we only raise errors for task failures in cases where a user: 1. might have put a literal value in a BUILD file, and 2. might be able to add additional literal values to allow a task to produce a requested product Testing Done: Fixed some tests that were marked xfail, and added a few more. https://travis-ci.org/pantsbuild/pants/builds/108637875 Bugs closed: 2869, 2912 Reviewed at https://rbcommons.com/s/twitter/r/3448/
|
I'm going to resolve in favor of #4535, which sketches out a realistic design for this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In order to support the example added by #2484, the engine will need support for merging products in some cases*.
Determining which products are safe to merge is covered by #2525.
The text was updated successfully, but these errors were encountered: