pmxbot IRC Log Viewer

[22:17:36] <xafer> any idea why pip defines https://github.com/pypa/pip/blob/develop/pip/wheel.py#L104-L128 instead of using EntryPoint.parse_map ?

[22:18:49] <dstufft> Came from https://github.com/pypa/pip/commit/22b63127cbccc3476033e54eb72bac8ea932ce3a

[22:18:58] <dstufft> pf_moore: is probably the best to ask if he still remembers

[22:19:01] <dstufft> Id on't know personally

[22:25:32] <xafer> I was wondering if distlib vendoring was useful: its used for the environment markers parsing and the script generation.

[22:25:50] <xafer> But the marker parsing can be performed via markerlib, already vendored

[22:26:30] <xafer> and the script generation might me mutualised with some code of setuptools

[22:28:53] <tomprince> My understanding is that distlib was added under the impression that it would be a faithful implementation of packagin PEPs, but it ended up also having a number of experimental things.

[22:29:00] <tomprince> (Hence 'packaging')

[22:29:18] <tomprince> So, it would probably make sense to remove it, if there are alternatives.

[22:30:16] <pf_moore> xafer TBH, probably because I didn't know about that function :-) Also, at the time we didn't vendor pkg_resources, so we avoided references to it (it's not quite that simple, as we may have used setuptools in some places, but that's basically it)

[22:31:19] <pf_moore> xafer: I'm strongly -1 on using setuptools' script generation rather than distlib's, as I find setuptools' distinctly inferior (at least on Windows)

[22:32:09] <pf_moore> I don't have any objection to us copying just distlib's script generation code (or vendoring a new package that replicates it).

[22:32:26] <xafer> good to know :)

[22:33:06] <pf_moore> To be specific, the key points for me are single-file wrappers (no xxx-script.py) and no setuptools runtime dependency (the require stuff)

[22:37:17] <xafer> I dont know all the specificities but do we agree that sdist installation use setuptools code and wheel installation use distlib code ?

[22:52:31] <xafer> that's why I was prone to use the same implementation (ie setuptools) for both sdist and wheel scripts

[23:39:49] <r1chardj0n3s> dstufft: I propose removing google button from openid login on pypi...

[23:40:11] <dstufft> r1chardj0n3s: I kinda want to just remove openid all together, it seems to be more troubl than it's worth :/

[23:40:23] <r1chardj0n3s> yeah, but people still use some of the other providers

[23:40:40] <lifeless> dstufft: :<

[23:40:47] <lifeless> dstufft: openid and oauth - I love as a user.

[23:41:30] <dstufft> lifeless: I have ~opinions~ about federated auth

[23:41:48] <dstufft> I think it's an ideal that'll never be realized because reality sucks

[23:41:56] <r1chardj0n3s> lifeless: openid is a shambles and breaks all the time and I have no time to support it :(

[23:42:28] <dstufft> I think launchpad is still broken for some people, and i can't figure out why

[23:42:34] <r1chardj0n3s> yep, it is

[23:42:40] <r1chardj0n3s> I wish martin had never added openid :/

[23:42:48] <dstufft> same

[23:42:52] <lifeless> dstufft: its here and working, the balkanisation is mainly due to the big players being douchebags ;)

[23:42:53] <r1chardj0n3s> but it seemed like a good idea at the time

[23:43:02] <dstufft> openid doesn't really work for non web flows either

[23:43:13] <r1chardj0n3s> lifeless: "working" is debatable

