Log file Viewer

[14:49:43] <tdsmith> hmmm, https://github.com/pypa/virtualenv/pull/513/files is still a problem

[16:02:54] <grenle> Hi, I am wondering when download statistics are likely available in warehouse / pypi.io

[16:03:40] <grenle> I have read past irc logs / warehouse commit logs for this. I saw discussion on features for this on github.

[16:04:15] <grenle> It seems feature requirements / suggestions are rather ambitious.

[19:02:27] <tdsmith> dstufft: should pip freeze --hash exist?

[19:05:08] <dstufft> tdsmith: it theortically could, but it'd make it so ``pip freeze`` has to do network IO, because it's not possible to reverse engineer the hash of the .whl or .tar.gz from an installed distribution

[19:05:31] <dstufft> tdsmith: I pasted a snippet on the thread

[19:05:33] <dstufft> might be useful

[19:06:07] <tdsmith> nice, thanks

[19:07:33] <dstufft> tdsmith: one thing to remember of course is that ``pip freeze is going to miss setuptools/pip/wheel/distribute etc as a dependency

[19:08:09] <dstufft> so if something wants cryptography, it's not going to get a version of setuptools baked into the pip freeze

[19:08:15] <dstufft> as part of the dependency tree

[19:08:30] <tdsmith> that's fine, we'll keep virtualenv recent

[19:08:42] <tdsmith> thanks for the reminder!

[19:08:44] <dstufft> (now if you're using virtual environments, by default that's going to pull in a setuptools too, but it may have the same problem as you're trying to avoid by using ==

[19:12:31] <dstufft> tdsmith: fwiw --hash will break if you don't update the list of hashes and someone releases a new wheel that pip prefers over what's already there, you might want to do --no-binary :all: both to always build from source, and to make it so wheels can't be uploaded and break --hash (if you end up using --hash)

[19:12:56] <tdsmith> sounds good. we're doing --no-binary :all: already

[19:13:01] <dstufft> Ah good

[19:13:33] <dstufft> (there's still a small window, where someone can upload foo-1.0.tar.gz and then later foo-1.0.zip, but I plan on getting rid of that and only allowing one extension)

[19:14:16] <dstufft> tdsmith: ^ that can be used to attack if someone has control of an author account, fwiw

[19:14:21] <dstufft> not sure if tha'ts something y'all care about

[19:16:46] <tdsmith> oh, interesting

[19:24:19] <dstufft> tdsmith: you maybe want --isolated too

[19:24:44] <tdsmith> i was trying to decide earlier if that would buy me anything in a virtualenv

[19:24:52] <dstufft> user level configs will still be a thing

[19:25:04] <dstufft> like pointing pip at something that's not PyPI for instance

[19:25:37] <tdsmith> we do unset $HOME at least

[19:25:52] <tdsmith> may as well anyway

[19:26:39] <dstufft> ah, if you unset $HOME then I think it won't matter

[19:29:19] <tdsmith> bitrot from unpinned dependencies is a "speculative issue" now >:

[19:30:26] <tdsmith> i gotta come back to this later so my coworkers don't keep wondering why i'm making strangled noises at my desk

[19:33:06] <dstufft> tdsmith: would it help if I commented that I can confirm that the problem (indpendently from Homebrew) exists, and it's one of the reasons that we (pip) recommend people use pinned dependencies as part of their deployment steps?

[19:35:27] <tdsmith> that would be lovely