-
Notifications
You must be signed in to change notification settings - Fork 430
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
issue with pipx dependency conflicting with package dependency, Click #233
Comments
I got around the issue temporarily by force installing it into the virtualenv: |
I just ran |
@cs01 yes, it does not occur with pipx installed via pip. however, I'm not sure its entirely a homebrew issue going back to the homebrew installed version, here are some debug details:
As you can see, pipx is running If I manually run,
As you can see, manually running I think this is a pipx issue, not a homebrew issue @cs01 |
@cs01, I figured it out. The way the homebrew formula works is by manipulating the PYTHONPATH: https://github.com/Homebrew/homebrew-core/blob/master/Formula/pipx.rb#L47 Homebrew python packages can work in two ways: 1) using a proper virtualenv and 2) using a global vanilla python where the PYTHONPATH variable points it to the packages it needs. because of the nature of pipx, we use the second I believe the correct solution will be to explicitly unset the PYTHONPATH within pipx |
as a quick proof of concept, this patch fixes the issue: diff --git a/pipx/util.py b/pipx/util.py
index 94732d8..ba27eee 100644
--- a/pipx/util.py
+++ b/pipx/util.py
@@ -93,11 +93,12 @@ def get_site_packages(python: Path) -> Path:
def run(cmd: Sequence[Union[str, Path]], check=True) -> int:
"""Run arbitrary command as subprocess"""
+ env = {k:v for k,v in os.environ.items() if k != 'PYTHONPATH'}
cmd_str = " ".join(str(c) for c in cmd)
logging.info(f"running {cmd_str}")
# windows cannot take Path objects, only strings
cmd_str_list = [str(c) for c in cmd]
- returncode = subprocess.run(cmd_str_list).returncode
+ returncode = subprocess.run(cmd_str_list, env=env).returncode
if check and returncode:
raise PipxError(f"{cmd_str!r} failed")
return returncode |
Same issue here:
Pipx believes click is already installed, but it's pipx's click, not my tools' click. INFO: my pipx is from brew.
|
@AlJohri any quickfix? |
@cs01 what do you think of my proposed fix? |
It looks fine to me. If you make the change in a PR and the unit tests still pass then I will merge it. |
ping @AlJohri ... your proposed change passes the existing unittests ... submit a PR? It would be great if we could also have a test which demonstrates the problem and shows that it is fixed. |
Will do
On Wed, Oct 23, 2019 at 2:14 AM John Vandenberg ***@***.***> wrote:
ping @AlJohri <https://github.com/AlJohri> ... your proposed change
passes the existing unittests ... submit a PR?
It would be great if we could also have a test which demonstrates the
problem and shows that it is fixed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#233>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAVJFTFFPHATENHMOATTMEDQP7TUFANCNFSM4I7A5EPA>
.
--
- Al
|
I'm running into an issue with the
clokta
package. It depends onClick
. It seems like it is pipx thinks it is already installed because Click is a dependency ofpipx
itself.This is installed via the latest homebrew release.
The text was updated successfully, but these errors were encountered: