aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Smith <yasumo...@gmail.com>
Subject Re: Should we continue to maintain fine-grained python BUILD targets?
Date Wed, 07 Jan 2015 19:05:49 GMT
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 <jcohen@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 <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
View raw message