build: make python executable configurable

build: make python executable configurable

[bnoordhuis1, 2012-11-20 21:38:39]

Makes the name of the python executable configurable, for systems where it's
called e.g. `python2.7` instead of just `python`.

[Michael Starzinger, 2012-11-21 09:50:42]

This is more up Jakob's alley, handing over.

[Jakob Kummerow, 2012-11-21 10:04:53]

How about this instead:

sudo /usr/bin/python2.7 /usr/bin/python

That fixes all your scripts/applications/buildsystems at once, which is an
approach that scales much better than adding complexity to 150 other projects.

[bnoordhuis1, 2012-11-23 22:44:16]

On 2012/11/21 10:04:53, Jakob wrote:
> How about this instead:
> 
> sudo /usr/bin/python2.7 /usr/bin/python
> 
> That fixes all your scripts/applications/buildsystems at once, which is an
> approach that scales much better than adding complexity to 150 other projects.

In case you missed my reply on the mailing list: that only works if the user has
root access on that machine.

I don't understand your "adding complexity to 150 other projects" remark. It's a
self-contained patch to V8 that adds an *optional* override. It does *not*
change the default behavior.

[bnoordhuis, 2013-02-01 12:15:14]

V8 people, will you please reconsider this patch?  If not, can you explain
what's so abhorrent about it?  Jakob's argument is a little weak, IMO.

People complain that node.js (actually V8) is impossible to build on systems
where python is in a non-standard place or is python3 (Arch Linux).  It's an
issue that keeps coming up on our issue tracker, mailing list, IRC channel, etc.

[Jakob Kummerow, 2013-02-01 13:43:05]

On 2012/11/23 22:44:16, bnoordhuis1 wrote:
> On 2012/11/21 10:04:53, Jakob wrote:
> > How about this instead:
> > 
> > sudo ln -s /usr/bin/python2.7 /usr/bin/python
> > 
> > That fixes all your scripts/applications/buildsystems at once, which is an
> > approach that scales much better than adding complexity to 150 other
projects.
> 
> In case you missed my reply on the mailing list:

I saw it.

> that only works if the user has root access on that machine.

Aw, come on:
ln -s /usr/bin/python2.7 ~/bin/python
export PATH="~/bin:$PATH"

> I don't understand your "adding complexity to 150 other projects" remark. It's
a
> self-contained patch to V8 that adds an *optional* override. It does *not*
> change the default behavior.

Adding an optional override means adding complexity. Sure, it's a small change,
but small portions of complexity also add up, and at some point you have
hundreds of thousands of possible combinations of flags and overrides, it'll be
unclear which of them are used, which are outdated, which are broken anyway, and
it becomes next to impossible to change anything without breaking something. The
latter point means that this *will* break at some point: someone will modify the
build system and forget or just not know that "python" should not be hard-coded.


This CL is an example of complexity that I think can be avoided. If you happen
to run one of the 1% of Unix-like operating systems where "python" isn't called
"python", fixing your system is easier, more robust and more scalable than
fixing all scripts that expect to have a plain "python" binary somewhere on the
$PATH. (Even better, upstream the change to make the OS more usable for
everyone.)

If Sven still doesn't agree with me, he is free to approve and land this patch,
I won't veto that.

[Jgeralnik, 2013-06-09 05:37:13]

> > > That fixes all your scripts/applications/buildsystems at once, which is an
> > > approach that scales much better than adding complexity to 150 other
> projects.
> > 
This argument may apply for some tools. Certainly I think it is fair to expect
'touch' to be the touch tool, and rm to be that tool that removes things. If a
user overrides touch or rm that seems like a silly thing to do which should be
fixed. 

Python is different because my python binary _is_ python - it's just python 3
and not python 2.7. This is not an inherent bug or problem that I want to fix. 

> This CL is an example of complexity that I think can be avoided. If you happen
> to run one of the 1% of Unix-like operating systems where "python" isn't
called
> "python", fixing your system is easier, more robust and more scalable than
> fixing all scripts that expect to have a plain "python" binary somewhere on
the
> $PATH. (Even better, upstream the change to make the OS more usable for
> everyone.)
python3 is the future of python. There may be only a few oses that have taken
the plunge to having it as default, but that will change. It is a release goal
for Ubuntu 14.04 LTS to have only Python 3 on the desktop CD images[1]. While it
is fine to use python 2 for now, recognizing that python is not and will not
always be python 2 is important to allow all users to build. 

[1] https://wiki.ubuntu.com/Python/3

[Jgeralnik, 2013-06-09 05:37:13]

> > > That fixes all your scripts/applications/buildsystems at once, which is an
> > > approach that scales much better than adding complexity to 150 other
> projects.
> > 
This argument may apply for some tools. Certainly I think it is fair to expect
'touch' to be the touch tool, and rm to be that tool that removes things. If a
user overrides touch or rm that seems like a silly thing to do which should be
fixed. 

Python is different because my python binary _is_ python - it's just python 3
and not python 2.7. This is not an inherent bug or problem that I want to fix. 

> This CL is an example of complexity that I think can be avoided. If you happen
> to run one of the 1% of Unix-like operating systems where "python" isn't
called
> "python", fixing your system is easier, more robust and more scalable than
> fixing all scripts that expect to have a plain "python" binary somewhere on
the
> $PATH. (Even better, upstream the change to make the OS more usable for
> everyone.)
python3 is the future of python. There may be only a few oses that have taken
the plunge to having it as default, but that will change. It is a release goal
for Ubuntu 14.04 LTS to have only Python 3 on the desktop CD images[1]. While it
is fine to use python 2 for now, recognizing that python is not and will not
always be python 2 is important to allow all users to build. 

[1] https://wiki.ubuntu.com/Python/3

[Jgeralnik, 2013-06-09 05:37:14]

> > > That fixes all your scripts/applications/buildsystems at once, which is an
> > > approach that scales much better than adding complexity to 150 other
> projects.
> > 
This argument may apply for some tools. Certainly I think it is fair to expect
'touch' to be the touch tool, and rm to be that tool that removes things. If a
user overrides touch or rm that seems like a silly thing to do which should be
fixed. 

Python is different because my python binary _is_ python - it's just python 3
and not python 2.7. This is not an inherent bug or problem that I want to fix. 

> This CL is an example of complexity that I think can be avoided. If you happen
> to run one of the 1% of Unix-like operating systems where "python" isn't
called
> "python", fixing your system is easier, more robust and more scalable than
> fixing all scripts that expect to have a plain "python" binary somewhere on
the
> $PATH. (Even better, upstream the change to make the OS more usable for
> everyone.)
python3 is the future of python. There may be only a few oses that have taken
the plunge to having it as default, but that will change. It is a release goal
for Ubuntu 14.04 LTS to have only Python 3 on the desktop CD images[1]. While it
is fine to use python 2 for now, recognizing that python is not and will not
always be python 2 is important to allow all users to build. 

[1] https://wiki.ubuntu.com/Python/3

[keith.hughitt, 2013-11-25 17:23:51]

I'm also affected by this. Are there any plans to support native Python 3
systems?