Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


+
Philip Herron 2013-03-27, 13:54
+
Sean Mackrory 2013-03-27, 15:26
+
Philip Herron 2013-03-27, 15:36
+
Roman Shaposhnik 2013-03-27, 15:37
+
Philip Herron 2013-03-28, 15:04
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.
+
Roman Shaposhnik 2013-03-28, 16:33
+
Konstantin Boudnik 2013-03-28, 19:18
+
Roman Shaposhnik 2013-03-28, 16:29
+
Bruno Mahé 2013-03-29, 08:59
+
Bruno Mahé 2013-03-29, 08:42
+
Bruno Mahé 2013-03-29, 09:10
+
Philip Herron 2013-03-27, 15:12
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB