I found it ~annoying to test the client in a few cases where multiple targets were in one large test target- I’m in favor of fine-grained BUILD targets despite the (what I consider slight) additional overhead.
> On Jan 7, 2015, at 10:14 AM, Joshua Cohen <jco...@twopensource.com> wrote: > > 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 >>> >>
