Re: Denying #!/usr/bin/env as a valid interpreter

[Aleksej Saushev <asau%inbox.ru@localhost>]

  Hello!

George Michaelson <ggm%pobox.com@localhost> writes:

> Maybe I am misreading things, but this reads to me like a proposal to 
> ignore what python people experience on *every other platform* and 
> attempt to enforce a 'NetBSD does this different' position.
>
> I love NetBSD, but thats a form of mental torture that I suspect few 
> python developers want to go with.
>
> if #!/usr/bin/env python doesn't work on NetBSD, then NetBSD has a 
> problem, not python. If the problem is which python to invoke, then I 
> think it bears musing how other Unix-like platforms deal with this.
>
> What I am reading here smells a lot like 'we wont fix/change netbsd' 
>
> Please tell me I'm wrong.

This argument is of "millions of flies can't mistake" type.

Most people do not understand why static binding is better than dynamic
one, they don't know what it is about at all until it is late and they
find themselves in serious trouble. If python people don't understand
the difference and why this matters at all, I want it to be their
problem rather than mine.

Sure, when doing trivial things binding rules don't matter at all.
But then you don't need package management system as well, since you can
build everything from the source yourself. Why are we all here then?
Pkgsrc is the tool to cope with large and complex systems. There you can
have more than one "python" program, and it may be that all of them are
interpreters, possibly incompatible ones. This is the case, when system
built with dynamic scoping starts falling apart.

Consider some installation. Forget pkgsrc and assume that you install
software from source, you get some complex piece in /usr/local with all
your "/usr/bin/env python" there. You install some more packages and have
more and more scripts with this behaviour.

Then you suddenly need _another_ python version, slightly incompatible one.
Say, some piece of software needs exactly that. What are you doing?
Alright, if all you need is just to try it out, you can deploy chroot jail
or even virtual machine. What do you do when you need two python interpreters
coexisting? You install another version into, say, /usr/local2.

Welcome to dynamic scope! You have to decide when you need /usr/local2/bin 
in PATH, when you do not, and when you do not want it at all. But this doesn't
solve all your problems. You can install new interpreter, but when you
start installing other software using this interpreter you find that
something magically doesn't work. After you spend a day debugging it,
you'll find that your new package correctly detects presense of some of its
dependencies in /usr/local, but when it invokes some other script though
a long chain of calls it breaks, since the latter script doesn't expect python
that old or that new. "python" suddenly changed place due to you changing PATH.

When you start working with such system intensively, you find that you
need to set PATH explicitly for nearly every command invoking "python".
Alternatively you need to create shell wrappers doing exactly that.
You find that you frequently need to dive deep into modules to check how
they cope with PATH and whether it is set correctly or not at that point.
Thus your modular system, that is there to encapsulate details and
isolate you from those issues, just suddenly stops to work.
Or you'd rather have listened to those who had such experience and replace
"#!/usr/bin/env python" with something sensible.


-- 
HE CE3OH...