uninstall -nspkg.pth files installed with setup.py develop #4176

jaraco · 2016-12-11T23:50:46Z

With the release of setuptools 31, setup.py develop finally should work with namespace packages. However, it's my understanding that currently when one uninstalls using pip, pip doesn't remove the -nspkg.pth file created. It probably should do so.

The text was updated successfully, but these errors were encountered:

dstufft · 2017-03-30T20:37:52Z

Is this file named after the package being uninstalled?

jaraco · 2017-03-30T22:43:18Z

I don't understand the question. Was it answered due to the example in #4213?

dstufft · 2017-03-31T13:34:04Z

Yea sorry.

pradyunsg · 2017-10-06T17:07:48Z

#4576 has a test for this.

pfmoore · 2017-10-20T08:22:53Z

Is anyone working on a fix for this? If not, does it need to remain a release blocker?

pradyunsg · 2017-10-20T08:27:46Z

Well, I tagged it as a release blocker but I really don't know if it's definitely one.

I just wanted to make sure that someone takes a look at this before making the release and determine if this needs to be or not and @dstufft said doing this would be fine. :)

sbidoul · 2017-10-20T08:41:14Z

I can attest the error message is very confusing when such a .pth file is left behind after uninstall. I can't say if it qualifies as a release blocker though.

pfmoore · 2017-10-20T09:12:04Z

As it's a new problem introduced by changes in setuptools, I think fixing it is important. I don't understand the details, but I guess the problem is that setuptools isn't properly putting the information in the RECORD file and that's why pip isn't aware of it.

So I don't understand why this isn't simply a setuptools bug that the file is missing from RECORD. Maybe because as a namespace package, the file is deemed to be "shared" somehow? In which case there's a design question which need to be thought through (how do we record files that are shared between multiple packages). Although there may well be a tactical fix that pip can make to special-case the situation.

I'm happy to consider this as "high priority", but if no-one is willing to step up and offer a fix, I don't think we should block pip 10 on it (after all, setuptools didn't make it a release blocker at their end :-P)

sbidoul · 2017-10-20T09:19:11Z

It is not a shared file. @jaraco can probably comment on why it's reported here and not in setuptools.

pradyunsg · 2017-10-20T09:43:14Z

I'm happy to consider this as "high priority", but if no-one is willing to step up and offer a fix, I don't think we should block pip 10 on it

I have the same position but I don't think I mentioned it anywhere.

pradyunsg · 2017-10-22T16:32:19Z

Dropping release blocker status based on the above discussion. :)

jaraco · 2017-10-25T14:08:24Z

I guess the problem is that setuptools isn't properly putting the information in the RECORD file and that's why pip isn't aware of it

Interesting. I didn't think RECORD was used for develop installed packages. I can investigate, but I had assumed there was an implicit contract between setuptools and pip for editable packages.

pfmoore · 2017-10-25T14:12:47Z

I wasn't aware of anything specific for editable packages, but I'm equally working on assumption here...

pfmoore · 2017-10-25T14:16:16Z

Looks like there is a special case for editable installs. https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_uninstall.py#L358

Thanks for the pointer - so this needs fixing at the pip end, I guess.

pfmoore · 2018-03-26T14:00:19Z

In the absence of a PR for this, it'll probably get deferred until after pip 10.

ida · 2018-04-13T12:00:49Z

FTR, found a file named [EGG_NAME]-[EGG_VS]-py[PY_VS]-nspkg.pth in an egg installed with buildout.

pradyunsg · 2018-07-06T21:47:13Z

Pushing this down the road to the next release since I don't think this'd happen in time for 18.0.

pradyunsg · 2018-09-18T13:19:26Z

Pushing this down the road since I don't think this'd happen in time for 18.1.

pfmoore · 2018-09-18T13:30:56Z

Process note - I'm not sure it's worth putting things into release milestones - it creates an expectation that we're hoping to release things in a particular version, whereas in fact calver means that we'll release with whatever's in master, regardless of what's sitting in any "release XX.Y" milestone. Dropping the milestones would save a certain amount of unnecessary admin, as well as avoiding the impression that things are "slipping".

pradyunsg · 2018-09-18T14:47:50Z

Agreed. I realized that and I already stopped doing it. :)

blueyed · 2020-02-26T21:08:26Z

I've created #7795 which might solve it, but have done it for manually created "RECORD" files in the first place (via a custom "develop" setuptools command).

blueyed · 2020-02-26T21:34:23Z

It does not look like setuptools creates a RECORD file for the namespace-pth files though: https://github.com/pypa/setuptools/blob/e84f616a6507ec9115fad68b221cbf5333d9d2d9/setuptools/namespaces.py#L15-L31, but removes them with develop -u (https://github.com/pypa/setuptools/blob/e84f616a6507ec9115fad68b221cbf5333d9d2d9/setuptools/command/develop.py#L32-L39).

