On 21Jul2019 08:14, Chris Angelico <ros...@gmail.com> wrote:
On Sun, Jul 21, 2019 at 5:26 AM Tim Daneliuk <i...@tundraware.com> 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.
A quick grep through my $PATH shows that there are a number of
executable Python scripts there, including add-apt-repository,
calibre, some lilypond stuff, trash-can management, samba-tool, iotop,
and youtube-dl. If I have a venv active with, say, Python 3.9, then
`/usr/bin/env python` is going to point to Python 3.9. What are the
odds that all those scripts will work with Python 3.9 with no
libraries installed? Why should typing "youtube-dl B7xai5u_tnk" be
affected by a virtual environment, when typing "man youtube-dl"
wouldn't be?? Using env for everything is a terrible idea and one that
will basically make virtual environments useless.
I'm with Tim Daneliuk. The environment matters and should be honoured
except in extremely weird cases.
If you require a specific outcoming, set a specific environment. It is
under your control. Control it.
For your specific example, "man youtube-dl" _is_ affected by the
environment. It honours the $MANPATH variable.
For Peter J. Holzer, if we must play the "I've been doing this forever"
game: I've been sysadmining etc longer than your 25 years and disagree
with you. If your tools are strongly affected by version, run them with
an environment that finds the right version.
Installers, particularly those run as root or in other low level setup
situations, should have a WELL DEFINED environment.
If you have a tool that isn't portable, put it in a wrapper that coddles
its behaviour.
Cheers,
Cameron Simpson <c...@cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list
