[01:52:35] ** fengee has left IRC (clarke.freenode.net irc.freenode.net) [01:55:54] ** fengee has joined us [04:18:20] ** bitmonk has left IRC () [05:28:27] [connected at Mon Mar 17 05:28:27 2008] [05:28:27] <> *** Looking up your hostname... [05:28:27] <> *** Checking ident [05:28:27] <> *** No identd (auth) response [05:28:27] <> *** Found your hostname [05:28:27] <> *** Your host is clarke.freenode.net[clarke.freenode.net/6667], running version hyperion-1.0.2b [05:28:29] [I have joined #peak] [05:28:29] ** clarke.freenode.net set the topic to does anyone remember the real topic ? - not really ... [05:56:13] ** fengee has left IRC (Remote closed the connection) [06:26:50] ** apoirier has joined us [10:40:16] ** jfincher has joined us [10:40:31] anyone around to answer questions about eggs? [10:43:08] I've got one package X which is distributed as an egg and depends on package Y. Package Y I have installed via my OS package management, which does not install an egg. So setuptools is refusing to load package X because it thinks package Y isn't installed. Is there a way to resolve this without rebuilding package Y as an egg? [11:22:54] Howdy jfincher. [11:30:29] zooko is now known as zookoafk [11:35:54] hola, zooko [11:57:48] zookoafk is now known as zooko [11:57:54] ** pje has joined us [12:07:30] pje: you in? :) [12:07:39] yes? [12:07:48] I'm having an egg problem, you seem to be the reasonable person to seek out. [12:08:31] What needs to be done when I have software X, which is distributed via eggs, which depends (in requires.txt) on software Y, which is installed via the OS' package distribution (RPM, in this case) [12:09:26] I'm going to guess that you're using Python <2.5, or one of the OS distros that strips out egg metadata. [12:09:35] is there a workaround apart from building an egg for software Y? [12:09:42] yeah, using 2.4 [12:09:50] and the RPM doesn't install an egg [12:09:59] (and it doesn't seem trivial to make it do so) [12:10:00] Create an .egg-info file for Y, as a renamed copy of Y's PKG-INFO file [12:10:26] and put it in the directory that Y is imported from - *alongside* Y, not inside Y [12:10:26] where does that .egg-info file go? [12:10:36] i.e., in site-packages? [12:10:40] Yes [12:11:10] and it needs to be named correctly. What's Y's real name and version? [12:11:40] numpy 1.01 [12:11:42] er, 1.0.1 [12:12:06] ** bitmonk has joined us [12:12:59] pje: btw, if I missed documentation for this problem, feel free to refer me to it directly, I don't mean to take any time of yours that I don't need. [12:13:17] okay so the file should be called numpy-1.0.1-py2.4.egg-info [12:13:30] In truth, you could probably just create that as a zero-length file and have it work [12:13:52] but if you later use any third-party egg inspection tools they might balk at the lack of metadata [12:14:56] Howdy pje. Were you at Pycon this year? [12:15:13] nope [12:15:25] I'm mildly surprised. [12:15:42] pje: by the way, is there a way that I can unpack an egg in site-packages and modify its source easily? I don't like the opaque nature of eggs (and sometimes has local tweaks I need to try out) [12:17:13] jfincher: set your distutils config file to prefer to always unzip. [12:20:57] man, I really don't understand why this software is such a pain. [12:21:08] if you knew how busy I was, you wouldn't be surprised at all, zooko [12:21:10] (matplotlib) [12:21:28] zooko: were you there? How accurate the reports that it was over-commercialized? [12:21:43] How accurate *were* the reports, that is [12:24:40] pje: glad to hear that you are busy -- I suppose this means getting laid off from OSAF isn't too bad for you. [12:25:00] I wasn't laid off. [12:25:02] jfincher: I was there. I didn't attend very many talks. [12:25:09] That's one of the reasons I'm so busy. :) [12:25:25] pje: Ah yes. Looking for a job is a full-time job. [12:25:33] Wha? [12:25:43] I still work full time at OSAF. [12:25:54] jfincher: I noticed people getting tired of the lightning talks featuring sales pitches and solicitations for employees. [12:26:02] pje: oh, I thought you were let go. [12:26:05] I'm busy because I have another whole business, plus nine jillion open source projects [12:26:22] I guess I was confused by the fact that OSAF has effectively defunded its contribution to setuptools/pkg_resources. [12:26:27] nope -- OSAF is funding Trellis work [12:26:34] Oh, that's interesting. [12:26:45] setuptools was already adequate for OSAF's needs like a year ago [12:26:45] I'm rather disappointed about this new (to me) direction re: pkg_resources. [12:26:58] I have already set in motion plans based on the belief that pkg_resources was going into Python >= 2.6. [12:27:12] Although actually those plans will not be harmed by having to install it separately. [12:27:18] but they had to cut my time from setuptools support, which actually was a lot of my time. [12:27:39] Still, I really want wider convergence on your packaging tools/package metadata format/etc.. [12:27:46] Don't worry about the new direction just yet... it's still all up in the air. [12:27:57] discussion w/Guido and others is ongoing [12:28:02] * zooko nods. [12:28:19] To be clear: managing a dependency on pkg_resources separately from the stdlib is no problem for me. [12:28:22] And if someone credible steps up to support pkg_resources in the core, it could still happen [12:28:38] The reason I care is that inclusion of pkg_resources in the stdlib makes other people think that pkg_resources is a standard tool that they should support. [12:28:47] Jim Fulton may yet weigh in [12:29:02] Packaging is one of those things where the greatest value comes from the widest ecosystem of people agreeing to use it. [12:29:17] I momentarily considered volunteering to (help) maintain it, but then I thought the better of it. [12:29:21] I suspect, though, that 2.6 is too far ahead relative to Zope Corp's current needs/commitments for the payoff to be there for them [12:29:41] zooko: I think many people still consider packaging to be the realm of the OS distribution, not the language implementation. [12:29:49] jfincher: I know. [12:29:56] Well, like I said, just look at the SVN log for the thing... it's not exactly high-maintenance [12:30:14] pje: I don't have a full understanding of it, but I'm sure I could have if needed. [12:30:34] Anywho, I'm rapidly approaching "volunteer burnout" on anything whatsoever to do with setuptools. [12:30:39] But I, too, have several open source projects on the go. [12:30:42] It's like juggling. [12:31:02] pje: Hm. I wonder if you burning out could turn the tide against it. [12:32:54] On the other hand, if you successfully transfer maintainership then it could help by separating in people's minds the community-maintained tool from the PJE personality. [12:35:14] Hm... [12:35:19] Yes, this could be good. [12:35:31] Too bad I didn't know about your near-burnout before pycon. [12:35:38] Well, keep making remarks like that and you'll certainly accelerate the burnout process. :) [12:35:50] * zooko winks. [12:36:25] Here's a remark for you: you have done an excellent job of creatively advancing the state of the art, and many people over the whole world have benefitted from your contribution. Thank you! [12:37:55] Yeah, well, that's why I have another business: in that one, the ratio of thank-you's to people helped is a lot nearer 1:1; in fact, it's usually >1:1 [12:40:14] You are still deserving of receiving a Thank You Gift from allmydata.org. [12:40:16] You declined last time. [12:40:31] Yep, no need. [12:40:31] There are three other people who are going to receive one soon, and one person who has already received one. [12:40:48] ** bitmonk has left IRC () [12:40:52] It's not really the absence of thanks that's the burnout factor w/setuptools. It's the asshat factor that does it. [12:40:55] So act now to make your Allmydata.org Thank You Gift Number lower! [12:40:57] ;-) [12:41:02] Ah yes. That factor. [12:42:11] So, in my opinion, .egg-info and setuptools are past the point where individual creative drive are necessary to break through "Stop Energy". [12:42:30] And now they are in the point where becoming a community-owned, consensus-governed, conservative, stable point would be fine. [12:43:10] So this might be a good point to transfer it from a PJE project to some sort of community consensus project. [12:43:37] Since python 2.5 distutils produces .egg-info's, we have a stable point of consensus. [12:51:18] zooko is now known as zookoaway [14:37:37] ** bitmonk has joined us [14:38:36] ** bitmonk has left IRC (Client Quit) [14:42:55] ** bitmonk has joined us [14:51:49] zookoaway is now known as zookoafk [14:54:56] ** apoirier has left IRC ("KVIrc 3.2.6 Anomalies http://www.kvirc.net/") [15:24:19] zookoafk is now known as zooko [17:06:18] I think that the political conflict about eggs can be somewhat resolved by changing easy_install to play more nicely with others, in a few small ways. [17:06:42] I have asked several accomplished Python hackers why they refuse my patches which add easy_install compatibility or setuptools features to their projects. [17:06:47] And I've taken notes on their answers. [17:07:15] The big picture is: we don't have to all agree to use eggs or all agree to not use eggs. [17:07:39] Instead, we can make eggs more compatible with other alternatives. (And other alternatives more compatible with eggs.) [17:07:53] The small picture is: a few minor changes, some of them so minor as to be purely symbolic. [17:07:58] But symbols matter. [17:12:00] pje: please update the setuptools docs to suggest that people use the "Frameworks :: Setuptools Plugin" classifier. I will submit a patch against the HTML page if you like. [17:12:54] please patch against setuptools.txt @ http://svn.python.org/projects/sandbox/trunk/setuptools/ [17:13:02] not against the HTML [17:15:41] Ok. [17:22:30] Hm. I was thinking of "Frameworks :: Setuptools Plugins" as being for packages which extend setup.py itself. [17:22:47] Although the setuptools plugin mechanism can be used for other things entirely, I guess, such as parsers for a blog tool. [17:23:36] So shall I add a line that says something like "If you create a plugin which extends setup.py scripts with new development tools, then please include the classifier 'Frameworks :: Setuptools Plugins' in its metadata."? [17:28:51] Sheesh. Check out this stack trace: http://allmydata.org/buildbot/builders/dapper/builds/1391/steps/compile/logs/stdio [17:29:07] home/buildslave/slave-tahoe/dapper/build/misc/dependencies/setuptools-0.6c7.egg [17:29:07] invokes [17:29:08] /usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/easy_install.py [17:29:12] which in turn invokes [17:29:14] /home/buildslave/slave-tahoe/dapper/build/misc/dependencies/setuptools-0.6c7.egg [17:29:57] And how does PIL/__init__.py manage to invoke nevow/_version.py ? [17:30:00] Further discussion in #mnet... [18:42:02] zooko is now known as zookoafk [18:51:37] zookoafk is now known as zooko [19:02:33] zooko is now known as zookofamilytime [19:14:41] zookofamilytime is now known as zooko [19:28:45] zooko is now known as zookodinnertime [20:10:26] zookodinnertime is now known as zookofamilytime [20:45:05] zookofamilytime is now known as zooko [21:23:08] ** pje has left IRC ("Client exiting") [22:00:19] zooko is now known as zookoaway [22:06:37] zookoaway is now known as zooko [22:14:01] zooko is now known as zookosleep