4) Enforcing sensible software hygiene. The pants project itself for the longest time had a single root rglobs python_library target. I spent a few days splitting up that project into fine-grained targets and it uncovered a number of cyclical dependencies and abstraction leaks that simply would've been impossible to make with better target encapsulation. If everyone is an expert in the project, BUILD management can be tedious overhead, but for novice contributors, fine-grained BUILDs can be an effective linting mechanism to prevent poor code structure and advise the design process.
This is entirely a trade-off. I'm not sure you could get the same protections with coarser granularity than what we have now. That being said, if we move forward with simplification, I'd propose we go all-in and remove pants entirely in favor of setup.py and tox. ~brian On Tue, Jan 6, 2015 at 2:03 PM, Bill Farner <wfar...@apache.org> wrote: > We currently have ~111 BUILD targets serving our python code, and ~106 test > targets: > > $ find . -name BUILD | xargs grep python_library | wc -l > 111 > > $ find . -name BUILD | xargs grep python_test | wc -l > 106 > > This presents a non-trivial maintenance burden, and i'm not convinced the > benefits are worth it. Now that we have a good IDE story, refactors are > painless in the source code, but painful when you need to hand-edit all > affected BUILD targets. > > I can think of several motivations for using fine-grained targets > 1. Running specific unit tests with pants > 2. Limiting the sources included in a binary > 3. Carving out libraries to be published > > I'm not convinced these benefits outweigh the maintenance burden of these > files. I propose we reduce our BUILD targets to ~equal to the number of > binaries we produce, possibly with a few for libraries shared between > components. > > Does anyone else have opinions on this? Is there something i'm > overlooking? > > > -=Bill >
