[VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Eric Yang-2
-1, +1, -1

Python has fairly inconsistent support across all major OS vendors.  It is
hard to get it right unless the scripts are all designed to make use of
Python 2.4.  However, Python 2.4 doesn't have necessary OS features to make
Python useful in runtime or build environment unless you write a lot of
custom modules.  Which defeats the purpose to use python as intermediate
layer to do OS dependent work.  Jruby may be a better choice.

regards,
Eric

On Sat, Dec 1, 2012 at 12:28 PM, Joep Rottinghuis <[hidden email]>wrote:

> 0, 0, -1 (non-binding)
>
> Joep
>
> On Nov 24, 2012, at 12:13 PM, Matt Foley <[hidden email]> wrote:
>
> > For discussion, please see previous thread "[PROPOSAL] introduce Python
> as
> > build-time and run-time dependency for Hadoop and throughout Hadoop
> stack".
> >
> > This vote consists of three separate items:
> >
> > 1. Contributors shall be allowed to use Python as a platform-independent
> > scripting language for build-time tasks, and add Python as a build-time
> > dependency.
> > Please vote +1, 0, -1.
> >
> > 2. Contributors shall be encouraged to use Maven tasks in combination
> with
> > either plug-ins or Groovy scripts to do cross-platform build-time tasks,
> > even under ant in Hadoop-1.
> > Please vote +1, 0, -1.
> >
> > 3. Contributors shall be allowed to use Python as a platform-independent
> > scripting language for run-time tasks, and add Python as a run-time
> > dependency.
> > Please vote +1, 0, -1.
> >
> > Note that voting -1 on #1 and +1 on #2 essentially REQUIRES contributors
> to
> > use Maven plug-ins or Groovy as the only means of cross-platform
> build-time
> > tasks, or to simply continue using platform-dependent scripts as is being
> > done today.
> >
> > Vote closes at 12:30pm PST on Saturday 1 December.
> > ---------
> > Personally, my vote is +1, +1, +1.
> > I think #2 is preferable to #1, but still has many unknowns in it, and
> > until those are worked out I don't want to delay moving to cross-platform
> > scripts for build-time tasks.
> >
> > Best regards,
> > --Matt
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Arun Murthy
In reply to this post by Matt Foley-2

On Nov 29, 2012, at 6:26 PM, Matt Foley wrote:

> Hello again.  Crossed in the mail.
>
> * What kind of tasks you envision Python scripts will enable that are
>> not possible today?
>
>
> The point isn't to open brave new worlds.  The point is to avoid the
> nightmare of having to maintain multiple "parallel" scripts doing the SAME
> THING in multiple scripting languages.  

+1, +1, +1

Couldn't agree more, I don't want to be in the business of having the same logic in multiple platform-specific scripts - doesn't make any sense.

Arun

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Tom White-2
In reply to this post by Matt Foley-2
+1, +1, -1

Tom

On Sat, Nov 24, 2012 at 8:13 PM, Matt Foley <[hidden email]> wrote:

> For discussion, please see previous thread "[PROPOSAL] introduce Python as
> build-time and run-time dependency for Hadoop and throughout Hadoop stack".
>
> This vote consists of three separate items:
>
> 1. Contributors shall be allowed to use Python as a platform-independent
> scripting language for build-time tasks, and add Python as a build-time
> dependency.
> Please vote +1, 0, -1.
>
> 2. Contributors shall be encouraged to use Maven tasks in combination with
> either plug-ins or Groovy scripts to do cross-platform build-time tasks,
> even under ant in Hadoop-1.
> Please vote +1, 0, -1.
>
> 3. Contributors shall be allowed to use Python as a platform-independent
> scripting language for run-time tasks, and add Python as a run-time
> dependency.
> Please vote +1, 0, -1.
>
> Note that voting -1 on #1 and +1 on #2 essentially REQUIRES contributors to
> use Maven plug-ins or Groovy as the only means of cross-platform build-time
> tasks, or to simply continue using platform-dependent scripts as is being
> done today.
>
> Vote closes at 12:30pm PST on Saturday 1 December.
> ---------
> Personally, my vote is +1, +1, +1.
> I think #2 is preferable to #1, but still has many unknowns in it, and
> until those are worked out I don't want to delay moving to cross-platform
> scripts for build-time tasks.
>
> Best regards,
> --Matt
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Doug Cutting
In reply to this post by Matt Foley-2
On Sat, Nov 24, 2012 at 12:13 PM, Matt Foley <[hidden email]> wrote:
> Vote closes at 12:30pm PST on Saturday 1 December.

It's not clear to me what kind of a vote this is.  It seems closest to
a code change vote, since it implies code changes, although without a
specific patch yet proposed.  As such it would follow lazy consensus
rules.  Or is it merely intended as a straw poll, to gauge community
opinion?

Doug
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Matt Foley
It is intended to be a "technical discussion", in the sense of the bylaws
statement (in section "Roles and Responsibilities: Committers"), "Committers
may cast binding votes on any technical discussion regarding any
subproject."  I therefore intended it to be a majority vote of Committers.

Interestingly, this need to discuss tooling and other issues that go beyond
a simple "code change" is not addressed in the "Decision Making: Actions"
section of the bylaws.  That need seems to have been overlooked in the
current rev of that section.  But I do not agree that such issues are "code
changes"; it relates to the tools we depend on to make code changes, which
is clearly qualitatively different.

--Matt


On Mon, Dec 3, 2012 at 10:37 AM, Doug Cutting <[hidden email]> wrote:

> On Sat, Nov 24, 2012 at 12:13 PM, Matt Foley <[hidden email]> wrote:
> > Vote closes at 12:30pm PST on Saturday 1 December.
>
> It's not clear to me what kind of a vote this is.  It seems closest to
> a code change vote, since it implies code changes, although without a
> specific patch yet proposed.  As such it would follow lazy consensus
> rules.  Or is it merely intended as a straw poll, to gauge community
> opinion?
>
> Doug
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Doug Cutting
On Mon, Dec 3, 2012 at 11:21 AM, Matt Foley <[hidden email]> wrote:
> It is intended to be a "technical discussion", in the sense of the bylaws
> statement (in section "Roles and Responsibilities: Committers"), "Committers
> may cast binding votes on any technical discussion regarding any
> subproject."  I therefore intended it to be a majority vote of Committers.

I'm not sure how you conclude that technical discussions are resolved
with majority votes.

http://www.apache.org/foundation/voting.html

> Interestingly, this need to discuss tooling and other issues that go beyond
> a simple "code change" is not addressed in the "Decision Making: Actions"
> section of the bylaws.  That need seems to have been overlooked in the
> current rev of that section.  But I do not agree that such issues are "code
> changes"; it relates to the tools we depend on to make code changes, which
> is clearly qualitatively different.

I don't see a striking difference between this and a proposed code
change.  How is a -1 here fundamentally different than a veto on a
patch submitted to HADOOP-9082?

Doug
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Matt Foley
Hi Doug,
The apache voting process contradicts the Hadoop bylaws:
http://www.apache.org/foundation/voting.html says that only PMC members can
make binding votes on code modification issues, but
http://hadoop.apache.org/bylaws.html says that Committers can make binding
votes on them.  Does that mean the Hadoop bylaws have to change?

Thanks,
--Matt


On Mon, Dec 3, 2012 at 11:37 AM, Doug Cutting <[hidden email]> wrote:

> On Mon, Dec 3, 2012 at 11:21 AM, Matt Foley <[hidden email]>
> wrote:
> > It is intended to be a "technical discussion", in the sense of the bylaws
> > statement (in section "Roles and Responsibilities: Committers"),
> "Committers
> > may cast binding votes on any technical discussion regarding any
> > subproject."  I therefore intended it to be a majority vote of
> Committers.
>
> I'm not sure how you conclude that technical discussions are resolved
> with majority votes.
>
> http://www.apache.org/foundation/voting.html
>
> > Interestingly, this need to discuss tooling and other issues that go
> beyond
> > a simple "code change" is not addressed in the "Decision Making: Actions"
> > section of the bylaws.  That need seems to have been overlooked in the
> > current rev of that section.  But I do not agree that such issues are
> "code
> > changes"; it relates to the tools we depend on to make code changes,
> which
> > is clearly qualitatively different.
>
> I don't see a striking difference between this and a proposed code
> change.  How is a -1 here fundamentally different than a veto on a
> patch submitted to HADOOP-9082?
>
> Doug
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Doug Cutting
On Mon, Dec 3, 2012 at 2:08 PM, Matt Foley <[hidden email]> wrote:
> The apache voting process contradicts the Hadoop bylaws:
> http://www.apache.org/foundation/voting.html says that only PMC members can
> make binding votes on code modification issues, but
> http://hadoop.apache.org/bylaws.html says that Committers can make binding
> votes on them.  Does that mean the Hadoop bylaws have to change?

This may be a little atypical but I don't see any harm.  The Hadoop
PMC is willing to respect the veto of any committer as binding.  I'd
worry more if we tried to reduce vetoes to a subset of the PMC than
extend it to a superset.

Do you think this is problematic?

Doug
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Matt Foley-2
No, but it speaks to whether the Hadoop bylaws can extend the Apache voting
procedures and draw finer distinctions.  For example, the Apache voting
procedures only identify 3 types of votable issue, while the Hadoop bylaws
identify 9 types of votable issues.

If we were forced to fit "development tools" into one of the three
categories cited by the Apache voting procedures, it would be fitting a
square peg in a round hole.  Since we can instead look at the 9 categories
provided by the Hadoop bylaws, we can acknowledge that "development tools"
was an overlooked category.  But in my opinion it certainly doesn't fit
into the "code change" category.  Tooling is a meta-issue regarding HOW we
do what needs to be done.  In this case, whether we allow a
platform-independent solution, or force contributors to maintain parallel
scripts in multiple platform-specific languages for no reason.

--Matt


On Mon, Dec 3, 2012 at 3:57 PM, Doug Cutting <[hidden email]> wrote:

> On Mon, Dec 3, 2012 at 2:08 PM, Matt Foley <[hidden email]> wrote:
> > The apache voting process contradicts the Hadoop bylaws:
> > http://www.apache.org/foundation/voting.html says that only PMC members
> can
> > make binding votes on code modification issues, but
> > http://hadoop.apache.org/bylaws.html says that Committers can make
> binding
> > votes on them.  Does that mean the Hadoop bylaws have to change?
>
> This may be a little atypical but I don't see any harm.  The Hadoop
> PMC is willing to respect the veto of any committer as binding.  I'd
> worry more if we tried to reduce vetoes to a subset of the PMC than
> extend it to a superset.
>
> Do you think this is problematic?
>
> Doug
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Doug Cutting
Hadoop's bylaws do draw finer distinctions than the Apache voting
guidelines document, but we follow the same general principles that
are described there.

As I understand it, the rationale for using consensus for code is that
everyone needs to agree on everything in the codebase or we've
disenfranchised some.  We share a single code repository and we need
to all agree on what goes into it.  A release does not require
majority since if someone doesn't agree on the timing of a release
they can choose to make another at a different time, but every change
that goes into each release requires consensus.  We also require
consensus for committers and PMC member votes so that we have a group
that's coherent and is able to reach consensus on code changes.

Re-writing bash scripts in Python is neither a release nor other
procedural issue.  It involves changes to the software we maintain and
seems to fall clearly into the "code change" category.

If you disagree then perhaps you'd like to propose a change to the
bylaws so that scripts have different rules than other kinds of
software, but I don't yet see the rationale for such a change.

Doug

On Mon, Dec 3, 2012 at 5:22 PM, Matt Foley <[hidden email]> wrote:

> No, but it speaks to whether the Hadoop bylaws can extend the Apache voting
> procedures and draw finer distinctions.  For example, the Apache voting
> procedures only identify 3 types of votable issue, while the Hadoop bylaws
> identify 9 types of votable issues.
>
> If we were forced to fit "development tools" into one of the three
> categories cited by the Apache voting procedures, it would be fitting a
> square peg in a round hole.  Since we can instead look at the 9 categories
> provided by the Hadoop bylaws, we can acknowledge that "development tools"
> was an overlooked category.  But in my opinion it certainly doesn't fit
> into the "code change" category.  Tooling is a meta-issue regarding HOW we
> do what needs to be done.  In this case, whether we allow a
> platform-independent solution, or force contributors to maintain parallel
> scripts in multiple platform-specific languages for no reason.
>
> --Matt
>
>
> On Mon, Dec 3, 2012 at 3:57 PM, Doug Cutting <[hidden email]> wrote:
>
>> On Mon, Dec 3, 2012 at 2:08 PM, Matt Foley <[hidden email]> wrote:
>> > The apache voting process contradicts the Hadoop bylaws:
>> > http://www.apache.org/foundation/voting.html says that only PMC members
>> can
>> > make binding votes on code modification issues, but
>> > http://hadoop.apache.org/bylaws.html says that Committers can make
>> binding
>> > votes on them.  Does that mean the Hadoop bylaws have to change?
>>
>> This may be a little atypical but I don't see any harm.  The Hadoop
>> PMC is willing to respect the veto of any committer as binding.  I'd
>> worry more if we tried to reduce vetoes to a subset of the PMC than
>> extend it to a superset.
>>
>> Do you think this is problematic?
>>
>> Doug
>>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Matt Foley-2
Hi Doug,
I didn't read your email until this morning, but I spent time overnight
thinking about the Apache Way and reached similar conclusions.  While
tooling is broader in scope than a single code change, it is a technical
choice that we all have to live with.

More importantly, "Community over Code" would suggest that if only slightly
less than 50% of the community is uncomfortable with adding Python to the
mix which is the Hadoop stack, then we probably shouldn't do it, regardless
of the technical merits.

Therefore, I withdraw the question.

We will search for other means of cleaning up the shellscript problem and
making all functionality work with parity in the Windows world.  I am quite
partial to Allen Wittenauer's suggestion in
HADOOP-9082<https://issues.apache.org/jira/browse/HADOOP-9082?focusedCommentId=13507163&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13507163>
that
the scripts should be greatly simplified before dealing with the
cross-platform question.  It is in many respects silly to have so much
functionality "on the side" instead of dealing with it forthrightly in core
code.  In that spirit, I am also -1 on burying the same complexity in maven
plug-ins, which after all just adds another couple layers of complexity,
and limits the number of people who understand it, as well.

Thanks to all who voted and contributed to the discussion.
Best regards,
--Matt


On Mon, Dec 3, 2012 at 8:50 PM, Doug Cutting <[hidden email]> wrote:

> Hadoop's bylaws do draw finer distinctions than the Apache voting
> guidelines document, but we follow the same general principles that
> are described there.
>
> As I understand it, the rationale for using consensus for code is that
> everyone needs to agree on everything in the codebase or we've
> disenfranchised some.  We share a single code repository and we need
> to all agree on what goes into it.  A release does not require
> majority since if someone doesn't agree on the timing of a release
> they can choose to make another at a different time, but every change
> that goes into each release requires consensus.  We also require
> consensus for committers and PMC member votes so that we have a group
> that's coherent and is able to reach consensus on code changes.
>
> Re-writing bash scripts in Python is neither a release nor other
> procedural issue.  It involves changes to the software we maintain and
> seems to fall clearly into the "code change" category.
>
> If you disagree then perhaps you'd like to propose a change to the
> bylaws so that scripts have different rules than other kinds of
> software, but I don't yet see the rationale for such a change.
>
> Doug
>
> On Mon, Dec 3, 2012 at 5:22 PM, Matt Foley <[hidden email]> wrote:
> > No, but it speaks to whether the Hadoop bylaws can extend the Apache
> voting
> > procedures and draw finer distinctions.  For example, the Apache voting
> > procedures only identify 3 types of votable issue, while the Hadoop
> bylaws
> > identify 9 types of votable issues.
> >
> > If we were forced to fit "development tools" into one of the three
> > categories cited by the Apache voting procedures, it would be fitting a
> > square peg in a round hole.  Since we can instead look at the 9
> categories
> > provided by the Hadoop bylaws, we can acknowledge that "development
> tools"
> > was an overlooked category.  But in my opinion it certainly doesn't fit
> > into the "code change" category.  Tooling is a meta-issue regarding HOW
> we
> > do what needs to be done.  In this case, whether we allow a
> > platform-independent solution, or force contributors to maintain parallel
> > scripts in multiple platform-specific languages for no reason.
> >
> > --Matt
> >
> >
> > On Mon, Dec 3, 2012 at 3:57 PM, Doug Cutting <[hidden email]> wrote:
> >
> >> On Mon, Dec 3, 2012 at 2:08 PM, Matt Foley <[hidden email]>
> wrote:
> >> > The apache voting process contradicts the Hadoop bylaws:
> >> > http://www.apache.org/foundation/voting.html says that only PMC
> members
> >> can
> >> > make binding votes on code modification issues, but
> >> > http://hadoop.apache.org/bylaws.html says that Committers can make
> >> binding
> >> > votes on them.  Does that mean the Hadoop bylaws have to change?
> >>
> >> This may be a little atypical but I don't see any harm.  The Hadoop
> >> PMC is willing to respect the veto of any committer as binding.  I'd
> >> worry more if we tried to reduce vetoes to a subset of the PMC than
> >> extend it to a superset.
> >>
> >> Do you think this is problematic?
> >>
> >> Doug
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Radim Kolar-2
result of vote is to close
https://issues.apache.org/jira/browse/HADOOP-9073 and write groovy in
pom.xml variant (option number 2)?
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Matt Foley
Please close HADOOP-9073 as "will not fix", citing this discussion.

I'm -1 on groovy in maven.  That's worse, not better.  Let it sit for a
while and let people propose simplifications of the script situation.

Thanks,
--Matt


On Tue, Dec 4, 2012 at 11:41 AM, Radim Kolar <[hidden email]> wrote:

> result of vote is to close https://issues.apache.org/**
> jira/browse/HADOOP-9073<https://issues.apache.org/jira/browse/HADOOP-9073>and write groovy in pom.xml variant (option number 2)?
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Alejandro Abdelnur
i've been playing around writing a couple of maven plugins, one to replace saveversion.sh and the other to invoke protoc. they both work in windows standard cmd (no cygwin required). together with hadoop-8887 they would remove most of the scripting done the poms.

(they also work in linux and osx)

they are java based, only require having SVN GIT & PROTOC avail in the PATH.

if cmake works in windows, i assume hadoop-8887 would be almost there.

this would leave the tar stitching, which is done as script to handle SO symlinks. though i have and idea on how we could take care of it.

i'll be creating a jira momentarily.

thx

Alejandro

On Dec 4, 2012, at 12:28 PM, Matt Foley <[hidden email]> wrote:

> Please close HADOOP-9073 as "will not fix", citing this discussion.
>
> I'm -1 on groovy in maven.  That's worse, not better.  Let it sit for a
> while and let people propose simplifications of the script situation.
>
> Thanks,
> --Matt
>
>
> On Tue, Dec 4, 2012 at 11:41 AM, Radim Kolar <[hidden email]> wrote:
>
>> result of vote is to close https://issues.apache.org/**
>> jira/browse/HADOOP-9073<https://issues.apache.org/jira/browse/HADOOP-9073>and write groovy in pom.xml variant (option number 2)?
>>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Matt Foley
There's already a jira:
HADOOP-8924<https://issues.apache.org/jira/browse/HADOOP-8924>


On Tue, Dec 4, 2012 at 1:00 PM, Alejandro Abdelnur <[hidden email]>wrote:

> i've been playing around writing a couple of maven plugins, one to replace
> saveversion.sh and the other to invoke protoc. they both work in windows
> standard cmd (no cygwin required). together with hadoop-8887 they would
> remove most of the scripting done the poms.
>
> (they also work in linux and osx)
>
> they are java based, only require having SVN GIT & PROTOC avail in the
> PATH.
>
> if cmake works in windows, i assume hadoop-8887 would be almost there.
>
> this would leave the tar stitching, which is done as script to handle SO
> symlinks. though i have and idea on how we could take care of it.
>
> i'll be creating a jira momentarily.
>
> thx
>
> Alejandro
>
> On Dec 4, 2012, at 12:28 PM, Matt Foley <[hidden email]> wrote:
>
> > Please close HADOOP-9073 as "will not fix", citing this discussion.
> >
> > I'm -1 on groovy in maven.  That's worse, not better.  Let it sit for a
> > while and let people propose simplifications of the script situation.
> >
> > Thanks,
> > --Matt
> >
> >
> > On Tue, Dec 4, 2012 at 11:41 AM, Radim Kolar <[hidden email]> wrote:
> >
> >> result of vote is to close https://issues.apache.org/**
> >> jira/browse/HADOOP-9073<
> https://issues.apache.org/jira/browse/HADOOP-9073>and write groovy in
> pom.xml variant (option number 2)?
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Konstantin Boudnik-2
In reply to this post by Steve Loughran-3
On Sat, Dec 01, 2012 at 10:44AM, Steve Loughran wrote:

> On 1 December 2012 01:08, Eli Collins <[hidden email]> wrote:
>
> > -1, 0, -1
> >
> > IIUC the only platform we plan to add support for that we can't easily
> > support today (w/o an emulation layer like cygwin) is Windows, and it
> > seems like making the bash scripts simpler and having parallel bat
> > files is IMO a better approach.
> >
> >
> WinNT Bat/CMD files are the worst possible scripting language invented. At
> the very least, .py should be the language of choice there

Compare to the OS in question - it isn't _that_ bad ;)

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack

Konstantin Boudnik-2
In reply to this post by Eric Yang-2
On Sat, Dec 01, 2012 at 10:07PM, Eric Yang wrote:
> -1, +1, -1
>
> Python has fairly inconsistent support across all major OS vendors.  It is
> hard to get it right unless the scripts are all designed to make use of
> Python 2.4.  However, Python 2.4 doesn't have necessary OS features to make
> Python useful in runtime or build environment unless you write a lot of
> custom modules.  Which defeats the purpose to use python as intermediate
> layer to do OS dependent work.  Jruby may be a better choice.

JRuby? Really? Groovy is already there and it is really a Java dialect unlike
JRuby. And yes - it is quite suitable for build things, considering the use of
it in BigTop

Cos

> On Sat, Dec 1, 2012 at 12:28 PM, Joep Rottinghuis <[hidden email]>wrote:
>
> > 0, 0, -1 (non-binding)
> >
> > Joep
> >
> > On Nov 24, 2012, at 12:13 PM, Matt Foley <[hidden email]> wrote:
> >
> > > For discussion, please see previous thread "[PROPOSAL] introduce Python
> > as
> > > build-time and run-time dependency for Hadoop and throughout Hadoop
> > stack".
> > >
> > > This vote consists of three separate items:
> > >
> > > 1. Contributors shall be allowed to use Python as a platform-independent
> > > scripting language for build-time tasks, and add Python as a build-time
> > > dependency.
> > > Please vote +1, 0, -1.
> > >
> > > 2. Contributors shall be encouraged to use Maven tasks in combination
> > with
> > > either plug-ins or Groovy scripts to do cross-platform build-time tasks,
> > > even under ant in Hadoop-1.
> > > Please vote +1, 0, -1.
> > >
> > > 3. Contributors shall be allowed to use Python as a platform-independent
> > > scripting language for run-time tasks, and add Python as a run-time
> > > dependency.
> > > Please vote +1, 0, -1.
> > >
> > > Note that voting -1 on #1 and +1 on #2 essentially REQUIRES contributors
> > to
> > > use Maven plug-ins or Groovy as the only means of cross-platform
> > build-time
> > > tasks, or to simply continue using platform-dependent scripts as is being
> > > done today.
> > >
> > > Vote closes at 12:30pm PST on Saturday 1 December.
> > > ---------
> > > Personally, my vote is +1, +1, +1.
> > > I think #2 is preferable to #1, but still has many unknowns in it, and
> > > until those are worked out I don't want to delay moving to cross-platform
> > > scripts for build-time tasks.
> > >
> > > Best regards,
> > > --Matt
> >
123