Skip to content
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

pipx uninject removes apps made available when first creating the virtual environment if a dependency provides the same app #1366

Open
doolio opened this issue Apr 23, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@doolio
Copy link

doolio commented Apr 23, 2024

Running pipx version1.4.3.

Describe the bug

When uninjecting a package from another installed packages virtual environment the package is removed as expected but any apps that were exposed when creating the virtual environment into which you injected the package are also removed if a dependency provides the same app yet pipx list suggests they are still available. Noted this behaviour just after submitting #1364.

How to reproduce

  1. Install a package e.g. pipx install python-lsp-server creating its isolated venv
  2. pipx list shows:
   package python-lsp-server 1.11.0, installed using Python 3.12.2
    - pylsp
  1. Inject a package into the venv created for the package installed in step 1
    e.g. pipx inject python-lsp-server python-lsp-ruff

  2. pipx list --include-injected shows:

   package python-lsp-server 1.11.0, installed using Python 3.12.2
    - pylsp
    Injected Packages:
      - python-lsp-ruff 2.2.0
  1. Uninject the package injected in step 3 with pipx uninject python-lsp-server python-lsp-ruff. I noticed too that some of the dependent packages of the injected package remain in the pipx venv when the injected package is uninjected. I would have expected all of its dependent packages to be removed with it but maybe this behaviour is expected as it is the same with pip if I'm not mistaken (just a beginner).

  2. pipx list --include-injected shows the same as in step 2:

  package python-lsp-server 1.11.0, installed using Python 3.12.2
    - pylsp

Notice, pylsp is still listed as exposed but it is not.

  1. which pylsp gives bash: type: pylsp: not found and ~/.local/bin shows:

image

and the venv directory also confirms it is no longer present:

image

All this suggests the behaviour of pipx uninject is more serious than raised in #1364.

Expected behavior

Pipx uninject should not touch apps exposed by the virtual environment into which you previously injected.

@dukecat0 dukecat0 added the bug Something isn't working label Apr 25, 2024
@doolio
Copy link
Author

doolio commented Apr 26, 2024

To shed some more light on this behaviour. The python-lsp-server package exposes the pylsp app. The python-lsp-ruff package exposes no apps but its dependent packages python-lsp-server and ruff expose the pylsp and ruff apps respectively. So it seems if I uninject python-lsp-ruff from the python-lsp-server venv it removes the pylsp app because it thinks it is the pylsp app of its dependent package python-lsp-server despite not exposing it with the --include-deps option.

In such cases, I think it would be best if one could do something like the following:

$ pipx install python-lsp-server  # exposing the pylsp app
$ pipx inject --include-deps=ruff python-lsp-server python-lsp-ruff  # exposing the ruff app only
$ pipx uninject --include-deps=ruff python-lsp-server python-lsp-ruff  # removing the ruff app only

Ideally, --include-deps could take a list of apps in case the injected package has more than one dependency with an app that we wish to expose and/or remove. Or except a regex to exclude a specific app.

@chrysle
Copy link
Contributor

chrysle commented Apr 26, 2024

I'm definitely in favour of selecting the dependency apps to include.

@doolio doolio changed the title pipx uninject removes apps made available when first creating the virtual environment pipx uninject removes apps made available when first creating the virtual environment if a dependency provides the same app Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants