Add a --force-recompile option

[hynek]

The auto-wheeling is something great, but it leads to really annoying problems like pyca/cryptography#2006.

Especially because I couldn’t figure out without dtruss where the hell the cache is. :)

[rbtcollins]

Hmm, so an alternative/complementary thing, which I think might be better is a way to flush a given thing out of the cache. The original cache path I used made that easy, because it was human readable, but the new one is more opaque (though still amenable to find ~/.cache/pip/wheels -iname "mything")

[hynek]

That presumes you know to look in ~/.cache or wherever it is hidden on Win32/Mac. Easier cache introspection (e.g. -v saying "using precompiled wheel from absolute-path) would help a lot too. At least it'd saved me about an hour learning OS X debugging tools. ;)

[dstufft]

We could have pip purge cryptography.

[dstufft]

A downside of that is it would be somewhat of a pain to purge the HTTP cache since that has a completely opaque directory structure and I'd think that a purge command should being purging the entire cache for that named project.

[rbtcollins]

+1 on purging within the http cache. An alternative to active purging is lazy purging: we write a timestamp for now to a file in the cache. Then we ignore all cached results older than that time. This should be easy enough to glue into the http cache and the wheel cache.

[hynek]

+1 to make a purge command. There are more reasons one would want to do it

As a side note: a cache status command would be amazing too. Something that will tell you: yes, it's in http cache at abs-path and/or wheel cache at -abs-path. Because debugging this was really painful.

[hynek]

Ouch, another use case: I’ve just updated my PyPy to 2.6.0 and it seems as if the wheels stopped working (probably due to a change cffi? maybe @arigo or @alex can say more about that; started getting exceptions.ImportError: cannot import name 'etree' until I re-wheeled lxml).

Anyhow, it seems like this issue should be a higher priority than it originally seemed. :-/ If I see this correctly, everyone updating their PyPy will run into this.

In this case maybe you should seriously consider to take PyPy’s version into account too when caching (separate issue, I know).

[arigo]

I think this is caused by the presence of a file called ".pypy-25.so", which needs to be ".pypy-26.so" in PyPy 2.6. (We use the same extension for "cpyext", i.e. C extension modules compiled in compatibility mode, and for cffi. Maybe we should say---reasonably---that it now tends to be compatible across pypy versions and stop changing its name at each minor release.)

[rbtcollins]

So, sounds like wheels from PyPy are inappropriately tagged - what filename are they creating? I need to page in the fine detail of the wheel spec, but essentially its over to wheel to DTRT thing here. Or PyPy to be compatible within major versions, which AIUI wheel presumes

[hynek]

The only tag I can see is pp27 with not regard to the version.

And if you try to use PyPy 2.5.1 wheels in 2.6 (I.e.pip install without purging the cache) all kinds of weird stuff happens. One example is above, another one is https://gist.github.com/hynek/4c0ae4c6650ea57020e3

For posterity and ppl who find this by Google, what you need is:

find ~/.cache/pip/wheels/ -name "*pp27*" -delete

Or

find ~/Library/Caches/pip/wheels -name "*pp27*" -delete

[rbtcollins]

Whats the filename of one of your wheels doing the pypy.so thing? I think pip might have an invalid assumption here which we can fix.

[rbtcollins]

Specifically, whats the python tag and whats the abi tag you have used?

[hynek]

Not sure whether you mean me, but here’s some examples:

cryptography-0.9.1-pp27-none-linux_x86_64.whl
Twisted-15.2.1-pp27-none-linux_x86_64.whl
lxml-3.4.4-pp27-none-linux_x86_64.whl

[rbtcollins]

Ok phew - so this is combination wheel/pypy bug.

"The wheel filename is {distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl ."

So - those filenames say:
lxml
3.4.4
no build tag
pp27
no abi tag
linux_x86_64

But https://www.python.org/dev/peps/pep-0425/ says https://www.python.org/dev/peps/pep-0425/#abi-tag - and all those wheels are things which include extension modules, and consequently depend on the ABI of pypy, part of which appears to be the naming of the extension .so. Fixing wheel/pypy (I'm not sure who owns the ABI detection / export stuff) would identify these as separate wheels for separate pypy's.

That said, pp27 is also not declared as compatible with pp26 per PEP 425, so there is something we should change here in pip I think. @dstufft - thoughts?.

[dstufft]

I think the problem is that PyPy's version tag is wrong. It's using the Python version not the PyPy version (however it needs to differentiate PyPy and PyPy3 with the same version number).

[rbtcollins]

Oh, in both cases? I figured these were from one pypy version of wheel building. @HYNK what happens when the wheels are built with the other release of pypy (pypy2.6 or whatever) ?

[dstufft]

Yea, no matter what version of PyPy you get pp27, and no matter what version of PyPy3 you get pp32 (until they release a 3.2 compatible one).

[dstufft]

But we can't just do like pp26 because there might also be a PyPy3 2.6, so we might need to do pp326 or something.

[rbtcollins]

ack, I see.

[rbtcollins]

Still seems to me like the ABI should be filled out, but that would be complementary?

[hynek]

That’s what I meant in the first comment: you will need a separate way to determine the PyPy version because their binaries (and virtualenvs for that matter) are incompatible to each other. cffi that is bundled with PyPy and which version changes with each release being the most obvious offender.

[dstufft]

ABI should be filled out for something that has C code in it yes, there's no reason to fill out the ABI for sometihng that's pure Python but PyPy specific.

[rbtcollins]

Ok, so closing the loop, AIUI /all/ the problematic wheels here are C code using ones. cryptography, lxml, Twisted.

[hynek]

Yes absolutely. Only C extensions are trouble.

[natefoo]

@dstufft I am treating pp226 and pp324 (for example) as gospel for the work I'm doing on Python 2 ABI support in pip/wheel pep425tags.py. Let me know if you think this is a bad idea.

[OOPMan]

Hey all, I've run into an issue that looks to be related to this one. See pyca/cryptography#2478 for the gory details, but to summarize:

Pip caching does not seem to play nicely when multiple Python interpreters are present. Specifically, I was testing with two different compiles of the PyPy interpreter and found the .so files compiled by Cryptography where getting re-used from one interpreter to the next. This caused Cryptography to fail when importing the crypto backends.

Replication details are available in the issue linked above.

[xavfernandez]

@OOPMan the multiple interpreters present issue should be solved (or at least improved) by #3225

[OOPMan]

@xavfernandez Nice, good to know :-)

[dstufft]

This may be solved by #2819 if we go with a purge command.

[pradyunsg]

Linking this to #4685.

[pradyunsg]

We could have pip purge cryptography.

There's pip cache purge cryptography now and it does basically everything that has been requested here from the cache-purging perspective. Additionally, a pip install . will now always rebuild the wheel and not use the cache for the package being built.

Between these two, I think the request being made here is covered so I'm gonna go ahead and close this eagerly. If someone feels like there's more to discuss, please feel free to reopen. :)