[katello-devel] Why #!/usr/bin/env ?

Eric Sammons esammons at redhat.com
Mon Jul 23 21:22:38 UTC 2012



----- Original Message -----
> On 23.7.2012 23:05, Eric Sammons wrote:
> >>> among developers. Then python can live in ~/myenv/bin/python as
> >>> >  >  well as
> >>> >  >  many dependencies under ~/myenv/lib/python2.X/site-packages
> >>> >  >  which
> >>> >  >  /usr/bin/python will never find, or worse, different
> >>> >  >  versions. I
> >>> >  >  imagine
> >>> >  >  something similar may exist in the ruby world.
> 
> And that ~/myenv/bin/python is python 2.4, 2.6, or 3.0? All of them
> behave *very* differently.
> 
> > Again wrt virtualenv, here is an example:
> >
> > $ virtualenv testme
> > $ cd testme
> > $ source bin/activate
> > $ which python
> > ~/testme/bin/python
> >
> > Note, if you were using /usr/bin/python you would_not_  be testing
> > the python binary in "testme".
> 
> That can be ok for quick'n'dirty code, where you want fast
> alternation
> without too much work. But who would do such thing in production?
> 
> Mirek

I actually do know IT shops that only run python code this way as it ensures that no stray libraries are in use or installed.  But yes primarily used for Dev and Test (I use only for test, honestly).  However, I still fall back to the use where shops actually do override the default $PATH to ensure they are using their in house compiled "GOLD" version of python.  

Many (many) customers feel that our interpreters are always behind and the versioning.release stuff confuses them so to be sure they are getting (for example) pure python-2.7 they will install python-2.7 into /usr/local/ and then change path to reference /usr/local/bin first.  Again, in this manner /usr/bin/python breaks.

--Eric
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
> 




More information about the katello-devel mailing list