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
Philip Herron 2013-03-27, 15:36
On 27/03/13 15:26, Sean Mackrory wrote:
> Overall I think I like this - thanks for doing all the work for this fork!
> It would indeed be nice to have a more sophisticated language for this.
> Some thoughts:
>    - If we do make a move to Python, we ought to make sure it works on
>    Python 2.4 initially, as we're still doing releases that we intend to
>    support on RHEL 5. I haven't tried the fork on RHEL 5 yet, so I'm just
>    mentioning it - don't know if there actually are any small issues.
Yeah i could try and and test against this tomorrow there are a few
things i'd have to look out for since i think i used with in there etc
which is python >= 2.5 but its not nessecary etc.

>    - do-component-build and install_.sh: I think those should remain as
>    bash scripts. Did you have any intention to the contrary?
Yeah this is true we should deffo keep this this is a nice way to have
the builds be the same on both deb/rpm.

>    - Some of the do-component-build scripts source 'bigtop.bom' to get
>    component versions in the environment. We need to make sure we still
>    generate that in a shell-friendly form.
Ah this is an interesting problem but if we were to output environment
variables for the child-processes of subprocess.call this might work.
Other outputting an bash friendly bom like before. There is definitely a
way to work around this. Though i am not sure what way yet :P.

>    - Don't know how I feel about "demoting" the tests. I've been under the
>    impression that they were still maintained (though I admit I haven't paid
>    much attention to them myself), but if they're not well maintained, I think
>    I'd rather we make a plan to give them more attention than accept their
>    unmaintained-ness.
Yeah it might be my ignorance but I�ve never got that side of bigtop to
work yet. And not sure how it works I think I put bigtop-deploy and test
under contrib mostly because it undocumented and not really that
important for the main functions of bigtop to package software.

> Definitely a big decision to make and there's a lot of discussion and work
> to go - but put me down for a +1.

And i plan to make the code a lot nicer i did this in an afternoon and i
know its probably not great yet but there is a lot of room for more
interesting use of bigtop for long-term.

Thanks for your +1. I think with some work i could try and bring it up
to scratch with trunk bigtop and see how the community finds it i think
its a necessary step in the long run even though the gcc hacker in my
likes makefiles :).