pmxbot IRC Log Viewer

[05:21:03] <agronholm> dstufft: just wondering...if you see werkzeug/flask as MVC, where is the "C" or Controller if not the code that executes queries and renders the templates?

[05:26:58] <dstufft> agronholm: gotta be honest, Id on't really think about it all that often. I call it view because that's what Django called it and that's what I learned :)

[05:27:15] <dstufft> but Django calls itself MVT (Model-View-Template) not MVC

[05:27:39] <agronholm> most other frameworks would call themselves MVC, despite having the same fundamental structure

[05:28:14] <agronholm> the controller is where the business logic happens

[05:28:30] <agronholm> the view is where the visible output is generated

[05:28:42] <agronholm> that is, where the display logic works

[05:31:49] <dstufft> yea, I grok it, and It's mostly out of habit rather than conscious choice :)

[06:49:37] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[06:49:37] <pmxbot> Correct sort order by using list.sort with support for 'key' and 'reverse'. This method is less efficient, but allows the tests to pass.

[06:49:37] <pmxbot> Remove _sort_dists (unused)

[06:49:37] <pmxbot> Merge pkg_resources.Environment.__getitem__() code cleanup (pull request #47 and subsequent changes).

[07:52:01] <pmxbot> jaraco pushed 11 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[07:52:01] <pmxbot> Rewrite hashcmp using modern syntax

[07:52:01] <pmxbot> Reformat for consistency

[07:52:01] <pmxbot> Reindent long line

[07:52:01] <pmxbot> Use simpler syntax to get the same info

[07:52:01] <pmxbot> Reindent long lines in marker impl

[07:52:01] <pmxbot> Reindent more long lines. Other minor syntax modernization.

[07:52:01] <pmxbot> Remove unnecessary list comprehension

[07:52:01] <pmxbot> Now this syntax fits nicely on one line

[07:52:01] <pmxbot> Fix spacing in __all__

[07:52:01] <pmxbot> Avoid trailing comments

[07:52:01] <pmxbot> Use modern syntax for octal values

[13:53:36] <jezdez> dstufft: pin

[13:53:38] <jezdez> g

[15:15:14] <dstufft> jezdez: pong

[15:18:00] <jezdez> dstufft: can I point pip-installer.org and virtualenv.org already somewhere?

[15:19:55] <dstufft> jezdez: yup

[15:19:59] <dstufft> just cname to web.pypa.io

[15:20:06] <jezdez> ok.

[15:20:25] <dstufft> it'll redirect any pip-installer.org subdomain or virtualenv.org subdomain (or apex for both) to their respective *.pypa.io domain

[15:20:27] <jezdez> I'd like to move the domains somewhere where I'm not the bottleneck

[15:20:42] <dstufft> If you want to set the DNS up in rackspace that's where the DNS is setup for pypa.io

[15:20:49] <dstufft> do you have those creds? I don't remember if I sent them to you or not

[15:20:56] <jezdez> nope

[15:21:04] <dstufft> I'll send them, moment

[15:21:07] <jezdez> cool

[15:21:15] <jezdez> right now pypa.io is registered with you?

[15:21:28] <dstufft> yea

[15:21:32] <dstufft> jannis@leidel.info yea?

[15:21:35] <jezdez> yeah

[15:22:21] <jezdez> brb, urgent cake eating here

[15:22:27] <dstufft> jezdez: you should have a GPG email with the rackspace creds

[15:22:32] <jezdez> yep, got it

[15:22:34] <jezdez> yay gpg

[15:22:39] <dstufft> that's where the servers are too

[15:22:43] <dstufft> we get 2k/month free

[15:22:43] <jezdez> cool

[15:22:46] <jezdez> <3

[15:23:09] <dstufft> we have free fastly too

[15:23:14] <dstufft> with SSL for *.pypa.io and pypa.io

[15:25:28] <dstufft> jezdez: as far as domain registration goes, I don't have a good solution for that. Luckily that is something where the settings to fiddle are pretty limited. We could get a team account somewhere, or we could see if the PSF would take ownership of the domains

[15:25:39] <dstufft> or we could just keep owning our respective ones

[15:25:44] <dstufft> it doesn't matter much to me

[15:43:38] <Ivo> just point pip-installer.org & virtualenv.org NS at some rackspace ones?

[16:01:45] <jezdez> Ivo: that's not the point, I'm talking about the registration of the domains

[16:02:06] <jezdez> dstufft: makes sense. maybe we could talk to coderanger about the psf registering

[16:02:39] <jezdez> as long as we keep stewardship over the domains via dns, I'd rather have the domains somewhere safe

[16:03:33] <Ivo> know what psf uses?

[16:06:04] <jezdez> I think gandi

[16:06:47] <jezdez> there was a domains report on the psf-members list three days ago

[16:20:43] <dstufft> yea they use Gandi

[16:26:08] <jezdez> dstufft: do you know if gandi supports shared accounts?

[16:26:18] <dstufft> no idea

[16:26:28] <dstufft> Gandi is what I used too, but I never tried to do that before

[16:28:54] <jezdez> ok, I'll look into it

[16:29:24] <jezdez> in the meantime I update the dns for pip and virtualenv

[16:30:12] <jezdez> dstufft: oh, one other thing, how does the docs rendering work now?

[16:30:21] <dstufft> it still goes through RTD

[16:30:23] <jezdez> rtd still is the origin server?

[16:30:24] <jezdez> ok

[16:30:26] <jezdez> cool

[16:30:28] <dstufft> Fastly just fronts RTD

[16:30:33] <jezdez> sweet

[16:30:37] <jezdez> thanks for working on this

[16:30:43] <jezdez> that'll be a big help I think

[16:30:53] <jezdez> let's pray for fastly never going down :D

[16:31:10] <dstufft> it does mean that changes to the docs may take up to an hour to show up

[16:31:14] <dstufft> our cache time is set to an hour

[16:31:39] <jezdez> dstufft: okay, we need to take this into account when doing releases

[16:31:44] <dstufft> Eventually I'll probably write something that polls RTD and does a purge

[16:31:51] <jezdez> yeah

[16:31:54] <jezdez> sounds good

[16:32:10] <jezdez> as long as we can manually purge things via fastly's web ui I'm good

[16:32:23] <jezdez> btw, is there a way to get access there?

[16:32:37] <dstufft> yea, moment

[16:32:55] <jezdez> dstufft: <3

[16:32:57] <dstufft> each fastly user account is tied to a specific organization, and 1 user account per email address

[16:33:03] <dstufft> which email address do you want tied to pypa?

[16:33:23] <jezdez> jannis+pypa@leidel.info

[16:34:08] <dstufft> jezdez: you should get an email invite

[16:34:12] <dstufft> I made you a superuser

[16:35:07] <jezdez> superjezdez

[16:36:47] <jezdez> dstufft: dns entries changed

[16:37:32] <jezdez> both changes work already

[16:37:35] <jezdez> for me at least

[16:38:53] <dstufft> me too

[16:39:22] <dstufft> yay for consildation and TLS

[16:39:42] <jezdez> <3

[16:39:50] <jezdez> wanna do the announcement?

[16:40:01] <jezdez> or wait for propagation?

[16:40:39] <dstufft> can do an announcement

[16:41:37] <jezdez> btw, I registered a twitter account :) https://twitter.com/ThePyPA

