On Sat, 2019-07-20 at 15:26 -0500, Tim Daneliuk wrote: > On 7/20/19 2:56 PM, Peter J. Holzer wrote: > > On 2019-07-20 14:11:44 -0500, Tim Daneliuk wrote: > > > So, no, do NOT encode the hard location - ever. Always use env to > > > discover the one that the user has specified. The only exception is > > > /bin/sh which - for a variety of reasons - can reliably counted upon. > > > > > > We don't need to bikeshed this. All we need is people who disagree > > > with this view to spend a year in software packaging, operations, > > > deployment and DevOps ... then get back to us... > > > > After 25 years in software packaging, operations, deployment and DevOps > > I disagree: A program should not behave differently because of a > > different path, #!/usr/bin/env is a total no-no. > > > > There is a nice way to achieve this: Just use the interpreter of the > > virtual environment in the shebang. > > (That requires rewriting the shebang during installation, but that's a > > minor inconvenience) > > > > hp > > > > > And what happens with programs that have no virtenv equivalent? > perl, go, ruby, awk, sed, grep, etc. have no simple way to > get installed virtual short of insisting the everything live in a > docker container or VM? > > The fact is that most large compute environments are slow to upgrade > the OS. That means core tools also lag considerably behind as well. > Being able to install newer versions along side the OS' own and then > use them by default is manifestly necessary. That's why users have > the ability to modify $PATH to suit their own needs. All /usr/bin/env > does is to tell the interpreter, "honor the intent of the spawning shell". > This shouldn't even be a question ... and it's why so much garbage continues > to live forever. Having to constantly code around old systems versions of > tools with not other recourse is just crazy. > > In actual fact, the very best way to write portable, reliable, and operable > systems of code is to divorce them entirely (or as a nearly as possible) for > the OS tools as you can. That's why docker works so well. That's why go > avoids dynamic linking. > > In my case, that's why I compile my own version of > languages and daily use utilities to live outside the OS. I get absolutely > predicable behavior irrespective of my distro and whatever backleveled cruft > it has laying around. I _know_ every version of every important tool my code > will be using ... all by setting up $PATH properly and using /usr/bin/env in > my interpreters. > > If you want really big fun, try going into an older CentOS or RedHat > instances and, say, > upgrading system python to python3. It's super fun. Yes, in that case, you > COULD > use a venv. But there are tons of other tools for which this is not an > option - > gcc, autoconf, perl, go awk, sed, bash, ad infinitum, ad nauseum are > invariably > backleveled on production OS instances. My way fixes that problem. Your way > forces me to code around it ... which is a way worse solution. > > You may have 25 years at this but I have 40 - does that make me nearly twice > as right? Arguments from authority are silly. > > P.S. https://www.tundraware.com/TechnicalNotes/Divorce-Your-Linux-Admin/ Nice.
Emacs (well spacemacs) is my authority. The key sequence 'SPC i !' inserts #!/usr/bin/env python as specified in the insert-shebang package https://github.com/psachin/insert-shebang My limited experience tells me to expect the user (me) to know what they're doing, hence env. Why not make a compromise? What would be a potential pitfall of the following spitbang? #!python -- https://mail.python.org/mailman/listinfo/python-list
