reinstall is destructive when misused with local source directory

[jayqi]

pipx version 1.5.0

Describe the bug

I have a package installed with pipx, and I wanted to reinstall it from a local source repository. I ran

pipx reinstall {absolute-path-to-repo}

thinking that it would do something equivalent to

pipx install {absolute-path-to-repo} --force

Instead, it deleted the file tree at {absolute-path-to-repo}.

From this experience, I have inferred that I have misunderstood the intended functionality and arguments of the reinstall command. (I'm inferring that reinstall accepts a path to a package's pipx virtual environment, rather than a path to package source.) However, I feel like this is an easy mistake to make, and the destructive side effect of this performing this action seems really bad. I did in fact lose some work that was only in my local git repository.

How to reproduce

1. Create any directory

   mkdir testdir

2. Run pipx reinstall with an absolute path to that directory

   pipx reinstall $(pwd)/testdir

   This produces output

   uninstalled testdir! ✨ 🌟 ✨
   Fatal error from pip prevented installation. Full pip output in file:
       /Users/jqi/.local/pipx/logs/cmd_2024-04-05_19.03.13_pip_errors.log
   
   Some possibly relevant errors from pip install:
       ERROR: Could not find a version that satisfies the requirement testdir (from versions: none)
       ERROR: No matching distribution found for testdir
   
   Error installing testdir.
   

   with the side effect of deleting testdir/.

Expected behavior

pipx reinstall should not accept a local file path as an argument to prevent misuse. Or if this is actually desired functionality, there should more checks in place to ensure that it is intentional and actually a path to a pipx virtual environment.

[chrysle]

From this experience, I have inferred that I have misunderstood the intended functionality and arguments of the reinstall command. (I'm inferring that reinstall accepts a path to a package's pipx virtual environment, rather than a path to package source.)

Not actually a path, but the name of a pipx-installed package from which a corresponding venv directory name is created.
Thus it's interesting that passing in an absolute path does this. I couldn't reproduce this with a relative path. There must be some issue with this function when you pass an absolute path:

pipx/src/pipx/venv.py

Line 76 in 9ae4134

def get_venv_dir(self, package_name: str) -> Path:

Let me reproduce this further.

However, I feel like this is an easy mistake to make, and the destructive side effect of this performing this action seems really bad. I did in fact lose some work that was only in my local git repository.

Sorry to hear that.

[chrysle]

@jayqi I've opened #1329 for a fix. Would that work for you?

[mosbasik]

Ohhhhhh man!

Goodbye not-pushed-anywhere year-old repo. Recovered three files that were open in my editor when I ran the command. That's a gut punch. I'm used to thinking "even if i accidentally delete files, git has my back" - not when the whole repo goes. Guess I've been around the block enough to know that if there's not a copy on another computer, it's not safe.

Agreed with OP about misconstruing the purpose of the reinstall command - but it was actually a message from pipx that made me try it:

I'd somehow installed my app using the wrong Python, so I was trying to fix it with install --force --python. The output said "ok, we'll reinstall it cause you said --force but not with the python you asked for; to change the python you have use reinstall like this:

$ pipx install --editable ~/contributions/linear-terminal-clock  --force  --python $(pyenv which python)
--python is ignored when --force is passed. If you want to reinstall linear-terminal-clock with
/home/phenry/.pyenv/versions/3.9.17/bin/python, run `pipx reinstall /home/phenry/contributions/linear-terminal-clock
--python /home/phenry/.pyenv/versions/3.9.17/bin/python` instead.

So first I tried

$ pipx reinstall --editable ~/contributions/linear-terminal-clock --python $(pyenv which python)
[snipped]
pipx: error: unrecognized arguments: --editable

so I dropped the --editable:

$ pipx reinstall ~/contributions/linear-terminal-clock --python $(pyenv which python)

and that's all she wrote!

I haven't fully digested #1329 because I'm still kind of preoccupied with data recovery, but I think it makes it an error to call reinstall with a path (absolute or relative). If so the message that led me astray probably needs some adjusting to ensure it doesn't recommend calling reinstall with a path. It would be even better if it recommended the correct thing to do when there's a path (what would that be? Just uninstall followed by install --python?)