Log file Viewer

[09:15:39] <amsharma> How can I tell pip to not use the cache for some time?

[09:15:52] <amsharma> i have a package installed (selenium 2.53)

[09:15:59] <xafer> --no-cache-dir ?

[09:16:39] <amsharma> wow, weird!

[09:16:46] <amsharma> xafer: I used --no-cache-dir

[09:16:57] <amsharma> but pip is still downloading an old version of the package

[09:17:11] <amsharma> selenium has 3.0 on pypi

[09:17:18] <amsharma> but when i do pip install selenium

[09:17:25] <amsharma> it installs the 2.53 version

[09:17:40] <xafer> add --verbose to check how it selects this version

[09:18:23] <amsharma> what is the switch so that i don't have to press y after uninstall?

[09:20:56] <xafer> pip uninstall --help ;)

[09:21:23] <amsharma> it did find 3.0.0b1 but didn't include it in the newest of versions list...

[09:21:31] <amsharma> because the package is a beta?

[09:27:06] <xafer> yup, you'd need the --pre switch

[09:37:11] <therue> hello :)

[18:16:14] <durin42> dstufft: ahoy, got a second for a twine question?

[18:18:01] <dstufft> durin42: sure

[18:18:42] <durin42> dstufft: so, for hysterical raisins, the Mercurial package on the cheeseshop is called "Mercurial", but in the setup.py etc it's "mercurial", which confuses twine.

[18:19:02] <durin42> dstufft: what should we do, so we can stop using a hacked twine install? (I just found out mpm has been doing this for years, sigh)

[18:19:22] <dstufft> durin42: um, well that sounds like a Twine bug

[18:19:32] <dstufft> can you explain how it confuses twine?

[18:20:12] <durin42> Twine thinks I should upload to a package called "mercurial" which doesn't exist

[18:20:31] <dstufft> durin42: is there a traceback or something?

[18:20:48] <durin42> is there a way to test against a dummy pypi or something?

[18:21:11] <durin42> (otherwise I can wait until it's time for 3.9.1 and then see if I can reproduce the failure)

[18:21:34] <dstufft> durin42: Test PyPI yea

[18:22:17] <dstufft> https://hynek.me/articles/sharing-your-labor-of-love-pypi-quick-and-dirty/ search for "testppyi"

[18:22:25] <dstufft> except spelled correctly

[18:23:08] <durin42> cool

[18:23:34] <dstufft> durin42: I suspect this may be a legacy PyPI problem

[18:23:54] <durin42> oh boy

[18:24:05] <dstufft> so if you can reproduce it with testpypi.python.org, try it again with repository set to https://test.pypi.org/legacy/

[18:24:30] <dstufft> if it reproduces with the first, but doesn't with the second, then the easiest thing to do is just upload to warehouse instead of PyPI

[18:25:27] <durin42> fun

[18:25:49] <dstufft> (uploading to warehouse is better in basically every way anywas)

[18:29:05] <durin42> Should we just be doing that anyway?

[18:30:12] <dstufft> durin42: yea I recommend it, it's more likely to actually work on any given upload-- and if you're using a recent twine it defaults to that if you don't set a repository url in your ~/.pypirc

[21:12:23] <tdsmith> hey dstufft, can i get some pypi.io support?

[21:12:30] <dstufft> tdsmith: whats up

[21:12:52] <tdsmith> legacy pypi has the same data

[21:12:54] <tdsmith> think this might be user error

[21:13:04] <tdsmith> but https://pypi.io/pypi/lazr.authentication/json shows no data for version 0.1.3

[21:13:18] <tdsmith> but the json for version 0.1.2 has a tarball for version 0.1.3

[21:14:03] <dstufft> lol

[21:14:12] <dstufft> this is almost certainly because PyPI is stupid

[21:14:29] <dstufft> the upload API takes a file + a bunch of data alongside the file... and doesn't really verify that they match

[21:14:44] <dstufft> so you can totally upload a 0.1.3.tar.gz with version: 0.1.2

[21:15:01] <dstufft> tdsmith: the tl;dr is that PyPI is dumb and allows this, and someone decided to do it... or accidently did it

[21:17:50] <tdsmith> oh well :p

[21:18:30] <tdsmith> https://bugs.launchpad.net/lazr.authentication/+bug/1397282 heh, filed in 2014

[21:18:56] <tdsmith> oh, this is a different pypi issue