[16:42:01] <dstufft> :D

[16:42:15] <jezdez> kinda want to wait to using it till we have a proper logo

[16:42:33] <jezdez> the designer who was asking for all kinds of questions didn't get back to me :('

[16:42:39] <jezdez> err, :'(

[16:45:00] <dstufft> ;(

[16:45:05] <dstufft> I should probably move twine over to PyPA

[16:45:55] <dstufft> jezdez: wanna give this a skim over https://gist.github.com/dstufft/1f36dc4882d5f53c712d ?

[16:48:02] <Ivo> dstufft: perhaps having the domains be urls would differentiate them more in the paragraph

[16:49:15] <dstufft> Ivo: updated

[16:51:01] <Ivo> dstufft: thought about moving setuptools' docs?

[16:51:28] <dstufft> Ivo: it's setup for it, blocked on https://bitbucket.org/pypa/setuptools/issue/194/add-support-for-read-the-docs

[16:57:16] <jezdez> dstufft: minor updates: https://gist.github.com/jezdez/3f326cb81cce21d3055c

[16:57:25] <jezdez> see https://gist.github.com/jezdez/3f326cb81cce21d3055c/revisions

[16:57:55] <dstufft> WFM

[16:57:58] <dstufft> gonna post it

[17:00:02] <dstufft> posted

[17:00:12] <jaraco> jezdez, do you hold the copyright on setuptools_hg (as forked by hgtools)? I'd like to re-license the code under a more liberal license (MIT).

[17:01:00] <jezdez> jaraco: I do indeed. I first released it as MIT IIRC but was told by mercurial devs that I was not allowed to do so due to licensing issues

[17:01:18] <jezdez> I would never use GPL on my own terms :-/

[17:01:43] <jaraco> Oh. That sounds familiar. I think we've discussed that before.

[17:01:59] <jezdez> https://bitbucket.org/jezdez/setuptools_hg/commits/c220eb46a094d8fdadd985e77c6b562ac0ef2c52

[17:02:02] <jezdez> yeah :)

