Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Bigtop >> mail # dev >> Python Fork

Copy link to this message
Re: Python Fork
On 03/29/2013 01:42 AM, Bruno Mah� wrote:
> On 03/27/2013 06:54 AM, Philip Herron wrote:
>> Hey all
>> I am new to bigtop and I would like to get feedback on this initial
>> concept from the community on this.
>> I have created a fork of bigtop in my own time at:
>> http://git.buildy.org/?p=bigtop.git;a=shortlog;h=refs/heads/python-fork
>>    $ git clone git://buildy.org/bigtop.git
>>    $ git checkout --track -b python-fork origin/python-fork
>> This fork of bigtop's toplevel Make/Bash logic within python has a
>> number of benefits to the whole community of bigtop for its most
>> important function namely packaging.
>> --Phil
> Hi Philip,
> I like the direction this is going. But why not using scons? It's in
> python, it's available everywhere and already has support for parallel
> builds.
> Thanks,
> Bruno

Sorry, I hit the send button a little bit too early.

 >> 3 - This new directory structure feels more maintainable already with
 >> bigtop's main function to generate packages for hadoop stack's on
 >> different platforms. Other functions which (don't seem) to be actively
 >> maintained like bigtop-deploy and the test framework with regards to
 >> their documentation.

bigtop-deploy and the test framework should not be deprecated. They
receive less attention, but that's no reason to

* I see you import the logging module, but you don't use it. You even
have your own methods for error/fatal/info.
* nitpick: getopt works, but python has some much nicer argument parsers
modules :)
* Instead of having a bunch of if RPM elif DEB, I would move these
implementation details to their own class.
* exit code of subprocess calls should be check. Their output should
also be displayed and even logged (maybe)