Dangerous command-line incompatibility with pip

[raxod502]

User story

I have a Python package that I develop locally, ~/projects/foo. Previously, I installed it by pip install --user -e ~/projects/foo, where the -e is necessary in order to avoid reinstalling after every change. Now I want to modernize my Python package management, so I want to try pipx. Just to check that -e is supported, I check pipx install --help. I see that it is, so I run pipx install -e ~/projects/foo. But then I get this error:

'/Users/me/projects/foo' already seems to be installed. Not modifying existing installation in {str(venv_dir)!r}. Pass '--force' to force installation

I'm briefly very confused, but then figure that this message was supposed to be passed through str.format. I'm still quite confused, though, because this message doesn't explain anything about what the problem is. It seems like pipx thinks this package is installed. Just to check, I run pip list and confirm that it isn't. As suggested in the error message, I run pipx install --force -e ~/projects/foo. This deletes my project!! This is very upsetting, since nothing in the error message suggested this is what would happen. Also, it still doesn't work:

Installing to existing directory '/Users/me/projects/foo'
Could not find package /Users/me/projects/foo. Is the name correct?

After I restore my project from a backup, I look again at pipx install --help to see if I missed anything. I find this statement:

The argument to `--spec` is passed directly to `pip install`.

I am quite confused why the package name I give pipx wouldn't normally be passed to pip install. I don't see any explanation of what the alternative is. But nevertheless I try pipx install -e --spec ~/projects/foo. This gives me a usage error:

pipx install: error: the following arguments are required: package

None of this makes any sense to me given that pip install --user -e ~/projects/foo works just fine. But I figure maybe I need to provide a package name, and try pipx install -e --spec ~/projects/foo foo despite the redundancy. This churns away for a while, and spits out:

No binaries associated with package foo.

Which is patently false. At this point I find #108 and #126 which seem to indicate that --editable isn't really supported. I still don't really understand what's going on, though.

It seems like pipx can't install my package, so I instead create a virtualenv manually and symlink the installed script into ~/.local/bin.

---

I hope that my recounting of this experience may suggest some changes to the pipx interface or documentation which could avoid such unintuitive, frustrating, and arguably dangerous behavior.

[cs01]

So sorry to hear that it deleted your project! I have never heard of this happening before. I will definitely read everything over and make changes if necessary. One other thing that may help is to run with the --verbose flag.

In the mean time I would suggest using virtual environments for development. https://packaging.python.org/guides/installing-using-pip-and-virtual-environments/

[ghost]

So sorry to hear that it deleted your project! I have never heard of this happening before.

This issue may be related to #137 since that also unexpectedly deleted packages.

[cs01]

@apnewberry thanks for pointing that out. I will get this fixed ASAP.

[cs01]

This deletes my project

This has been fixed in 0.13.1.0

this message was supposed to be passed through str.format

This has been fixed as well.

None of this makes any sense to me given that pip install --user -e ~/projects/foo works just fine.

I could possibly modify pipx to use pip to determine the package name, but right now pipx requires the user to specify the package name.

Which is patently false. At this point I find #108 and #126 which seem to indicate that --editable isn't really supported. I still don't really understand what's going on, though.

If you re-run with the --verbose flag and share the output I might be able to help diagnose. Also make sure there are no egg or egg-info files present.

[cs01]

I am going to close this issue since the removal of existing venvs has been fixed. For the other problem, feel free to open a new issue and add verbose output.

[raxod502]

@cs01 Thanks, see #148 for the editable install problem.