Cannot uninstall pew from pip --user install

[lofidevops]

Steps to reproduce:

• pip install --user setuptools [1]
• pip install --user pew
• pip uninstall pew

What should happen:

pew is installed then uninstalled.

What happens instead:

pew is installed. When attempting uninstallation:

Can't uninstall 'pew'. No files were found to uninstall.

Notes:

• This also prevents upgrade attempts but I can't reproduce this at the moment.
• This procedure works with other Python packages (e.g. youtube-dl)
• This procedure works in a virtualenv.

Footnotes:

[1] This is required for the installation to work, otherwise pew complains that it requires setuptools and aborts the installation attempt, even if setuptools is already installed via apt. I don't think this is a bug (but I'm not sure), probably required so pew can detect setuptools in its "environment" or it requires a newer version of setuptools than what is currently in the Ubuntu repos.

Workaround:

Manually delete files listed in .local/lib/python2.7/site-packages/pew-0.1.12-py2.7.egg-info/installed-files.txt

[lofidevops]

FYI I am installing this way because pew is not in the Ubuntu repos (yet) so I can't do a system install, and sudo pip install is discouraged.

[ryanhiebert]

I don't have a reference for it, but I think that this is a bug in pip with the --user option. Though generally discouraged, I prefer to install pew globally.

[ryanhiebert]

Hmm. I'm on a Mac, using pip 1.5.6 for Python 3.4 from MacPorts, and it works for me. I'll have to set up an Ubuntu VM to try and track this down. Are you on Ubuntu 14.10?

[lofidevops]

Thanks for the feedback. I'm on Ubuntu 14.04 LTS using pip 1.5.4 (as packaged in Ubuntu repo).

[berdario]

Just a drive-by comment: I'm trying to create a deb package, but I just realized that I'd need to repackage virtualenv-clone (debian/ubuntu only supplies a virtualenv-clone for python2... and using python2 by itself wouldn't be much better, since we now depend on a backported pathlib which would need to be packaged as well)

[ryanhiebert]

@kwill , thanks for investigating and finding some other packages with the same issues. I'll try to follow that issue. If I have some time (I thought I would have already by now), I'll set up a VM and replicate the issue on my machine.

@berdario : the default python for Jessie will be 2.7, so heading down the road of packaging pathlib seems likely to be the better route over forward porting virtualenvclone. At least, it seems saner to me.

[berdario]

Good news everyone!

I managed to package it, and make it available here as a PPA

Unfortunately, we can't have a nightly PPA automatically build new versions due to this bug, and due to the crumminess of the debian build tools, I won't guarantee at all that these packages will be kept updated, unless someone else is willing to help.

The PPA already belongs to a group, so I can easily add someone else. Once added you just need to add your GPG key on Launchpad, and you can then try to build it again. the steps for (python3-)virtualenv-clone (in the unlikely case it'll need to be updated) are:

bzr branch lp:~pew-maintainers/virtualenv-clone/python3-virtualenv-clone
bzr export ../virtualenv-clone_0.2.7.orig.tar.gz
debuild -kYOUR_GPG_KEY_ID

instead of bzr export + debuild you should be able to use bzr-buildpackage

bzr-buildpackage -- -kYOUR_GPG_KEY_ID

but this is quite flaky and fails on me

this will generate a .deb in the parent folder, and you will need to specify the correct version (if you'll use the bzr-export command)... it might be better to add a suffix to the package name to avoid potential conflicts. I didn't bother do to it earlier, but given the fact that virtualenv-clone is in maintentenance mode, this shouldn't be an issue.

the -k flag is needed because otherwise if you have more than 1 GPG key the build will fail.

Once you've checked that the .deb has been built correctly, you can build the source package with:

bzr export ../virtualenv-clone_0.2.7.orig.tar.gz
debuild -S -kYOUR_GPG_KEY_ID

or

bzr-buildpackage -S -- -kYOUR_GPG_KEY_ID

and then upload it with (remember to specify the correct version):

dput ppa:pew-maintainers/ppa ../virtualenv-clone_0.2.7-1_source.changes

for pew itself:

git-buildpackage --git-ignore-new --git-upstream-tree=master -kYOUR_GPG_KEY_ID

(as usual, add -S to build the source package)

Also, apparently, there's no easy way to make the package available for multiple "series" (ubuntu versions), instead you have to manually copy (from the launchpad UI) the packages to a different series. Currently I've done it for Trusty and Utopic... let me know if you want them copied for another one.

As I was mentioning, this uses Python3 since it required the least effort. I just checked and Debian Jessie will have Python3.4 in its repositories, so I wouldn't sweat it

[ryanhiebert]

Sounds good! Thanks for getting the .deb made, I think it will open up new possibilities for using pew.

[berdario]

I've done plenty of tests, and this bug doesn't happen with a pip3 install --user /path/to/pew

I moved to Wheels, which is nice, but apparently the issue still happens on Python3 (but not on Python2, weirdly)... hence the "sort of Fixes"

[lofidevops]

Confirmed as working for me with Python 2.7 (after manually uninstalling 0.1.12 I can install/uninstall 0.1.13 using pip --user install and pip uninstall). Many thanks! Next stop the PPA :)

[lofidevops]

Also confirmed pip --user -U install pew worked for 0.1.13 to 0.1.14 upgrade ;)