Proper shebang for python3

[Brian Oney]

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