pip not removing pkg dirs that contain __pycache__ dirs

[qwcode]

the tip version of pip is not removing pkg dirs that contain __pycache__ dirs

see pull #637 where I generate a failure for py32 by adding an import that generates the __pycache__ folder before the uninstall is attempted.

a similar issue came up for the debian package of pypy (that travis uses) which patches pypy to generate __pycache__ folders. there's currently a workaround for that case (see #630). possibly, we can fix both of these cases with one general fix.

I don't see this behavior locally using pip1.1 with py32, so something changed, but not sure what yet.

pip is attempting to remove the pkg using installed-files.txt which is generated using setup.py install with --record combined with --single-version-externally-managed. The log just contains inline *.pyc files. If you trace it down, you find what's ultimately being called to generate the compiled filenames is:
setuptools.command.install_lib._bytecode_filenames which has no __pycache__ awareness.

[qwcode]

important discussion related to this: http://bugs.python.org/issue11254

[qwcode]

posted question to distutils list to get some context:
http://mail.python.org/pipermail/distutils-sig/2012-August/018825.html

waiting to see if people have input.

[qwcode]

getting the byte-compiled filename in 3.2+
http://docs.python.org/py3k/library/imp.html?highlight=imp#imp.cache_from_source
"if path is /foo/bar/baz.py the return value would be /foo/bar/__pycache__/baz.cpython-32.pyc"

the debian patched version of pypy also has imp.cache_from_source

so I think the the fix here is just generalizing the workaround we already have for debian pypy (#630) to use imp.cache_from_source

[qwcode]

btw, the change from pip1.1 that exposed this is pull #437, which I think is a good change.

[qwcode]

FYI, a pull is in the works for this.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.