#!/usr/bin/python2.3 vs #!/usr/bin/env python2.3

[John Goerzen]

Hello,

Many Python programs use constructs like #!/usr/bin/env python2.3 to load
themselves. Many others use #!/usr/bin/python2.3. On most Debian systems,
these are the same.

The submitter in #189473 claims that #!/usr/bin/env python2.3 is wrong
because he has his own python2.3 on the path prior to the system's, and it
doesn't necessarily have requisite libraries for the programs being run.

Any opinions?

-- John

--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Matthias Klose]

John Goerzen writes:
> Hello,
>
> Many Python programs use constructs like #!/usr/bin/env python2.3 to load
> themselves. Many others use #!/usr/bin/python2.3. On most Debian systems,
> these are the same.
>
> The submitter in #189473 claims that #!/usr/bin/env python2.3 is wrong
> because he has his own python2.3 on the path prior to the system's, and it
> doesn't necessarily have requisite libraries for the programs being run.
>
> Any opinions?

I think you should use the /usr/bin prefix to enforce the dependencies
that your package has. After the temp. install in debian/* I use:

: # Replace all '#!' calls to python with $(PY_INTERPRETER)
: # and make them executable
for i in `find debian/foo -type f`; do \
sed '1s,#!.*python[^ ]*\(.*\),#! $(PY_INTERPRETER)\1,' \
$$i > $$i.temp; \
if cmp --quiet $$i $$i.temp; then \
rm -f $$i.temp; \
else \
mv -f $$i.temp $$i; \
chmod 755 $$i; \
echo "fixed interpreter: $$i"; \
fi; \
done

[Donovan Baarda]

On Tue, 2003-08-12 at 06:50, John Goerzen wrote:
> Hello,
>
> Many Python programs use constructs like #!/usr/bin/env python2.3 to load
> themselves. Many others use #!/usr/bin/python2.3. On most Debian systems,
> these are the same.
>
> The submitter in #189473 claims that #!/usr/bin/env python2.3 is wrong
> because he has his own python2.3 on the path prior to the system's, and it
> doesn't necessarily have requisite libraries for the programs being run.

The submitter is basically right. There have been discussions about this
on this list in the past. However, the python policy has the following;

Programs that can run with any version of Python should be started
with `#!/usr/bin/python'. They must also specify a dependency on
`python'. You're free to use `#!/usr/bin/env python', if you'd
like
to give the user a chance to override the Debian Python package
with a
local version.

and;

Programs which require a specific version of Python must start with
`#!/usr/bin/python<X>.<Y>'. They must also specify a dependency on
`python<X>.<Y>'. Again, if you're using `#!/usr/bin/env
python<X>.<Y>', please be aware that a user might override the
Debian
Python package with a local version.

Despite the Python Policy allowing you to use #!/usr/bin/env, the
general consensus is that it is a bad idea. Package maintainers who
choose to use it must be prepared to justify their decision and deal
with bug reports from users with broken local installations of python.

--
Donovan Baarda <a...@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/

[Jérôme Marant]

Quoting John Goerzen <jgoe...@complete.org>:

> Hello,
>
> Many Python programs use constructs like #!/usr/bin/env python2.3 to load
> themselves. Many others use #!/usr/bin/python2.3. On most Debian systems,
> these are the same.
>
> The submitter in #189473 claims that #!/usr/bin/env python2.3 is wrong
> because he has his own python2.3 on the path prior to the system's, and it
> doesn't necessarily have requisite libraries for the programs being run.

#!/usr/bin/env python2.3 helps programs running everywhere, i.e. they
will work with people that installed python in /usr/local/bin for
instance.

--
Jérôme Marant

[Jérôme Marant]

Quoting Jérôme Marant <jma...@free.fr>:

> Quoting John Goerzen <jgoe...@complete.org>:
>
> > Hello,
> >
> > Many Python programs use constructs like #!/usr/bin/env python2.3 to load
> > themselves. Many others use #!/usr/bin/python2.3. On most Debian
> systems,
> > these are the same.
> >
> > The submitter in #189473 claims that #!/usr/bin/env python2.3 is wrong
> > because he has his own python2.3 on the path prior to the system's, and it
> > doesn't necessarily have requisite libraries for the programs being run.
>
> #!/usr/bin/env python2.3 helps programs running everywhere, i.e. they
> will work with people that installed python in /usr/local/bin for
> instance.

Hmm, after reading everyone's arguments, it seems wiser to use
#!/usr/bin/python2.3 in order to avoid mixing with local python
installs.

[Derrick 'dman' Hudson]

Here's my perspective on this :

On Tue, Aug 12, 2003 at 10:10:57AM +0200, Jérôme Marant wrote:

| > #!/usr/bin/env python2.3 helps programs running everywhere, i.e. they
| > will work with people that installed python in /usr/local/bin for
| > instance.

Use this if you are distributing your script/program to the world at
large.

| Hmm, after reading everyone's arguments, it seems wiser to use
| #!/usr/bin/python2.3 in order to avoid mixing with local python
| installs.

Use this in a debian package.

The difference: on $RANDOM_UNIX_SYSTEM you don't know that pythonX.Y
is in /usr/bin, but on a debian system you do and on a debian system
you'd rather not deal with other installations in $ENV.

-D

--
If Microsoft would build a car...
... Occasionally your car would die on the freeway for no reason. You
would have to pull over to the side of the road, close all of the car
windows, shut it off, restart it, and reopen the windows before you
could continue. For some reason you would simply accept this.

http://dman13.dyndns.org/~dman/

[Federico Di Gregorio]

Il mar, 2003-08-12 alle 15:41, Derrick 'dman' Hudson ha scritto:
[snip]

> | Hmm, after reading everyone's arguments, it seems wiser to use
> | #!/usr/bin/python2.3 in order to avoid mixing with local python
> | installs.
>
> Use this in a debian package.
>
> The difference: on $RANDOM_UNIX_SYSTEM you don't know that pythonX.Y
> is in /usr/bin, but on a debian system you do and on a debian system
> you'd rather not deal with other installations in $ENV.

i think we pretty much all agree here. what about changing the python
policy?

--
Federico Di Gregorio
Debian GNU/Linux Developer f...@debian.org
INIT.D Developer f...@initd.org
Best friends are often failed lovers. -- Me