[00:08:55] ** apauley has left IRC (Read error: 60 (Operation timed out)) [01:12:05] ** apauley has joined us [03:38:23] Hi, anyone alive in here? [04:02:25] [connected at Mon Jan 31 04:02:25 2005] [04:02:25] <> *** Looking up your hostname... [04:02:25] <> *** Checking ident [04:02:26] <> *** Found your hostname [04:03:06] <> *** No identd (auth) response [04:03:06] <> *** Your host is tolkien.freenode.net[thunder.stealer.net/6667], running version dancer-ircd-1.0.35 [04:03:06] [I have joined #peak] [04:03:06] ** tolkien.freenode.net set the topic to http://dirtsimple.org/2004/11/generic-functions-have-landed.html [09:21:47] ** vlado has joined us [09:22:58] ping [09:23:26] pong [09:24:15] Hi vlado, glad to someone alive in this room [09:25:16] Are you developing PEAK apps? [09:27:30] yes, but nothing in production yet ;) [09:51:51] What type of application? [09:52:21] I'm evaluating PEAK in order to write a point-of-sale application [09:52:44] that should plugin to the company's existing ERP backend [09:53:35] If this initial project is successful there's a chance that we'll rewrite more ERP components in Python [10:04:22] PDM App [10:07:06] PDM? [10:08:55] product data management [10:28:26] ** bear_ has joined us [10:52:30] Hi bear_ [10:59:45] hi [11:02:56] bear_: What's your involvement with PEAK? [11:03:13] Developing an app, or helping with PEAK dev? [11:03:38] lurking mostly [11:04:09] etrepum and pje were discussing some distutil work for plugins [11:04:37] vlado: Have you discovered any pitfalls that I should look out for? [11:04:58] Or missing features that would make your life easier? [11:05:30] bear: I started writing some code, and the wiki page has been updated [11:06:09] etrepum, excellant - I [11:06:26] 'll take a look after I clearn my monday morning tech support queue [11:06:37] basically I wrote about 80% of the code you need to use plugins given the specifications we have so far, but no code to make them [11:06:45] :) [11:07:38] I also extended the implementation so that it can support "flavors" of plugins, like if an .egg was just a directory [11:07:55] different packing styles then [11:08:07] file-based eggs have a signature registry, right now only zip-eggs are implemented with a signature of 'PK\x03\x04' [11:08:34] and I left those mechanisms exposed as module-global dicts in case the containing application wants to be tricky [11:09:39] the resource loading code should work for packages that are not eggs too, so for development you shouldn't need to egg something in order to use resource_stream(...), etc. [11:09:53] * bear_ nods [11:10:00] makes dev testing much easier [11:10:23] well not so much, but it makes compatibility easier [11:10:53] for dev testing you simply make a symlink named myegg-py2.3-1.0.egg to your src directory [11:11:28] * bear_ nods [11:11:57] I was thinking more of the "dev testing that the distribution code works" testing [11:12:11] but either way - makes life easier [11:13:15] yeah [11:13:23] apauley: collections and sequences are computer on first access, not on the fly and maybe there will be problems with the speed of the app if they are very large ... dunno [11:40:06] ** vlado has left IRC ("Leaving") [11:49:35] ** apoirier has joined us [12:34:59] ** apoirier has left IRC ("Using KVIrc 3.0.1") [12:51:41] ** pje has joined us [12:51:48] * pje waves [12:54:46] * pje looks at etrepum's implementation of the egg runtime [12:55:03] it's not finished yet, of course, but it does Do Some Stuff [12:55:11] and it needs tests in a bad way [12:55:24] Yeah, I thought I might cleanroom it. [12:55:45] Actually, I suppose dirty room it would be more accurate. :) [12:55:48] cleanroom test it, or write another implementation? [12:56:02] I mean, write tests and copy code from the original to make the tests pass. [12:56:11] ah [12:56:16] Thus "proving" that all lines are covered by tests. [12:56:27] I notice that there are lines in the current version that never execute, for example. [12:57:17] yeah of course [12:57:41] I meant like the default for when archive is None, but archive should never be None. [12:58:16] On an unrelated note, I'm not sure that cleanup() should be disallowed for the main resource manager. [12:58:18] actually that is so that it can support legacy packages [12:58:30] cleanup is disallowed for the main resource manager with the default path [12:58:33] Aren't those handled by the DirDistribution? Or am I misunderstanding. [12:58:56] the loader might not be a DirDistribution [12:59:09] Yeah, but DirDistribution has a non-None archive, doesn't it? [12:59:21] might *not* be a DirDistribution [13:00:15] I never really intended archive to be a public attribute except for the ZipDistribution, though. [13:00:36] it's useful for DirDistribution though [13:00:45] * pje nods [13:00:48] any flavor of egg should have one [13:00:58] anyway it is to support when there is a loader, but it's not an egg loader [13:01:42] I was thinking we'd check isinstance(loader,Distribution) and if not do dist=DistWrapper(loader) [13:02:00] So that all default behaviors are in a single wrapper/adapter rather than spread out within ResourceManager. [13:02:03] when there is a loader, but not an egg loader or zipimporter, and the file doesn't already exist [13:02:11] that would be fine too [13:02:31] but it's only really used in two or three places and making a DistWrapper that doesn't use __getattr__ would be a pain in the ass [13:02:42] Eh? [13:02:56] more grunt work than I wanted to do [13:02:58] DistWrapper doesn't need that; it would just be distribution methods needed by a resource manager. [13:03:10] Same work you did now, in other words, just in one place. :) [13:03:21] still more lines than what is already there [13:03:47] What you have is fine; we just differ in what things we like to generalize. :) [13:04:02] actually other than that archive thing I really don't know what it would do [13:04:07] For example, you generalized copying of public methods to the module dict, and I'd have just set those by hand. :) [13:04:38] Well, I'd move other behavior from ResourceManager to it; anything that's the "distribution's business" rather than the archive. [13:04:46] rather than the RM I mean. [13:04:48] well I wanted to add functionality to create the global resourcemanager lazily [13:04:51] Like the actual file extraction. [13:05:33] ** sprout has joined us [13:05:40] * pje waves to Ted [13:05:43] so the Distribution, not the ResourceManager should do file extraction? [13:06:00] Yeah. ResourceManager should ensure the directory exists and do locking. [13:06:11] Distribution should check mtime and copy [13:06:30] well I wanted the Distribution to be able to say "hey, I already have a filename" [13:06:39] You mean the RM? [13:06:45] no I mean the Distribution [13:06:47] Yeah, sure, RM caching filename is good, like you have it already. [13:06:59] Right, it still can. [13:07:00] Distribution.get_filename [13:07:23] Yeah, and that routine should do the callback to RM to get a directory, or lock for extract. [13:07:58] The RM owns the extract space, and so should control locking. [13:08:08] the RM is the only thing that extracts [13:08:10] But the distribution knows what resources are eager, so it needs to control extraction [13:08:35] Why shouldn't the RM be able to prod the Distribution's metadata directly? [13:08:44] Because it's none of its business. :) [13:09:00] so each Distribution is allowed to have its own way to do metadata? [13:09:03] Or "Tell Don't Ask", I think is the current catchphrase. [13:09:29] In theory, I suppose. I just prefer TDA because it means I always know what class to look in for the code that does something. :) [13:09:37] * pje is a bit simple-minded :) [13:10:24] I was thinking about refactoring it in that way anyhow, I just didn't want to add all the extra methods last night [13:11:26] Anyway, it looks really good; the only things missing I believe are eager extract, header munging, and locking on Windows, right? [13:11:38] It looked like everything else is done. [13:11:48] Well, version matching, but we didn't actually design that yet. :) [13:11:48] it doesn't do locking anywhere [13:11:55] actually I did design version matching [13:12:05] Yeah, exact match. :) [13:12:20] it is "give it an object that does something useful wtih != against a distutils.version.(Strict|Loose)Version" [13:12:32] True. [13:13:01] and it will always pick the one that sorts highest out of the not un-selected distributions [13:13:18] The not unselected? :) [13:13:21] I didn't make any accommodations for platform specificity [13:13:29] well != doesn't select things, it removes things [13:13:30] Don't need to. [13:13:48] It's the user's (or app's) job to only install compatible stuff [13:13:49] if you have the same package for multiple platforms on your RM path, yeah you do [13:13:58] Hrm. [13:14:15] Well, we can punt on that for 1.0, can't we? [13:14:17] well say you have purelib packages and platlib packages for your application [13:14:33] and your app is distributed in such a way that you have a single download that does everything [13:14:44] Speaking of purelib, does the archive name splitter handle the purelib (i.e. no platform string) naming pattern? [13:14:44] actually nevermind [13:14:51] yes it does [13:14:57] Nevermind what? You lost me there. [13:15:08] Is it not actually a problem for some non-obvious (to me) reason? [13:15:23] the application will add two egg paths, one for purelib and one for platlib [13:15:26] like python does [13:15:35] Ah. [13:15:49] and we can leave it up to the user to do the right thing when installing third party stuff for now [13:16:15] Which will eventually become the app doing the right thing, once we have download metadata for eggs. [13:16:27] it doesn't have any provision to say "i support python >= 2.3" but it does have a provision to say "i support any python" [13:17:07] I think we can live with being tied to specific Python releases; they're only once a year or so, after all. [13:17:08] which is implicitly >= 2.3 since that will be the requirement for the egg runtime [13:18:28] the egg can be named foo-py-version.egg or foo-py2.3-version.egg [13:18:37] the first doesn't care about which python, the second does [13:18:44] iter_distributions doesn't care either way [13:18:46] but require does [13:18:50] Is that the right order? [13:19:12] I thought pkg-version-pyversion-platform was the distutils convention? [13:19:27] it is not the distutils order [13:19:27] or maybe platform-pyversion. [13:20:37] Easier to parse that way? [13:20:42] marginally, yeah [13:21:14] it could probably change [13:21:39] * pje nods [13:21:41] at first I was going to let version be free to be whatever it needed but I later realized that the platform has to go somewhere, and preferably last, because it will be ugly [13:22:16] I'll change it to be foo-version.egg, foo-version-pyversion.egg, foo-version-pyversion-platinfo.egg [13:22:18] Also, I think both version and platform can have '-' in them, which makes things interesting. :) [13:22:29] well we can say don't do that [13:22:36] and sub out - for platform since we control that [13:22:51] I suppose we could convert '-' in both of them to '_'. [13:23:43] yeah, but let's do that with a warning for the version [13:23:58] I was thinking I'd add pkg_resources as a package to the Python sandbox 'setuptools', along with tests for it. [13:24:07] And also put bdist_egg there, of course. [13:24:33] I don't have commit to Python yet.. it would be best if we could put this somewhere that both of us could hack on [13:24:44] should we be annoying and have a warning if they end up defaulting to LooseVersion? [13:25:03] to try and convince people that StrictVersion is The Way, or are there too many projects using non-strict versions? [13:25:25] I think wx is loose; I don't really know how many projects use loose versioning. [13:25:45] Or I guess non-strict. :) [13:25:56] Maybe we should get you commit access to Python. [13:26:21] that's one way [13:26:21] I actually was originally given it so I could work on setuptools, so there's precedence. :) [13:26:31] er, precedent. [13:26:47] My fingers are faster than my brain, this morning. [13:26:57] I could probably get jack jansen, mwh, and JvR to vouch for me w.r.t. Mac support [13:27:12] * pje can't wait to build Chandler's dependencies as eggs, and dump them in its start directory [13:27:46] I can't wait to chuck more py2exe-ish code out of py2app and use eggs instead [13:27:56] Yeah, I notice you're often trying to get patches through the system, so it's not like you don't need the access anyway. :) [13:29:11] putting modulegraph in the sandbox would probably also be a Good Thing [13:29:32] but I definitely prefer svn to CVS [13:29:37] You could even put it in with setuptools. [13:29:53] that's an idea [13:30:02] if you gues need a svn repository to work with let me know - I can set one up on my server [13:30:15] Chances are good that if you need modulegraph, you need other setuptools stuff and vice versa. [13:30:29] Especially with pkg_resources and bdist_egg. [13:30:31] I can get one open on red-bean or codespeak [13:30:40] yeah definitely [13:31:07] * pje went through this last year with setuptools... Python CVS is the place to be. [13:31:32] yeah you're probably right [13:31:36] Remember all the distutils-sig traffic about it? Tim Peters, Fred Drake, and other folks all said, put it in the sandbox, rather than set up another location. [13:31:45] I don't know what the procedure is for begging for commit bit [13:32:07] Me either; but Fred and Tim were the ones who sponsored me for it last year. [13:32:23] bear_ is now known as bear_lunch [13:33:24] I'll ask Jack next time I see him online [13:33:33] ** _pje has joined us [13:33:37] <_pje> We need your OS X expertise, and you've already written maybe half of the runtime. [13:34:56] <_pje> I'm not sure I'm of sufficient seniority to sponsor someone, personally, although I'll certainly vouch for your needing it for this. [13:35:59] Jack would know what the procedure is, he's been around forever and a half [13:37:16] <_pje> Until that comes through, I'd say keep pkg_resources where it is. [13:37:28] <_pje> And I'll work on bdist_egg in the setuptools sandbox. [13:37:38] that works [13:41:56] ** pje has left IRC (Read error: 60 (Operation timed out)) [13:47:28] _pje is now known as pje [13:57:46] pje is now known as pje|afk [14:00:09] Does anyone know of PEAK-based apps that are running live? [14:00:35] Or is PEAK still too much under development for that? [14:01:00] One of Verio's service tracking systems is based on it. [14:01:17] * pje|afk is really going AFK now... :) [14:02:23] Consider putting details of such apps on the web, while going AFK :-) [14:06:18] ** pje has joined us [14:08:03] pje: How suitable would PEAK be for the point-of-sale component of an ERP system? [14:11:29] ** pje|afk has left IRC (Read error: 60 (Operation timed out)) [14:17:59] ** apauley has left IRC ("Download Gaim: http://gaim.sourceforge.net/") [14:19:10] ** apauley|away has joined us [14:29:57] ** _pje has joined us [14:36:00] ** pje has left IRC (Read error: 60 (Operation timed out)) [16:35:22] ** pje has joined us [16:41:27] ** _pje has left IRC (Read error: 60 (Operation timed out)) [17:01:49] ** rdmurray has joined us [17:02:19] ** bear_lunch has left IRC ("Leaving") [19:33:44] ** pje has left IRC ("Client exiting") [20:20:11] ** bear has left IRC (Read error: 60 (Operation timed out)) [20:24:04] ** bear has joined us [21:41:37] ** sprout has left IRC ("Snak 4.13 IRC For Mac - http://www.snak.com")