aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Wickman <wick...@apache.org>
Subject Re: Should we continue to maintain fine-grained python BUILD targets?
Date Tue, 06 Jan 2015 22:43:29 GMT
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 <wfarner@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message