aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Cohen <jco...@twopensource.com>
Subject Re: Should we continue to maintain fine-grained python BUILD targets?
Date Wed, 07 Jan 2015 18:14:58 GMT
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 <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
> >
>

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