Shouldn't pip maybe just run the develop -u command in the first place, which would take of removing the develop_egg_link itself then also.
(Using RECORD (#7795) allows for showing what would be removed though, so it could still be done regardless, and setuptools could also add the namespace-pth files there then).

But given the "dynamic" nature of the "develop" command it seems to make sense also calling it for uninstallation, which is important for custom / extended versions of it in particular: currently pip just assumes what setuptools is doing there for its uninstallation.
If there are plans to not call the "develop" command for installation (since it is called "legacy" internally already) this might be void, but as things currently stand I think "develop -u" should be called then also.

This allows for pip to uninstall any custom files, e.g. being created with a custom "develop" setuptools command, where a `RECORD` file is created manually: with open(os.path.join(self.dist.egg_info, "RECORD"), "w") as fp: fp.write("{},,".format(custom_fname)) It might also help with uninstalling -nspkg.pth files (pypa#4176), but have not investigated/tested this.

chrahunt · 2020-02-27T03:55:01Z

Personally I like the idea of calling develop -u a lot - I'm surprised we don't already do this.

xavfernandez · 2020-03-05T13:15:53Z

Using develop -u would mean that pip would need setuptools to uninstall things which seems wrong to me: what if setuptools was already uninstalled ? Should pip reinstall setuptools in a temporary environment to uninstall things ?

chrahunt · 2020-03-06T01:44:45Z

You're right, that doesn't sound like as good an idea anymore. Those kinds of complications and edge cases are things that would have to be sorted out as part of a standardized editable install proposal. I'm tempted to say let's not try to figure them out here and instead if this gets implemented just do the straightforward thing and implement the logic in pip.

dstufft added this to the 10.0 milestone Mar 30, 2017

dstufft mentioned this issue Mar 30, 2017

pip uninstall does not remove *-nspkg.pth for packages installed in editable mode #4213

Closed

xavfernandez added the project: setuptools Related to setuptools label Mar 30, 2017

pradyunsg self-assigned this Jun 27, 2017

pradyunsg added the type: bug A confirmed bug or unintended behavior label Jun 27, 2017

pradyunsg mentioned this issue Jun 27, 2017

[WIP] Handle editable namespace packages properly #4576

Closed

pradyunsg added the !release blocker Hold a release until this is resolved label Oct 6, 2017

pradyunsg removed their assignment Oct 6, 2017

pradyunsg removed the !release blocker Hold a release until this is resolved label Oct 22, 2017

pradyunsg mentioned this issue Mar 30, 2018

Plan for 10.0 #4981

Closed

dstufft modified the milestones: 10.0, 10.1 Mar 31, 2018

pradyunsg removed this from the 18.0 milestone Jul 6, 2018

pradyunsg added this to the 18.1 milestone Jul 6, 2018

pradyunsg removed this from the 18.1 milestone Sep 18, 2018

blueyed mentioned this issue Feb 26, 2020

[RFC/WIP] Use uninstallation paths from RECORD with editable installs #7795

Closed

1 task

abn mentioned this issue Mar 28, 2020

pip installer breaks environment on vcs namespace package removal python-poetry/poetry#2238

Closed

3 tasks

uninstall -nspkg.pth files installed with setup.py develop #4176

uninstall -nspkg.pth files installed with setup.py develop #4176

Comments

jaraco commented Dec 11, 2016

dstufft commented Mar 30, 2017

Uh oh!

jaraco commented Mar 30, 2017

Uh oh!

dstufft commented Mar 31, 2017

Uh oh!

pradyunsg commented Oct 6, 2017

Uh oh!

pfmoore commented Oct 20, 2017

Uh oh!

pradyunsg commented Oct 20, 2017

Uh oh!

sbidoul commented Oct 20, 2017

Uh oh!

pfmoore commented Oct 20, 2017

Uh oh!

sbidoul commented Oct 20, 2017

Uh oh!

pradyunsg commented Oct 20, 2017

Uh oh!

pradyunsg commented Oct 22, 2017

Uh oh!

jaraco commented Oct 25, 2017

Uh oh!

pfmoore commented Oct 25, 2017

Uh oh!

pfmoore commented Oct 25, 2017

Uh oh!

pfmoore commented Mar 26, 2018

Uh oh!

ida commented Apr 13, 2018

Uh oh!

pradyunsg commented Jul 6, 2018

Uh oh!

pradyunsg commented Sep 18, 2018

Uh oh!

pfmoore commented Sep 18, 2018

Uh oh!

pradyunsg commented Sep 18, 2018

Uh oh!

blueyed commented Feb 26, 2020

Uh oh!

blueyed commented Feb 26, 2020

Uh oh!

chrahunt commented Feb 27, 2020

Uh oh!

xavfernandez commented Mar 5, 2020

Uh oh!

chrahunt commented Mar 6, 2020

Uh oh!