[systemd-devel] [PATCH] *.py: don't hardcode /usr/bin/python

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Wed Dec 19 23:02:03 PST 2012


On Wed, Dec 19, 2012 at 11:02:30PM +0100, Lennart Poettering wrote:
> On Sat, 01.12.12 09:34, Ramkumar Ramachandra (artagnon at gmail.com) wrote:
> 
> > 
> > Michael Biebl wrote:
> > > 2012/11/30 Ramkumar Ramachandra <artagnon at gmail.com>:
> > >> Execute python using "/usr/bin/env python" instead of hard-coding the
> > >
> > > I'm not really a fan of using /usr/bin/env, as you can pick up a
> > > random python version depending on how your PATH is setup.
> > > Besides, you need to spawn an additional binary.
> > > I would assume that pretty much every distro ships the python
> > > interpreter as /usr/bin/python.
> > 
> > I don't follow your reasoning: it is idiomatic to use "/usr/bin/env
> > $interpreter", because every distro does not necessarily ship it as
> > /usr/bin/$interpreter.  
> 
> Always doing two exec()s instead of one sounds suboptimal to me. Given
> that this script is not supposed to be copiable to other distros, I'd
> suggest to detect the python part as configure time (which we do
> anyway in @PYTHON@) and rewrite the scripts to use that. That way, we
> don't do the unnecessary double exec() and we have the benefit that the
> scripts are executed with the same python version as was used to
> configure the build tree, which I think is quite desirable...

I had a patch moving all .py files to .py.in and then "translating"
them during build process to insert proper values of $PYTHON and
$PACKAGE_VERSION (for --version and --help). Didn't post because I
thought it is too much noise for little gain. I'll dig it up, clean
up, and post here.

Zbyszek


More information about the systemd-devel mailing list