[17:02:06] <jezdez> I think we did a while ago

[17:02:08] <tomprince> I thinik you can use any license you want, but the combined program will be bound by GPL.

[17:02:15] <jezdez> gee 2009!

[17:02:34] <jezdez> ah, BSD it was

[17:02:37] <jezdez> oh well

[17:02:41] <tomprince> So the effective license is GPL anyway.

[17:02:55] <jezdez> what's the license of setuptools?

[17:03:01] <jezdez> PSF?

[17:03:38] <jaraco> Yeah, I wonder about that. setuptools is Zope license and PSF.

[17:03:52] <jaraco> I suspect the PSF license comes from borrowing Python distutils code.

[17:03:53] <jezdez> jaraco: I guess we better get someone like van involved

[17:04:03] <jaraco> And the Zope license comes from Zope contributions.

[17:04:07] <jezdez> right

[17:04:32] <jaraco> It's not a clean situation, to say the least.

[17:04:47] <jezdez> true indeed

[17:05:02] <jezdez> pip imports stuff from setuptools as well

[17:05:15] <jezdez> so I'm not sure if that has any meaning

[17:05:24] <jezdez> IANAL :(

[17:05:58] <dstufft> setuptools_hg can just shell out to avoid GPL taint :V

[17:06:26] <dstufft> at least the FSF (who have an incentive to make the GPL as viral as possible) maintain that shelling out to GPG doesn't taint the calling software

[17:06:30] <Ivo> afaik you'd need to delete the `from mercurial...` code path

[17:06:45] <jezdez> dstufft: it does that if mercurial isn't found

[17:06:47] <tomprince> Does the taint apply to the source code, or only binaries compiled from the joint work?

[17:07:00] <Ivo> whatever is distributed to people

[17:07:02] <Ivo> to use

[17:07:52] <jezdez> setuptools_hg is only distributed as non-binary format

[17:08:02] <jezdez> assuming egg files are "binary"

[17:08:41] <jaraco> jezdez: can you comment on https://bitbucket.org/jaraco/hgtools/issue/23/add-a-more-liberal-license indicating that you release setuptools_hg 0.2 under the MIT license as well? I don't think the code base shares any lines, but I want to be sure.

[17:08:53] <jezdez> jaraco: sure thing

[17:09:02] <Ivo> the source code is linking with a gpl library, qed that source code, if distributed to ppl, has to be distributed under gpl

[17:09:22] <tomprince> "linking"

[17:09:43] <Ivo> from mercurial import x is pretty much linking in python's case

[17:10:21] <tomprince> Also, under the GPL, or under compatible license?

[17:10:59] <Ivo> at least gpl

[17:11:43] <tomprince> It isn't clear to me that distributing something that doesn't include the mercurial code triggers the GPL license of that code.

[17:11:46] <jezdez> gosh GPL is such a PITA

[17:12:38] <Ivo> tomprince: its making substancial use of gpl code

[17:12:56] <Ivo> well its whole point is to be viral and unavoidable

[17:13:12] <Ivo> so if you want your free software to be absolutely unavoidably free, use gpl

[17:13:24] <dstufft> VanL had an awesome comment about this

[17:13:32] <dstufft> on jacobkm's blog

[17:13:38] <dstufft> but then jacob killed his blog comments

[17:13:41] <dstufft> and now it's gone ;(

[17:13:45] <Ivo> lol

[17:14:30] <dstufft> the tl;dr was something like, it's never been tried in court of ``import gplthing`` triggered the GPL or not, the conservative answer is that importing ~= linking and it does IIRC

[17:15:00] <Ivo> hangon

[17:15:04] <tomprince> http://web.archive.org/web/20091216063355/http://jacobian.org/writing/gpl-questions

[17:15:04] <Ivo> maybe i remember wrong

[17:15:24] <Ivo> yeah i remember wrong

[17:15:25] <dstufft> https://web.archive.org/web/20121113180205/http://jacobian.org/writing/gpl-questions/

[17:15:27] <dstufft> er

[17:15:30] <dstufft> lol tomprince

[17:15:32] <dstufft> way to beat me

[17:16:19] <Ivo> no i was right

[17:16:31] <jimbaker> dstufft, so i saw the pypy may ship with ensurepip (i assume for 2.7 support). this might be a good idea for jython 2.7...

[17:16:39] <Ivo> lgpl lets you link with whatever license you want, gpl does not

[17:16:41] <jimbaker> any thoughts?

[17:17:27] <tomprince> Ivo: The kernel has a bunch of MIT/BSD code in it. The combined work is covered by GPL, but the individual parts aren't.

[17:17:49] <Ivo> tomprince: that's what I mean by 'at least'

[17:18:16] <Ivo> it has to be available under gpl, but can be available under other things too

[17:18:45] <tomprince> The original question was wether having 'import mercurial' made the code GPL, or whether it could just be licensed as MIT (which is compatible with the combined work being GPL.

[17:21:15] <Ivo> the question is if its regarded as significantly derivate work, then it must be under gpl. conservatively since you import from gpl library and make use of a large part of its functionality in your library, then you're a derivative work

[17:21:47] <Ivo> although certainly not a settled issue https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works

[17:24:14] <Ivo> lgpl is basically gpl with this issue cleared up by explicitly saying linking doesnt infect it

[17:28:24] <Ivo> i suppose you could argue that its only dynamic linking and dynamic linking doesn't neccesitate infection

[17:32:00] <jezdez> jaraco: nice, using sys.modules as a way to not import it :D

[17:32:02] <jezdez> https://bitbucket.org/jaraco/hgtools/commits/ef154d702d6d

[17:33:41] <jaraco> Thanks. I think that will satisfy licensing restrictions, but if there are complaints, I'll just remove that functionality. It's disabled by default anyway because its sandboxing conflicts with setuptools sandboxing (I think).

[17:34:38] <Ivo> its always funny to know that someone would actually have to sue you in court over hgtools for any of this to matter :D

[17:35:45] <Ivo> hmmm.. s/funny/ambivalent

[17:37:14] <dstufft> jimbaker: sorry I had a meeting

[17:39:00] <dstufft> jimbaker: I was actually planning on asking you about that once pip was working there. I wasn't sure what Jython's policy was regarding backporting things from 3.x to 2.x, but yes the ensurepip was 2.7 compat in PyPy

[17:39:22] <dstufft> ensurepip itself is pretty small, ~200CLOC or so

[17:42:36] <jezdez> jaraco: thanks for taking care of setuptools and hg integration

[17:45:54] <jimbaker> dstufft, awesome, that should just work then

[17:46:07] <jimbaker> for stuff like pip, we do not mind backporting - it will help with usability

[17:46:38] <dstufft> jimbaker: I'm assuming ZipImport works on Jython at least

[17:46:45] <jimbaker> dstufft, yes

[17:46:49] <dstufft> if it doesn't it's stil dosable, will just require extra effort

[17:46:50] <dstufft> ok

[17:47:17] <jimbaker> dstufft, there are the usual exceptions. so for jython, this means zipimport cannot include jars

[17:47:24] <dstufft> all ensurepip really does is shove a bundled pip wheel (and setuptools wheel) onto sys.path (all a .whl really is, is a zip file) and then import's pip and uses pip to install itself

[17:47:36] <jimbaker> i suppose this could be relaxed but irrelevant to ensurepip

[17:47:42] <jaraco> jezdez, Glad to help. It's a team effort.

[17:47:47] <jezdez> :)

[17:48:04] <Ivo> dstufft: does it do that cert-file extraction dance as well?

[17:48:10] <jimbaker> dstufft, that should just work. wheel support proved to be a matter of updating our distutils

[17:48:16] <jimbaker> from core python 2.7

[17:48:25] <dstufft> Ivo: Nope, ensurepip doesn't touch the network

[17:48:37] <dstufft> it does the equvilant of pip install path/to/pip.whk

[17:48:40] <dstufft> whl

[17:49:22] <dstufft> for CPython the bundled pip gets updated even in maintenance releases

[17:49:22] <Ivo> oh.. right, yeah

[17:49:23] <jimbaker> so ensurepip is just a bundling - one more thing in the stdlib, but ensures upgradeability of pip itself

[17:50:10] <dstufft> jimbaker: yea, the reason we didn't just shove pip in the stdlib is because pip (and packaging as a whole) is moving fast, and as we learned with distutils, baking things into the life cycle of Python means that improvements to the tooling aren't actually useful for a *long* time

[17:50:20] <Ivo> includes a pip package internally, and then installs it into a site-packages if needed

[17:50:34] <dstufft> yup

[17:50:43] <dstufft> and we can update the bundled one in maintenance releases

[17:50:45] <jimbaker> dstufft, right, we decided to do the same thing with a bunch of new java integration support

[17:50:52] <jimbaker> which of course requires pip

[17:51:22] <tomprince> jezdez jaraco: That commit looks like meaningless sophistry.

[17:51:25] <jimbaker> (this is our jythontools project)

[17:51:35] <Ivo> jimbaker: some distros have chosen to remove ensure-pip, but always have their distro pip package be installed if python is installed

[17:51:38] <dstufft> jimbaker: I love smaller stdlibs and a helathy ecosystem

[17:51:39] <jimbaker> dstufft, timing wise: beta 3 will be released by end of week

[17:51:50] <jimbaker> i would like for ensurepip to be in beta4

[17:51:55] <jaraco> tomprince, I don't think it is. It specifically requires the client to import mercurial in _their_ code, meaning they're doing the linking.

[17:52:13] <dstufft> jimbaker: my guess is that Jython will be able to more or less just lift the PyPy patch up wholesale, modulo moving paths around

[17:52:16] <jaraco> But then again, maybe you're right.

[17:52:23] <dstufft> the CPython patch used a 3.x only thing or two

[17:52:35] <jimbaker> dstufft, we routinely borrow freely from pypy for this sort of thing ;)

