On 7/20/19 1:20 PM, Chris Angelico wrote: > On Sun, Jul 21, 2019 at 4:13 AM Michael Speer <knome...@gmail.com> wrote: >> >> You may want to use `#!/usr/bin/env python3` instead. >> >> There is a concept in python called the virtual environment. This used to >> be done with a tool called virtualenv in python2, and is now done mainly >> through a venv module in python3. >> >> A virtual environment goes into a directory of your choosing and will have >> its own python3 executable, and pip3 executable, and when you add >> dependencies, they are also placed into the directory structure under your >> chosen directory. >> >> When you do a `. <directory>/bin/activate` the included source will places >> the virtual environment's bin/ folder at the beginning of your PATH >> environment variable, making it the default python3 when you type it >> without a full path. >> >> This allows you to run scripts that need different, or even conflicting, >> sets of dependencies without bothering with the underlying linux >> distribution's python installation's modules. >> >> If you use `#!/usr/bin/python3`, it will always use exactly the system >> version that is installed, and the system's installed modules. >> >> Your scripts will still default to the system installation if a virtual >> environment is not activated. So you lose nothing by doing it this way, but >> gain a little control from it. >> > > ONLY if you actually want this script to behave differently inside a > venv. When you're setting a shebang on a script, you often do not want > that. You potentially LOSE a lot of control. > > ChrisA
Disagree strongly. The environment should always define where you want to find key binaries, whether in a venv or not. There are many use cases where you want to override system binaries. For example, you may be running on an older OS release and want to point to a newer one installed elsewhere. Similarly, the DevOps workflow may demand particular configurations for the pipelines to run properly. I have spent way too much time in my career trying to undo this kind of imperious programming that thinks the coder knows best, when in the actual runtime environment, they actually don't. Most recently, I have been working to produce a configuration for linuxbrew that can be installed by an unprivileged user at any location they like. It is maddening to spend hours getting things working only to find out that some genius decided that the only version of, say, perl or autoconf, is to be found exclusively in /usr/bin. 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... Grrrrrrrrrr...... -- https://mail.python.org/mailman/listinfo/python-list
