Skip to content

Remove existing package before develop mode install #3875

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

Closed
wants to merge 1 commit into from

Conversation

ianw
Copy link
Contributor

@ianw ianw commented Jul 26, 2016

setuptools has changed its default behaviour whe installing packages
installed in "develop mode" (i.e. pip -e) from being inserted first in
sys.path to being added last (for details, see the bug).

This means that if "pip install -e" a git tree to work on something
but have the original package installed from PyPi (etc.), you will not
actually be importing the development version. During interactive
development you'll probably notice that your changes aren't applying
and start digging around, but this behaviour change could be very bad
in a CI situation where you think you've installed a development
version but really, with setuptools>=25, you're just testing the
release version.

This change removes an existing install before deploying in develop
mode. This way we only have one copy of the package and avoid
ordering issues. A new test is added.

Fixes #3874

setuptools has changed its default behaviour whe installing packages
installed in "develop mode" (i.e. pip -e) from being inserted first in
sys.path to being added last (for details, see the bug).

This means that if "pip install -e" a git tree to work on something
but have the original package installed from PyPi (etc.), you will not
actually be importing the development version.  During interactive
development you'll probably notice that your changes aren't applying
and start digging around, but this behaviour change could be very bad
in a CI situation where you *think* you've installed a development
version but really, with setuptools>=25, you're just testing the
release version.

This change removes an existing install before deploying in develop
mode.  This way we only have one copy of the package and avoid
ordering issues.  A new test is added.

Fixes pypa#3874
@ianw ianw force-pushed the upgrade-develop branch from 9b1f996 to 7255b61 Compare July 26, 2016 10:47
path = local_repo(
'git+http://github.com/pypa/pip-test-package.git',
tmpdir.join("cache"),
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather not have a network related test if we can avoid it.
You could use an existing module like https://github.com/pypa/pip/blob/6dc28c1/tests/data/src/singlemodule#L799-L805
Then:

  • install it via its path
  • install it via editable
  • check that pip freeze/list report it as editable
  • uninstall it
  • check that all installation disappeared

@xavfernandez
Copy link
Member

I don't like the approach used, I think we should stick with statisfied_by/conflicts_with logic, something akin to what was implemented in #1552.

@xavfernandez
Copy link
Member

cc @qwcode which reviewed #1552

@xavfernandez
Copy link
Member

Implemented in #3898

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Pip does not reinstall with latest setuptools
2 participants