pipx
pipx copied to clipboard
Extending PATH variable instead of symlinking executables
Idea: add option/flag for creating wrapper script which extends PATH environment variable with bin/ folder inside virtual environment.
How would this feature be useful?
This would avoid PATH pollution and possible name conflicts with extra executables. Some command use different command but only internally. Also, user might not want to have bunch of extra executables in PATH instead of just one.
Describe the solution you'd like
When specifying special flag (i.e. --wrap), there would be only one script exposed in PIPX_BIN_DIR. Other executables are not linked outside of virtual environment. The only exposed executable would not be symlinked to executable in virtual environment. Instead, pipx would create a wrapper script with the same name of following contents:
#!/usr/bin/env sh
PATH="${PATH}:${PIPX_HOME}/venvs/<name>/bin" ${PIPX_HOME}/venvs/<name>/bin/<name>
with <name> replace by name of installed application.
That way, only one executable is exposed on PATH and application can still function properly when using other executables.
Of course this script example is written in POSIX-compliant shell, but it would be possible (and even more portable) to use Python. It's just an example.
Describe alternatives you've considered
Living with bunch of extra executables showing in PATH which I did not intend to use at all - possible but frustrating.
-1 from me. It is pretty simple to build a wrapper around pipx for this if you want to, there’s no need for pipx to support this explicitly.
IIRC there are all kinds of executables in the bin directory of the venv that are not the app itself, so this will not work. Things like pip, python, and all executables included in dependent packages.
Hi, I'd like to add a case that would probably benefit from this.
I tried installing virtualenvwrapper via pipx to see if that'd work. The main 'app' for it is a shell script that you need to source into your shell (virtualenvwrapper.sh or its lazy cousin). The script gets installed correctly in PIPX_BIN_DIR but sourcing it will fail with:
/usr/bin/python: No module named virtualenvwrapper
Checking the source shows this at the start of the script:
if [ "${VIRTUALENVWRAPPER_PYTHON:-}" = "" ]
then
VIRTUALENVWRAPPER_PYTHON="$(command \which python)"
fi
which is the Python executable it'll use. This will resolve to the system python (or whichever one is first in your $PATH) but not the one in the pipx virtualenv, so it can't find the virtualenvwrapper module (which is properly installed inside the pipx virtualenv).
If the virtualenv's bin/ dir would be added to the start of $PATH this would probably work as expected, as it'd resolve to the virtualenv's python. Though I'm not sure if it's a good idea to do so (nor if it's a good idea to use/support using virtualenvwrapper like this at all, though I'd expect there to be more tools/scripts with similar issues). At least this specific issue can be worked around but it'd be nicer not to have to IMO :)
Edit: and to further complicate this case, as these scripts get sourced a simple PATH="..." /path/to/script won't suffice for this case, it needs to be something like PATH="..." . /path/to/script (added . in between for sourcing), but only in cases where the script needs to be sourced.
-1 from me. It is pretty simple to build a wrapper around pipx for this if you want to, there’s no need for pipx to support this explicitly.