Log file Viewer

[04:47:13] <macopython> I am generating rpm using bdist_rpm approach. But generated rpm doesn't remove installed directory. Any help ?

[16:55:37] <nanonyme> dstufft, well, the mirror our IT is running obviously does not

[16:56:50] <nanonyme> Though yeah, I'll ask about it when I have time. pip 8 isn't really a top priority for me currently

[16:57:00] <dstufft> nanonyme: yea, just saying that the rules are such you can do that.-- Unfortunately this is a situation where there wasn't much we could do but make the change or live with permanent weird-ness and inefficiency around . and - in names

[16:57:33] <nanonyme> Uhm, what was the inefficiency in that?

[16:58:58] <nanonyme> PEP 503 didn't really contain much justification for the normalization

[16:59:16] <nanonyme> Sounds like you did have some reason?

[17:01:27] <dstufft> nanonyme: so setuptools/pip has done the normalization for basically ever, normalization is good because it means "django" and "Django" are the same thing, it also means django-foobar and django.foobar and django_foobar are the same thing, those are less obvious than django vs Django but I think it's important to reduce the confusion that could happen between having django-foobar and django.foobar be different things

[17:02:05] <dstufft> nanonyme: so the normalization is not new, but what is new is that pip requests the normalized version explicitly, it used to be that if you typed ``pip install DjAnGo`` pip would fetch /simple/DjAnGo/

[17:03:30] <dstufft> that means that A) your server would have to be smart enough to redirect all of the un-normalized versions to the "canonical" version and B) pip had to make extra HTTP requests, with an extra C) that if /simple/DjAnGo/ 404'd, pip would then fetch /simple/ and do the normalization dance itself

[17:04:35] <nanonyme> So, do you mean that the reason for normalization is security and prevention of tricking people to install malicious packages?

[17:05:09] <dstufft> by switching it so that pip always requests the normalized form from the server, the server doesn't need to do any sort of redirecting (except to support old versions of pip if they want to do that), that pip needed to make less http requests, and so that we could remove the fallback to /simple/ (which is a ~3.8MB download atm)

[17:05:34] <dstufft> nanonyme: both normalization and user friendliness yes, because it'd be weird if ``pip install django`` failed

[17:05:45] <dstufft> er

[17:05:51] <dstufft> both security and user friendliness

[17:06:52] <prometheanfire> would an option for pip freeze to include things excluded by default (setuptools and the like) be ok?

[17:07:38] <dstufft> prometheanfire: try `pip freeze --all`

[17:08:31] <prometheanfire> no option --all

[17:08:42] <prometheanfire> I should probably try a newer pip?

[17:08:46] <dstufft> prometheanfire: try pip install --upgrade pip, then try pip freeze --all :D

[17:09:00] <prometheanfire> not on gentoo, I'll test in a virtualenv

[17:09:04] <prometheanfire> that breaks gentoo

[17:09:46] <nanonyme> dstufft, ok. Please mention this kind of stuff as incentive in PEP next time, I started on the matter on the wrong foot

[17:11:03] <prometheanfire> dstufft: cool that works

[17:12:51] <dstufft> nanonyme: sure, it didn't really get added I guess becuase the normalization has existed for like 15 years or so at this point :) What changed was making the expectation that /simple/<normalized>/ would _always_ work regardless of what the "real" name of the thing was, and pip removing the /simple/ fallback

[17:13:46] <nanonyme> dstufft, TBH I didn't even know there was normalization before running into PEP 503 and I suspect majority of users didn't actively think of it

[17:14:57] <nanonyme> As you said, current functionality is user-friendly. It's even so much that people don't really think of what's happening when they're typing package names

[17:15:02] <dstufft> nanonyme: ya, and post PEP 503 most users still don't actively think about it I think-- Longterm, the only time it _should_ come up is when someone is making their own implementation of a repostiory (and in the interim, it comes up when epople have existing repos that don't handle it :( )

[17:15:38] <dstufft> but when both sides are fully PEP 503 compliant, end users don't need to think about it

[17:16:14] <nanonyme> dstufft, well, isn't PEP 503 mainly meant targeted for admins anyway, not end users?

[17:16:21] <dstufft> nanonyme: ya

[17:16:46] <dstufft> end users shouldn't need to think about it, the only reason you needed to was the weird in between state when not everything is all caught up

[17:17:00] <nanonyme> So the "why do I need to change my shit, it worked fine before" is a good idea to answer. Admins are typically very conservative people