[17:52:55] <dstufft> the distros that have removed ensurepip will likely be adding it back

[17:52:59] <jaraco> But i consider the problem small enough, the integration minimal enough, and the impact of removing the code negligible, so if it comes to it, that's what I'll do.

[17:53:11] <dstufft> the big one I know of are Debian/Ubuntu - and they are just doing policy lawyering

[17:53:17] <jimbaker> so the biggest thing will be just to have a working pip also bundled in for beta 4, which is maybe 2 months out for jython

[17:53:26] <dstufft> jimbaker: sounds reasonable to me

[17:53:34] <dstufft> I want to get the PyPy patch done in the next day or two

[17:53:41] <jaraco> In any case, my intention is clearly documented in the ticket and referenced in the changelog, so if anyone wants to complain, there's full transparency of intent.

[17:53:53] <dstufft> so at that point all Jython would need is for pip to actually work on Jython

[17:54:05] <jimbaker> i think the vendor lib pull request i made for html5lib-python looked good, so hopefully that will get through quickly

[17:54:26] <dstufft> Once they do a release I can probably do another 1.5.X release to bump html5lib

[17:54:33] <jimbaker> https://github.com/html5lib/html5lib-python/pull/150

[17:54:36] <dstufft> I dunno when 1.6 will be out

[17:54:39] <tomprince> jaraco: I'm not sure that change is enough to get around any potential GPL restrictions.

