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
>> With using puppet and i intend to start a fork of vmbuilder to unify all
>> these projects in making images of virtual machines. Since vmbuilder is
>> basically ubuntu only now with centos support floating about in github.
>> Boxgrinder is kind of gross to get setup because of ruby.

FYI, I'm most of the way through a proof-of-concept for a tool
(coincidentally - in Python) that supports the building of a certain VM in
multiple backends, with Boxgrinder and Kickstarter support right now, and
hopefully VMBuilder support without much difficulty. As I don't know much
about VMBuilder yet, would you perhaps want to collaborate on this? I'll be
posting a patch to BIGTOP-871 in a few days (the one that's there is
Boxgrinder-specific - I'm working on a much more modular approach).

Regarding the choice of language, I think I agree with both arguments so
far - might I suggest Jython? </onlyHalfJoking>. Groovy is already heavily
used within Bigtop, but it also requires more than just the JVM. I
personally prefer Python for these purposes - but I wouldn't strongly
object to anything - as long as it was a well-accepted standard so we don't
end up with a different language for every little project somebody
undertakes.

On Thu, Mar 28, 2013 at 8:04 AM, Philip Herron
<[EMAIL PROTECTED]>wrote:

> On 27/03/13 15:37, Roman Shaposhnik wrote:
> > Hi Philip,
> >
> > first of all thanks a bunch for considering to lead with the code --
> that's
> > the best way to make progress. I have just started to look at your code
> > and haven finished reviewing it yet (in fact, I'd rather have somebody
> > on this list who appreciates Python doing that -- Steve?) but let me
> > quickly answer some of the points you've raised.
> >
> > My only metapoint here would be that since we're stuck with Java
> > because 90% of Bigtop components are implemented in it
> > and we've also chosen it as a platform for iTest -- any solution
> > that leverages Java tooling (Gradle, Groovy, etc) would get
> > more of my personal enthusiastic embrace than a solution
> > that introduces yet another platform to care about (Python,
> > Ruby, etc.).
>
> I understand your point here but i think python suits this project much
> better than a jvm based language because of the dependency of the jvm to
> me isn't scripting. Python gets by this because its much simpler and
> installed even in minimal environments of linux by default. And suits
> this work very well.
>
> At the moment we care about:
>
> Make/Bash/java/puppet/ruby/kickstart/ From all i can see at the moment,
> With python we can unify all of bigtop's functionality properly.
>
> With using puppet and i intend to start a fork of vmbuilder to unify all
> these projects in making images of virtual machines. Since vmbuilder is
> basically ubuntu only now with centos support floating about in github.
> Boxgrinder is kind of gross to get setup because of ruby.
>
> >
> > On Wed, Mar 27, 2013 at 6:54 AM, Philip Herron
> > <[EMAIL PROTECTED]> wrote:
> >> 1 - Bigtop's logic is handled within gnu/make and bash which is
> >> detrimental for the long term maintainability of bigtop as it may turn
> >> away developers.
> >>
> >> 2 - Make is hard to debug in this way esp for the need of \ for line
> run-on.
> >
> > Could you, please, elaborate on what exact problem you were faced
> > with when you decided that Python is a better option than Make?
> > We all have preferences (for example mine is, honestly, make over
> > python) but of course if the current tooling is inadequate in some
> > respect it needs to be updated.
>
> Yeah I understand you like make i don't mind it but it doesn't have any
> real long term potential. Because i tend to think most people from java
> backgrounds will have next to no background with make. I come from a gcc
> developer/commiter background so i am used to it. But even then this
> isn't a valid use of make in my opinion and i am sure gnu/make
> developers would agree this isn't how make should be used.