[17:17:13] <ngoldbaum> it also impacts version numbers that people choose

[17:17:23] <nanonyme> Hmm, right

[17:17:26] <ngoldbaum> i.e. pip might normalize your version number

[17:17:36] <ngoldbaum> but as dstufft said, it's been doing that for a long time

[17:18:05] <dstufft> version normalization is PEP 440, and that's been in for not nearly as long as name normalization, but a few years at this point :D

[17:20:05] <nanonyme> ngoldbaum, just the fact that the behaviour has been there doesn't matter. PEP 503 implies responsibility shift from pip devs to server admins. It's good to argue why to normalize at all imo

[17:23:05] <dstufft> it's a been of a mess tbh

[17:23:21] <dstufft> previously the definition of what a repository was was "whatever PyPI does, I guess?"

[17:24:10] <dstufft> whicih sucks if you're trying to implement something and you're not PyPI :) no idea what is important and what is just random implementation details

[17:25:15] <dstufft> PEP 503 attempted to write an actual spec for that, and in the process it invalidated some people's reverse engineered assumptions

[17:38:00] <nanonyme> Yeah, I do get why PEP 503 made sense. It would just imo have made sense to put all of that into PEP 503 so that everyone wouldn't need to explain this same thing to their server admins

[20:32:05] <xz0r> Hi, whatever I try to install via pip I am getting the following error: Cannot fetch index base URL https://pypi.python.org/simple/

[20:32:10] <xz0r> I'm not able to install anything

[20:33:03] <ngoldbaum> you have an old version of pip that needs to be updated

[20:33:27] <ngoldbaum> https://pip.pypa.io/en/stable/installing/

[20:33:45] <ngoldbaum> although as that url notes, be careful if you're using the system python installation

[20:34:11] <ngoldbaum> (you almost definitely don't want to use the system python installation, if you are using it)

[20:34:26] <nanonyme> Breaking backwards-compatibility with pip is *bad* *always*. Expect people to want to use pip to update pip

[20:34:53] <ngoldbaum> nanonyme: i'm pretty sure this is due to a bug in pip

[20:35:37] <ngoldbaum> perhaps due to proxies?

[20:35:37] <ngoldbaum> http://stackoverflow.com/questions/21294997/pip-connection-failure-cannot-fetch-index-base-url-http-pypi-python-org-simpl

[20:36:07] <ngoldbaum> http://stackoverflow.com/questions/15501133/python-pip-error-cannot-fetch-index-base-url-https-pypi-python-org-simple

[20:40:11] <xz0r> ngoldbaum, after updating pip to 8.1.2 I'm the following errors https://dpaste.de/tTtW

[20:40:42] <ngoldbaum> what python version are you using?

[20:40:54] <xz0r> 2.7.6

[20:41:14] <ngoldbaum> as indicated by the error message, you should update to python 2.7.9 or newer to get non-broken TLS

[20:41:38] <xz0r> what is the command to that?

[20:41:53] <ngoldbaum> it depends on how you've set up your python installation

[20:44:32] <nanonyme> ngoldbaum, wasn't it 2.7.8?

[20:44:44] <ngoldbaum> nope, 2.7.9 had the SSL backport

[20:44:58] <ngoldbaum> should have been called 2.8 but that would have been a bridge too far :)

[20:46:14] <nanonyme> Looks like you are correct, I checked changelogs

[20:46:28] <nanonyme> And yes, I would very much have preferred 2.8.0

[20:47:19] <nanonyme> 2.7.9 was largely a "we're going to break your existing systems but we're claiming this is a bugfix only"

[20:47:45] <ngoldbaum> well, to be fair, if 2.7.9 broke anything it's because you had security issues but didn't know it

[20:47:47] <nanonyme> Heh, looks like changelog also comments about this being unprecedented

[20:48:31] <nanonyme> Well, yes and no. People were using it a lot in company-internal purposes where cert validation was supposed to be disabled

[20:48:48] <nanonyme> Then suddenly Python maintainers decided they know better

[20:49:00] <ngoldbaum> that's true

[20:49:12] <ngoldbaum> i know of several supercompute centers that are still dealing with upgrading python 2.7 because of this

[20:49:21] <ngoldbaum> a lot of them have very old OpenSSL installs

[20:49:34] <ngoldbaum> like, heartbleed still isn't patched old

[20:49:45] <nanonyme> Yup