[17:55:05] <jimbaker> dstufft, cool, glad this is finally coming together!

[17:55:09] <jaraco> tomprince, acknowledged. You may be right.

[17:55:20] <jimbaker> and also thanks for the ensurepip guidance - looking forward to bundling it!

[17:55:36] <tomprince> jaraco: But as I said, I don't think that the code itself needs to be covered by the GPL.

[17:56:08] <tomprince> Perhaps any use of it would, and I'd be leary of trying to distribute it under a more restritive license without talking to a lawyer.

[17:57:07] <jaraco> tomprince, I'd agree. I also could easily argue that by using the _exact same interface_ as the subprocess invocation, that it's really not linking at all, just entering the same logic in-process rather than as a subprocess.

[17:58:41] <tomprince> I'd say just license the code as MIT (or whatever), but maybe put a warning that because the code imports mercurial, using it may be subject to the GPL.

[17:58:51] <tomprince> Or ... just ask VanL?

[17:59:05] <jaraco> I've pinged him in the ticket, so he may choose to comment.

[18:01:09] <Ivo> im not sure if his answer would have changed from what was linked above

[18:01:32] <Ivo> always 'maybe' until some court cases come up (yay!)

[18:03:36] <tomprince> Ivo: He also said it depends on the specific circumstances, which this is. Also, that was general legal advice to all and sundry, rather than a specfic legal recomendation.

