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
Hadoop >> mail # dev >> [PROPOSAL] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack


+
Matt Foley 2012-11-21, 19:15
+
Radim Kolar 2012-11-23, 23:40
+
Matt Foley 2012-11-24, 20:13
+
Radim Kolar 2012-11-24, 21:26
+
Konstantin Boudnik 2012-11-24, 22:03
+
Alejandro Abdelnur 2012-11-21, 19:25
+
Radim Kolar 2012-11-21, 20:46
+
Konstantin Boudnik 2012-11-21, 21:33
+
Konstantin Boudnik 2012-11-21, 20:00
+
Matt Foley 2012-11-21, 21:14
+
Konstantin Boudnik 2012-11-21, 21:50
Copy link to this message
-
Re: [PROPOSAL] introduce Python as build-time and run-time dependency for Hadoop and throughout Hadoop stack
On Wed, Nov 21, 2012 at 1:50 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:
> The main point of my argument expressed in a lesser than 100 words: adding
> Python that is inconsistent across different Linux distros and has a history
> of backward incompatibilities (2.6 vs 2.5, 3.0 vs earlier, etc.) doesn't seem
> to leverage the benefit of having a somewhat easier build in Windows.

This seems mostly like a red herring to me. I'll grant that it's hard
to build a complete Python stack that's compatible between Python 2.x
and 2.y, but it's very easy by following best practices to keep python
*scripts* compatible across all reasonable Python 2.x versions.
Simply pick an oldest-supported-version like 2.4 and be reasonably
disciplined to not use newer constructs or libraries. I wouldn't wish
to try to build a complete system in such a limited dialect [1], but
for "we need a reasonable replacement for /bin/sh scripts" it's just
fine.

Ignore Python 3 for the time being, it's a completely different
language with incompatible syntax and semantics that doesn't support
several currently-important platforms.  Maybe in a few years sane
people can consider moving to it, but for now it's best to just stick
with the compatible subset of Python 2.x.

[1] the Mercurial project has had a pretty good experience with this
scheme; http://mercurial.selenic.com/wiki/SupportedPythonVersions they
currently support 2.4 - 2.7 with a few required libraries. They
dropped 2.2 and 2.3 support a few years ago due to specific
shortcomings on those versions.

-andy
+
Radim Kolar 2012-11-21, 23:58
+
Steve Loughran 2012-11-22, 09:21
+
Konstantin Boudnik 2012-11-22, 01:46
+
Radim Kolar 2012-11-22, 01:57
+
Chris Nauroth 2012-11-21, 21:03
+
Radim Kolar 2012-11-21, 21:30
+
Chris Nauroth 2012-11-21, 21:44
+
Radim Kolar 2012-11-21, 23:15
+
Chris Nauroth 2012-11-22, 00:14
+
Radim Kolar 2012-11-22, 01:55
+
Chris Nauroth 2012-11-22, 02:40
+
Radim Kolar 2012-11-22, 14:54
+
Steve Loughran 2012-11-22, 09:02
+
Matt Foley 2012-11-21, 19:44
+
Alejandro Abdelnur 2012-11-21, 19:58
+
Steve Loughran 2012-11-22, 09:14
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