#!/usr/bin/env python vs. #!/usr/bin/python

[D'Arcy J.M. Cain]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

On Fri, 02 May 2008 23:30:01 +1000
Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

The OP was asking why people prefer on over the other. My answer is
that I prefer specifying "give me the default OS Python" because
anything not installed by the OS is to non-standardised for me to
worry about.

As someone else pointed out, not all the world is Linux. So your
version of Linux (I'm not sure whether it is true for all versions or
not) delivers Python as part of the OS. That is simply not true of the
whole world. Some OS distributions have an adjunct facility for
installing packages but they are not part of the OS. Some systems
don't even have that and people must download packages such as Python
and install them manually. Even on Linux there are people who won't
install binaries and use NetBSD's pkgsrc instead. Clearly that cannot
install into /usr/bin since it is not part of the OS.

Certainly #! /usr/bin/python is fine if you never expect your software
to run outside of your own little corner of the world but you asked why
people prefer the env version and the answer is that we want to write
software that runs everywhere that Python runs.

--
D'Arcy J.M. Cain <darcy@druid.ne t | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

[Torsten Bronger]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

Hallöchen!

D'Arcy J.M. Cain writes:

On Fri, 02 May 2008 23:30:01 +1000
Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:
>

>The OP was asking why people prefer on over the other. My answer
>is that I prefer specifying "give me the default OS Python"
>because anything not installed by the OS is to non-standardised
>for me to worry about.

>
[...]
>
Certainly #! /usr/bin/python is fine if you never expect your
software to run outside of your own little corner of the world but
you asked why people prefer the env version and the answer is that
we want to write software that runs everywhere that Python runs.

Granted, but you must draw the line somewhere anyway. I cannot
pollute my program with hundreds of if clauses just to make it work
on every quirky system. It's the *systems* where the streamlining
must happen, not the programs.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: bronger@jabber. org
(See http://ime.webhop.org for further contact info.)

[Ben Finney]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

Thorsten Kampe <thorsten@thors tenkampe.dewrit es:

* Ben Finney (Fri, 02 May 2008 23:30:01 +1000)

The OP was asking why people prefer on over the other. My answer
is that I prefer specifying "give me the default OS Python"
because anything not installed by the OS is to non-standardised
for me to worry about.

Others may prefer something different, but then they get to wear
whatever problems occur as a result of that choice. I continue to
be bemused by that preference, and nothing that I've seen so far
in this thread illuminates the issue more.

>
You're missing the point. Apart from the really dubious terms you
use ("OS installable package"), using env in the first line has
exactly the effect to use the default path of Python (which is the
first entry in your path)

No, because it's quite common for the PATH variable to have
'/usr/local/bin' appear *before* both of '/bin' and '/usr/bin'.

If the system has a sysadmin-installed '/usr/local/bin/python'
installed as well as the OS-installed '/usr/bin/python', then the two
shebang options the OP raised will behave differently on such a
system. This seems to be quite the point of the discussion.

--
\ "Time's fun when you're having flies." -- Kermit the Frog |
`\ |
_o__) |
Ben Finney

[Grant Edwards]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

On 2008-05-02, Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

The specified command takes the form of a fully-qualified file
path, and zero or one arguments to the program. That command
is then executed by the kernel, and the Python program file is
passed as input to the resulting process.

Just to clarify that a bit a little, the name of the file (as
it was given to the "exec" system call) containing the "shebang
line" is passed to the resulting process as a command-line
parameter.

>Why is one preferred over the other one ?

>
I've never clearly understood why people want to use "#! /usr/bin/env
python", which is prone to finding a different Python from the one
installed by the operating system. I'd be interested to see what
responses are in favour of it, and what the reasoning is.
>
One possible reason is that the programmer is attempting to allow for
systems where Python has been installed, but not from an operating
system package.

Exactly. the "env" approach works as long as python is
installed somewhere on the PATH. "#!/usr/bin/python" will fail
if python is installed in /usr/local/bin/python.

--
Grant

[Ben Finney]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

Roy Smith <roy@panix.comw rites:

In article <87r6ckzvyv.fsf @benfinney.id.a u>,
Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:
>

Whereas if Python is *not* installed from an OS package, it's up
to the sys admin to ensure that it works -- not up to my program.
So I don't see the point in making it work by default, when what I
want for my program is that it works *with the default Python*,
not with some non-default installation.

>
Ben,
>
Have you ever shipped software to a customer?

Yes, and all parties have been quite happy with the results.

Imagine the following conversation:
>
Customer: "Your product is broken. It says it can't find python, and
I know I have it installed".
>
Vendor: "Where do you have it installed?"
>
Customer: "In /opt/bin/python"
>
Vendor: "Oh, that's your problem, it HAS to be in /usr/bin/python".

At this point the vendor isn't me, because this statement isn't true.
See below.

Customer: "I can't install it there because <insert whatever silly
reason the customer has>. If you can't make your product work
without requiring me to install python in /usr/bin, I'm afraid I
can't buy your product".

At this point they have the simple option of running the program with
'python /path/to/the/program'. It's certainly not a case of "can't
make the product work".

It is, however, a case of "can't automatically account for every local
customisation sysadmins choose to make on their systems". Perfectly
willing to work with them to get their specific environment working,
but as a matter of simple economics it's not worth my time to attempt
to make such corner cases work automatically.

If you want to hard-code /usr/bin/python into your application,
that's your decision. If you would like to take on the task of
convincing every sysadmin in the world to do things the way you
think they should be done, have fun.

If they've already chosen to install Python to some unpredictable
location, they know what they're doing enough to invoke the program in
a specific way to get it working.

--
\ Rommel: "Don't move, or I'll turn the key on this can of Spam!" |
`\ -- The Goon Show, _Rommel's Treasure_ |
_o__) |
Ben Finney

[Ben Finney]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

"D'Arcy J.M. Cain" <darcy@druid.ne twrites:

On Fri, 02 May 2008 23:30:01 +1000
Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

The OP was asking why people prefer on over the other. My answer
is that I prefer specifying "give me the default OS Python"
because anything not installed by the OS is [too] non-standardised
for me to worry about.

>
As someone else pointed out, not all the world is Linux.

It's a good thing I've never implied such to be the case.

--
\ "If nature has made any one thing less susceptible than all |
`\ others of exclusive property, it is the action of the thinking |
_o__) power called an idea" -- Thomas Jefferson |
Ben Finney

[Grant Edwards]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

On 2008-05-02, Jeroen Ruigrok van der Werven <asmodai@in-nomine.orgwrote :

>>I've never clearly understood why people want to use "#! /usr/bin/env
>>python", which is prone to finding a different Python from the one
>>installed by the operating system. I'd be interested to see what
>>responses are in favour of it, and what the reasoning is.

>
Simple, some systems are not as peculiar as a lot of Linux boxes which
chug everything into /usr/bin, which is OS territory

On many Linux distros, Python is pretty much part of the OS.
Since the early days of RedHat, Python has been part of the
base/minimum install since a lot of the "required" system
utilities were written in python. In Redhat, the package
manger was originally written in Python, so Python had to be in
"OS territory".

(as has been decreed long ago by hier(7)), but rather use
/usr/local/bin (all BSD Unix and derivatives) or /opt or
whatever convention a particular operating system has.

In the Linux world, /usr/local/bin and /opt are for stuff
installed by the user, not stuff that is an integral, required
part of the OS distribution.

--
Grant

[Grant Edwards]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

On 2008-05-02, Jeroen Ruigrok van der Werven <asmodai@in-nomine.orgwrote :

-On [20080502 07:51], Ben Finney (bignose+hates-spam@benfinney. id.au) wrote:

>>To my mind, the Python interpreter installed by a package as
>>distributed with the OS *is* OS territory and belongs in /usr/bin/.

>
That's the difference with a distribution, such as Linux, and full OSes ,
such as BSDs or commercial Unix variants. They prefer to keep a pristine
state for the OS vendor files

Python _is_ an OS vendor file in the Linux world.

versus what the user can opt to install himself,

Traditionally, Python has not been optional.

hence the /usr/bin - /usr/local/bin separation. Same for sbin,
lib, and so on. It effectively guarantees you can nuke
/usr/local without ill consequences for your OS.

That's the point. You _couldn't_ nuke Python and have your
system keep running. That's why it was in /usr/bin.

--
Grant

[D'Arcy J.M. Cain]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

On Fri, 02 May 2008 16:26:51 +0200
Torsten Bronger <bronger@physik .rwth-aachen.dewrote:

Certainly #! /usr/bin/python is fine if you never expect your
software to run outside of your own little corner of the world but
you asked why people prefer the env version and the answer is that
we want to write software that runs everywhere that Python runs.

>
Granted, but you must draw the line somewhere anyway. I cannot

No one is talking about if statements here.

--
D'Arcy J.M. Cain <darcy@druid.ne t | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

[Torsten Bronger]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

Hallöchen!

D'Arcy J.M. Cain writes:

On Fri, 02 May 2008 16:26:51 +0200
Torsten Bronger <bronger@physik .rwth-aachen.dewrote:
>

>>Certainly #! /usr/bin/python is fine if you never expect your
>>software to run outside of your own little corner of the world
>>but you asked why people prefer the env version and the answer
>>is that we want to write software that runs everywhere that
>>Python runs.

>>
>Granted, but you must draw the line somewhere anyway. I cannot

>
No one is talking about if statements here.

Sorry to become laconical, but your reply was so, too:

http://en.wikipedia.org/wiki/Abstraction

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: bronger@jabber. org
(See http://ime.webhop.org for further contact info.)

[D'Arcy J.M. Cain]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

On Sat, 03 May 2008 00:44:00 +1000
Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

"D'Arcy J.M. Cain" <darcy@druid.ne twrites:

As someone else pointed out, not all the world is Linux.

>
It's a good thing I've never implied such to be the case.

You haven't *said* it but you have definitely *implied* it. Installing
Python in /usr/bin is not common. It is very specific to your system.

--
D'Arcy J.M. Cain <darcy@druid.ne t | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

[D'Arcy J.M. Cain]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

On Sat, 03 May 2008 00:43:02 +1000
Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

Roy Smith <roy@panix.comw rites:

Have you ever shipped software to a customer?

>
Yes, and all parties have been quite happy with the results.

When some of us talk about shipping software we aren't talking about a
20 line script delivered to our uncle's construction company office. We
are talking about millions of lines of code in thousands of programs and
modules that has to run out of the box on whatever system the client
happens to run on.

Customer: "I can't install it there because <insert whatever silly
reason the customer has>. If you can't make your product work
without requiring me to install python in /usr/bin, I'm afraid I
can't buy your product".

>
At this point they have the simple option of running the program with
'python /path/to/the/program'. It's certainly not a case of "can't
make the product work".

Simple for your 20 line single script. Not so simple for my million
line, integrated system that has to work everywhere.

It is, however, a case of "can't automatically account for every local
customisation sysadmins choose to make on their systems". Perfectly
willing to work with them to get their specific environment working,
but as a matter of simple economics it's not worth my time to attempt
to make such corner cases work automatically.

If by "corner case" you mean "some system that I don't personally run"
then OK but to some of us your system is the corner case and we would
like our code to run there as well.

Real software has to deal with the fact that support costs money.
You may be able to deal with one or two clients that way but that does
not scale very well.

If they've already chosen to install Python to some unpredictable
location, they know what they're doing enough to invoke the program in
a specific way to get it working.

Unpredictable to you. Perfectly predictable on their system.

I do believe I am done with this thread.

--
D'Arcy J.M. Cain <darcy@druid.ne t | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

[Grant Edwards]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

On 2008-05-02, D'Arcy J.M. Cain <darcy@druid.ne twrote:

On Sat, 03 May 2008 00:44:00 +1000
Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

>"D'Arcy J.M. Cain" <darcy@druid.ne twrites:

As someone else pointed out, not all the world is Linux.

>>
>It's a good thing I've never implied such to be the case.

>
You haven't *said* it but you have definitely *implied* it.
Installing Python in /usr/bin is not common.

It is common. That's where it's installed by almost all Linux
distributions.

It is very specific to your system.

Are you claiming that Linux is not a "common" Unix-like OS?

--
Grant

[Yves Dorfsman]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

Thanks everybody, I didn't mean to start a flamewar...
I do get it now, it's whatever python is in the path, vs. the specific one
you're pointing to.

Ben Finney wrote:

>
No, because it's quite common for the PATH variable to have
'/usr/local/bin' appear *before* both of '/bin' and '/usr/bin'.
>
If the system has a sysadmin-installed '/usr/local/bin/python'
installed as well as the OS-installed '/usr/bin/python', then the two
shebang options the OP raised will behave differently on such a
system. This seems to be quite the point of the discussion.
>

And I have to admit, I prefer specifying the version (full path) because I
have run into too many problem when users have different PATHs and end up
running different version of an interpreter.

Yves.
--

http://www.SollerS.ca

[Thorsten Kampe]

Re: #!/usr/bin/env python vs. #!/usr/bin/python

* Ben Finney (Sat, 03 May 2008 00:37:45 +1000)

Thorsten Kampe <thorsten@thors tenkampe.dewrit es:

* Ben Finney (Fri, 02 May 2008 23:30:01 +1000)

The OP was asking why people prefer on over the other. My answer
is that I prefer specifying "give me the default OS Python"
because anything not installed by the OS is to non-standardised
for me to worry about.
>
Others may prefer something different, but then they get to wear
whatever problems occur as a result of that choice. I continue to
be bemused by that preference, and nothing that I've seen so far
in this thread illuminates the issue more.

You're missing the point. Apart from the really dubious terms you
use ("OS installable package"), using env in the first line has
exactly the effect to use the default path of Python (which is the
first entry in your path)

>
No, because it's quite common for the PATH variable to have
'/usr/local/bin' appear *before* both of '/bin' and '/usr/bin'.
>
If the system has a sysadmin-installed '/usr/local/bin/python'
installed as well as the OS-installed '/usr/bin/python', then the two
shebang options the OP raised will behave differently on such a
system. This seems to be quite the point of the discussion.

Again you're missing the point. If you or whoever installs Python (or
another version of Python) to /usr/local/bin and puts this in the path
to front (as it's often done) then /you/ want that Python to be the
"default" one. It would just be silly to say "no, I the developer want
/usr/bin/python".

So in general "#! env" is better while in certain circumstance
hardcoding the path to /usr/bin/python can be better.


Thorsten