[18:56:45] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[18:56:45] <pmxbot> Add Python 3.4 as a testable version. Bump version pulled in bootstrap test.

[20:27:18] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[20:27:18] <pmxbot> Just suppress the spurious IndexError when it happens. Rely on the environments where the behavior doesn't fail until the upstream issue can be resolved. Fixes #201.

[22:13:10] <dstufft> "Things like pip and virtualenv make working with Python packages generally pleasant, but as a total beginner, I felt lost until I found PUG"

[22:13:15] <dstufft> /cc qwcode

[22:13:54] <qwcode> dstufft, where is that from?

[22:14:02] <dstufft> an email that was sent to me

[22:14:18] <dstufft> I can forward it to you if you want to see the whole thing

[22:15:02] <qwcode> sure, if you want.

[22:15:11] <qwcode> "PUG", what a name

[22:15:36] <qwcode> I need some motivation to keep filling in the holes...

[22:15:42] <dstufft> what's your email?

[22:16:03] <qwcode> qwcode@gmail.com

[22:16:14] <Ivo> dstufft: is it postable online anonymised

[22:16:54] <dstufft> Ivo: yea, I'm just lazy and it had hyplinks

[22:16:56] <dstufft> I can do that too

[22:17:23] <Ivo> I supposed that's mostly work done by qwcode

[22:17:25] <Ivo> !m qwcode

[22:17:25] <pmxbot> you're doing good work, qwcode!

[22:18:15] <qwcode> thanks pmx

[22:19:42] <Ivo> Half Life 2 is ten years old!

[22:21:16] <qwcode> this section has some of the most promise I think for helping people "in the real world of deployment" http://packaging.python.org/en/latest/deployment.html

[22:21:31] <qwcode> not sure people realize the PUG is attempting that topic

[22:21:58] <qwcode> the problem is everyone is still figuring that out, including me

[22:22:01] <dstufft> Ivo: https://gist.github.com/dstufft/876b1fc9154ba0040171

[22:23:39] <Ivo> people deploying stuff should just not need binary packages, then everything would be fine.

[22:24:52] <qwcode> even ignoring external dependencies, you still have to decide what method to choose to deploy your app as part of your SDLC.

[22:26:28] <qwcode> even assuming you're using CFM (puppet, chef etc..), you have to sort our whether you'll bundle it as an rpm, or use some kind of module for building out virtualenvs

[22:26:32] <Ivo> dstufft: that's a cool little project of theirs!

[22:28:16] <Ivo> docker is the hip way to package things these days right

[22:28:19] <qwcode> ftr, I asked tarek to pull down the HHGTP. that would help

[22:28:51] <qwcode> yea, docker should have a place on that page too

[22:29:17] <Ivo> I bet there would be quite a few internet links points to HHGTP

[22:29:24] <Ivo> *pointing

[22:29:32] <qwcode> a redirect would be best.

[22:29:52] <qwcode> jaraco, you don't have control over http://guide.python-distribute.org/?

[22:30:05] <Ivo> tarek owned the domain

[22:30:49] <Ivo> i remember asking him to renew it last year ^_^

[22:31:04] <Ivo> or maybe the hosting

[22:31:22] <qwcode> the PUG is linked here https://www.python.org/doc/

[22:31:32] <qwcode> that's pretty authoritative

[22:31:47] <qwcode> but that doesn't help google searches

[22:32:05] <Ivo> I thought http://python-distribute.org/distribute_setup.py being down might make people angry

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Monday the 5th of May, 2014