I agree, pants is heavily biased towards 1 directory, 1 package, 1 build target. If we're going to stay with pants I'd prefer to stick with that convention. If we're going to simplify the build structure I think we should take that as impetus to move away from pants entirely.
On Tue, Jan 6, 2015 at 2:43 PM, Brian Wickman <wick...@apache.org> wrote: > 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 > > >
