{"push_id":951527008,"size":5,"distinct_size":1,"ref":"refs/heads/tabishev/build_file_renaming","head":"b9e8e95b9f3cdc67be7f1bfc64a34604b3264df9","before":"c2364dc79108a397f0d723d385fc4ab0bc972646","commits":[{"sha":"6ea125a5a8e3c985e5b219e78de0e32d49a274b6","author":{"email":"5496d4fd32b46dcb22e495b96a73063ce8ea956b@gmail.com","name":"Garrett Malmquist"},"message":"A managed_jar_libraries factory to reduce 3rdparty duplication.\n\nIn an effort to reduce duplication of 3rdparty configuration, I\nintroduced a `managed_jar_libraries` factory. It syntactically\nappears very similarly to a managed_jar_dependencies target, but it\nalso generates jar_library targets for each jar() it contains. It\ndoes not generate anything for artifacts which are specified\nindirectly with a jar_library spec (rather than a directly embedded\njar() object), because that would be redundant (and could even\nlikely conflict with existing definitions in the BUILD file).\n\nTesting Done:\nAdded integration tests to test_jar_dependency_management_integration.py.\n\nCI went green here: https://travis-ci.org/pantsbuild/pants/builds/104732867\nCI went green here: https://travis-ci.org/pantsbuild/pants/builds/104770329\nCI went green here: https://travis-ci.org/pantsbuild/pants/builds/104919830\n\nBugs closed: 2834\n\nReviewed at https://rbcommons.com/s/twitter/r/3372/","distinct":false,"url":"https://api.github.com/repos/ttim/pants/commits/6ea125a5a8e3c985e5b219e78de0e32d49a274b6"},{"sha":"39223aba9c0b2494f8a0cdef753fdbf19956e11c","author":{"email":"5496d4fd32b46dcb22e495b96a73063ce8ea956b@gmail.com","name":"Garrett Malmquist"},"message":"Multiple dependency_managements with multiple ivy resolves.\n\nThis is the second pass of implementing dependency management in\npants.\n\nThe first pass was reviewed here:\n\n    https://rbcommons.com/s/twitter/r/3336/\n\nThe design document is available here:\n\n    https://docs.google.com/document/d/1AM_0e1Az_NHtR150Zsuyaa6u7InzBQGLq8MrUT57Od8/edit#\n\nThis change allows managed_jar_dependencies targets to be chained\ntogether; the set of pinned artifact is the union of all jar\ncoordinates specified by the transitive closure of the target\nspecified in a jar_library's managed_dependencies field.\n\nWhen there are conflicts between dependencies in the transitive\nclosure, the default behavior is to raise an error. Optionally,\nif using --no-jar-dependency-management-require-disjoint-sets,\nthe most direct version (the first version encountered in a BFS)\nwill be used, and a warning will be logged.\n\nThe change to make ivy do multiple resolves is fairly simple; see\nivy_task_mixin.py's resolve() method.\n\nTesting Done:\nAdded integration tests for running multiple resolves, and for the new managed_jar_libraries factory.\n\nAdded unit tests for transitive artifact set calculation.\n\nCI went green here: https://travis-ci.org/pantsbuild/pants/builds/104711840\nCI went green here: https://travis-ci.org/pantsbuild/pants/builds/104947421\nCI went green here: https://travis-ci.org/pantsbuild/pants/builds/104985770\n\nBugs closed: 2830\n\nReviewed at https://rbcommons.com/s/twitter/r/3367/","distinct":false,"url":"https://api.github.com/repos/ttim/pants/commits/39223aba9c0b2494f8a0cdef753fdbf19956e11c"},{"sha":"ef3f8d221a5afefb01d655448ce7e3f537399810","author":{"email":"bb1f132dcb86bfc59bf4a043a3139a9ac7c0b658@gmail.com","name":"Stu Hood"},"message":"[engine] Eager execution and fully declarative dependencies\n\nThis is a refactoring of the experimental engine to:\n1. mix planning with execution\n2. declare all dependencies of tasks ahead of time\n\n----\n\n- Planners are now `(\"output product type\", \"input product selection clause\", \"task function\")` triples. The selection clause is an ANDed series of `Selector` instances which declare the dependencies of the function. See the bottom of `planners.py` for the updated examples.\n- Don't create an execution graph before beginning to execute it: instead, grow a ProductGraph _while_ executing it.\n    - While being more difficult to experiment with without causing sideeffects, this model allows for significant power: for one thing, it allows dependency lists to be created/determined by task code. This opens the door to tasks that do dependency inference by parsing input files (up to and including implementing BUILD file parsing inside the engine!).\n- A ProductGraph is made up of nodes which each uniquely identify a computation.\n    - The primary reason for the complexity of the `Node.step` API is that all of the dependencies of some nodes cannot be computed until some of their dependencies become available. In particular a `SelectDependencies` Node begins by requesting the product it needs to determine the dependency list; once that is available, it requests those dependencies as well.\n- Rename `config_selectors` to `variants`, give them names, and make them transitive through the graph (also possible to specify in an address on the CLI)\n    - One of the goals of this change is to allow for using the same system to solve three problems:\n        1. thrift cross-compilation (as John already demonstrated)\n        2. scala/javascript cross compilation (easy: left to the imagination)\n        3. frozen ivy resolutions (by configuring a variant on binary targets that travels all the way down to their 3rdparty dependencies)\n\n----\n\nThe visualizer tool continues to work, but now requires that the graph be executed before it can be displayed. Attached is the graph for:\n\n    ./pants run src/python/pants/engine/exp/examples:viz -- \\\n      tests/python/pants_test/engine/exp/examples/scheduler_inputs \\\n      compile \\\n      src/java/codegen/selector:selected\n\nTesting Done:\nhttps://travis-ci.org/pantsbuild/pants/builds/105050996\n\nBugs closed: 2782, 2825\n\nReviewed at https://rbcommons.com/s/twitter/r/3339/","distinct":false,"url":"https://api.github.com/repos/ttim/pants/commits/ef3f8d221a5afefb01d655448ce7e3f537399810"},{"sha":"c88c53784a10d33065adb895724d76afae8289b9","author":{"email":"5c03386320a2b453ce4a1ee67bf5a90e435fee84@gmail.com","name":"Timur Abishev"},"message":"BuildFile refactoring: add more constraints to BuildFile constructor\n\n`BuildFile.__init__` used to try to find any BUILD file in a passed directory and use it.  Now it requires that an explicit (existing) BUILD file is passed in order to succeed.\n\nPrevious behaviour doesn't work well with future `pants_build_ignore` option because this option can forbid some BUILD files extensions.\n\nThis RB adds the constraint to BuildFile constructor: input path should be a path to an existing BUILD file only.\n\nTesting Done:\nhttps://travis-ci.org/ttim/pants/builds/105066148\n\nBugs closed: 2838\n\nReviewed at https://rbcommons.com/s/twitter/r/3376/","distinct":false,"url":"https://api.github.com/repos/ttim/pants/commits/c88c53784a10d33065adb895724d76afae8289b9"},{"sha":"b9e8e95b9f3cdc67be7f1bfc64a34604b3264df9","author":{"email":"5c03386320a2b453ce4a1ee67bf5a90e435fee84@gmail.com","name":"Timur Abishev"},"message":"remove _project_tree_ from name of the methods","distinct":true,"url":"https://api.github.com/repos/ttim/pants/commits/b9e8e95b9f3cdc67be7f1bfc64a34604b3264df9"}]}