[23:43:20] <dstufft> how does setup.py upload or twine work with it (the answer is, it doesn't, you have to set a password anyways)

[23:43:34] <r1chardj0n3s> yah, people still need to get a username/password anyway

[23:43:34] <lifeless> dstufft: that would be a place where you'd use oauth

[23:43:49] <r1chardj0n3s> oauth is also a web interaction

[23:44:13] <lifeless> to get the token, yes, but you can do it separate from the place you use it

[23:44:32] <lifeless> sorry, to authorise the token

[23:44:38] <r1chardj0n3s> IIRC our discussion of warehouse included being able to generate per-use tokens for access

[23:44:56] <r1chardj0n3s> similar to the google one-off passwords for application access

[23:45:09] <lifeless> dstufft: if lp sign in fails, it may well be an LP end issue

[23:45:24] <dstufft> lifeless: No idea, I get people complaining to us about it and I can't figure out why

[23:45:29] <r1chardj0n3s> yep

[23:45:41] <dstufft> http://d.stufft.io/image/1e191a0K1u0U

[23:45:43] <dstufft> it worked fine for me

[23:45:45] <dstufft> not for glyph

[23:46:55] <lifeless> dstufft: did it work after the 'try now' ?

[23:47:01] <tomprince> I don't know if I know my pypi password. I just use the google auth. :/

[23:47:05] <dstufft> lifeless: the error changed

[23:47:14] <dstufft> the original error was our problem

[23:47:20] <lifeless> righto

[23:47:25] <r1chardj0n3s> tomprince: you can use the forgotten password thing to get a password

[23:47:33] <dstufft> I stopped importing M2Crypto because we got rid of our use of it, but it was sitll isntalled and passlib imports it

[23:47:42] <dstufft> and m2crypto monkeypatches urllib2 whne its imported

[23:47:56] <dstufft> and when I stopped importing it oruselves, our workaround to prevent m2crypto from doing that was removed

[23:48:35] <r1chardj0n3s> ugh

[23:49:22] <lifeless> monkeypatching from library calls considered harmful

[23:49:33] <dstufft> MyOpenID, LP, Google 2/3 of them are gone that we "supported"

[23:49:33] <dstufft> :/

[23:50:04] <lifeless> google supports OAuth 2.0 still doesn't it?

[23:50:13] <lifeless> there was some migrationary thing going on

[23:50:16] <r1chardj0n3s> google "deprecated" openid in may last year, still no word on when they're gonna turn it off

[23:50:39] <lifeless> I thought they did

[23:50:46] <dstufft> they did just turn it off yea I think so

[23:50:46] <lifeless> maybe it was oauth 1.0a they turned off

[23:50:53] <r1chardj0n3s> lifeless: yes, "openid connect" they call it

[23:51:01] <dstufft> and yea google supports oauth 2.0, but we don't support that

[23:51:09] <r1chardj0n3s> https://developers.google.com/accounts/docs/OpenID2

[23:51:11] <dstufft> and who knows maybe google will turn that off too in the future

[23:51:33] <r1chardj0n3s> no, because with "openid connect" they get to keep pushing the google+ turd

[23:52:31] <r1chardj0n3s> I'd *love* to have a "Sign in with Google+" on the page, alongside the "Sign in with GitHub" and all the other services people will ask for :/

[23:52:40] <r1chardj0n3s> (Facebook - someone will ask for Facebook)

[23:52:52] <dstufft> I'd love to get rid of auth all together and make id.python.org :V

[23:52:55] <r1chardj0n3s> big ol buttons

[23:53:03] <lifeless> r1chardj0n3s: so thats the replacement for openid yea?

[23:53:26] <r1chardj0n3s> lifeless: it's google's replacement for it, yes. it's oauth, which is way heavy-weight just for identification.

[23:53:28] <lifeless> I just want less IdPs

[23:53:34] <r1chardj0n3s> dstufft: what's id.python.org do when it's home?

[23:53:49] <dstufft> r1chardj0n3s: my ~dream~ is that id.python.org acts as a SSO for all of *.python.org

[23:53:54] <r1chardj0n3s> because pypi is already an openid2 and oauth2 provider ;)

[23:53:56] <dstufft> it doesn't exist at all though

[23:54:14] <r1chardj0n3s> s/pypi/id and you're set ;)

[23:54:32] <dstufft> r1chardj0n3s: yea except I don't think I can login with pypi on www.python.org or bugs.python.org or mailman or ..

[23:54:41] <r1chardj0n3s> no, you can't :/

[23:55:11] <r1chardj0n3s> moar coffee time

[23:55:46] <dstufft> I think I've become increasingly of the opinion that federated auth is a pipe dream. Either your site depends on another site (like Travis CI depends on Github), in which case hardcoding that auth as your only auth makes sense or the federated auth is always a second class citizen

[23:57:07] <lifeless> why are they always a second class citizen?

[23:57:37] <lifeless> my *best* experiences these days with small sites are those that don't require me to make up a damn password

[23:57:41] <lifeless> low friction

[23:57:44] <lifeless> easy access

[23:57:51] <lifeless> no need to worry about password resets

[23:57:54] <lifeless> 2FA built in

[23:58:06] <dstufft> because they are? I've never seen a site that offered local accounts _and_ federated auth where I felt like the federated auth was on the same level as the local accounts

[23:58:18] <dstufft> something always worked worse trying to use it

[23:58:19] <lifeless> so don't offer local accounts

[23:58:34] <dstufft> do you offer anything but launchpad?

[23:58:37] <lifeless> I don't think I have a local account on stackexhange, for instance

[23:58:50] <lifeless> me? I'm talking as a user, not a site dev.

[23:59:21] <dstufft> Honestly federated auth probably makes a lot more sense for small sites than it does for big sites *shrug*. I don't trust other openid things to implement 2fa anyways

[23:59:28] <dstufft> so whenever we implement 2fa it'll be our own 2fa

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Sunday the 8th of February, 2015