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

pip install --user -e tries to uninstall system-wide version, unlike pip install --user #4296

Open
anntzer opened this issue Feb 21, 2017 · 6 comments
Labels
C: user scheme Handling of packages in user-specific directories type: bug A confirmed bug or unintended behavior

Comments

@anntzer
Copy link
Contributor

anntzer commented Feb 21, 2017

  • Pip version: 9.0.1
  • Python version: 3.6
  • Operating system: Arch Linux

Description:

Tried to install pylint in user, editable mode. Failed as pip tries to uninstall the system-wide version.
While this could be a reasonable behavior, this is inconsistent with non-editable installs, which do NOT attempt to remove the system-wide version

What I've run:

$ pip install --user -e . # from pylint source directory, fails with permission error
$ pip install --user . # works, doesn't try to remove syswide install
@piotr-dobrogost
Copy link

piotr-dobrogost commented Feb 21, 2017

this is inconsistent with non-editable installs

Did you mean to say with non --user here?

I guess using --user with --editable is something almost no one does as most people install editable packages in virtualenvs I guess.

Funny, there's no editable label.

@anntzer
Copy link
Contributor Author

anntzer commented Feb 21, 2017

Sorry, I meant with non-editable, user installs. The example code was incorrect, I changed it.

@anntzer anntzer changed the title pip install --user -e tries to uninstall system-wide version, unlike pip install -e pip install --user -e tries to uninstall system-wide version, unlike pip install --user Feb 21, 2017
@pradyunsg
Copy link
Member

Relevant here: #4575

@pradyunsg pradyunsg added type: bug A confirmed bug or unintended behavior C: user scheme Handling of packages in user-specific directories labels Mar 5, 2018
@ppham27
Copy link

ppham27 commented May 21, 2019

As a workaround, it works to do pip install --user . && pip install --user -e . to hack pip into just overwriting the user version. To make this even quicker, I just copy over the *.dist-info folder.

@ssbarnea
Copy link
Contributor

ssbarnea commented Nov 10, 2021

@ppham27 I am not sure if that workaround no longer works in general but for packages that dropped setup.py it clearly does not work. In fact I see quite weird logs considering that my package fully switched to pyproject.toml and dropped setup.py file.

See https://gist.github.com/ssbarnea/d74648c926efc991999d227d2c379981

The irony is that while it fails, pip freeze reports the install as molecule @ file:///home/ssbarnea/c/molecule which looks bit like an editable.

@iuriguilherme
Copy link

iuriguilherme commented Jun 7, 2022

I see the same behaviour even with a minimal setup.py file (the import setuptools; setuptools.setup() one).

Workaround is forcing virtual environment and running pip install -e . - the setup.cfg would need to duplicate requirements.txt or equivalent with it's own install_requires =, but that's probably already done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: user scheme Handling of packages in user-specific directories type: bug A confirmed bug or unintended behavior
Projects
None yet
Development

No branches or pull requests

6 participants