-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get rid of which dependency in system_which #2882
Comments
I agree that we shouldn't use which, but we actually have a reimplementation of this in For the second element:
It's not quite this simple just because when the user has multiple versions of python 3, we prefer the highest stable release (and I think this is actually implemented using import pythonfinder
finder = pythonfinder.Finder(allow_global=True, system=False) # allow global searching, use system python i.e. sys.executable
command_path = finder.which("some_command") You should probably verify that this is actually how it works, I am going to cut a release of pythonfinder soon so it'd be good to double check :) Would absolutely accept a PR on this though, because yeah, definitely agree that the current approach isn't the best |
I didn’t check PythonFinder’s implementation, but the implementation provided in the top post does not work on all platforms. Windows, for example, allows you to omit extensions listed in |
(That was why I mentioned the pythonfinder implementation, which doesn't use the code from the original recommendation but instead uses an OS and platform agnostic approach) |
Some inspiration could be borrowed from |
Also (I learnt this only during last week) there is a backport for |
this isn't the first time someone mentioned |
Oh I didn't know |
I'm encountering this warning when using the new AWS Lambda distributable for Python. |
Encountering the same problem here as well. What's the solution? |
This should be solved as we no longer use which from vistir or the pipenv which. shutil.which is now used. |
Issue description
In many minimal system installations (container distributions, etc., see #2277) the non-standard command
which
is not available by default. Butpipenv
currently requires this in order to find python and other tools. One could say, that this is a packager fail, but I think, the requirements for pipenv should be minimal and there are many other ways to find executables apart fromwhich
.Expected result
pipenv should work in most plank standard container images out of the box.
Actual result
Pipenv fails and you have to specify the python executable with
--python
argument.Steps to replicate
Ideas to solve it
which
,command -v
is more standard and available in most shells--three
is given andsys.version_info.major == 3
, you could just usesys.executable
. The same applies for--two
and so on.$ pipenv --support
This is from a `fedora:29` beta docker image, as pipenv in `fedora:28` has no `--support` argument. The same issue is present on fedora 29 as well.Pipenv version:
'2018.7.1'
Pipenv location:
'/usr/lib/python3.7/site-packages/pipenv'
Python location:
'/usr/bin/python3'
Other Python installations in
PATH
:Warning: the which -a system utility is required for Pipenv to find Python installations properly.
Please install it.
[...]
PEP 508 Information:
System environment variables:
LANG
HOSTNAME
PWD
HOME
FBR
DISTTAG
FGC
TERM
SHLVL
PATH
_
PYTHONDONTWRITEBYTECODE
PIP_PYTHON_PATH
Pipenv–specific environment variables:
Debug–specific environment variables:
PATH
:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG
:en_US.UTF-8
PWD
:/
Contents of
Pipfile
('/Pipfile'):The text was updated successfully, but these errors were encountered: