aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zameer Manji <zma...@twopensource.com>
Subject Re: Should we continue to maintain fine-grained python BUILD targets?
Date Tue, 06 Jan 2015 23:54:54 GMT
If we decide to simplify the targets then I'm also in favor of going all in
and removing pants in favour of setup.py and tox.

On Tue, Jan 6, 2015 at 2:43 PM, Brian Wickman <wickman@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 <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
> >
>



-- 
Zameer Manji

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