[05:35:33] [connected at Wed Apr 18 05:35:33 2007] [05:35:34] <> *** Looking up your hostname... [05:35:34] <> *** Checking ident [05:35:34] <> *** Found your hostname [05:35:34] <> *** No identd (auth) response [05:35:34] <> *** Your host is sterling.freenode.net[freebsd.widexs.nl/6667], running version hyperion-1.0.2b [05:35:35] [I have joined #peak] [11:47:42] ** apoirier has joined us [11:54:55] ** pje has joined us [13:26:26] ** apoirier has left IRC ("KVIrc 3.2.0 'Realia'") [13:53:43] ** zooko has joined us [13:53:46] ** coderanger_ has joined us [13:54:19] Greetings, people of #setuptools. [13:56:04] Alo [14:12:13] I'm packaging up a couple of projects for open source distribution, and I have some questions about setuptools. [14:12:31] I'm pretty much happy with distutils, except that there's no standard way to invoke the package's unit tests. [14:12:59] So I mentioned to my partner that setuptools has a standard way to invoke tests, but this led us to the question of whether we want to use setuptools in general. [14:15:57] mhmm [14:16:32] I have traditionally avoided setuptools in packages that I *use* from other people. [14:16:36] Which is getting harder and harder to do... [14:16:37] ;-) [14:16:43] Why? [14:16:44] ... because it conflicts with GNU stow. [14:17:04] And, in my opinion, the reason that it conflicts is a rather deep disagreement between my philosophy and setupttools's philosophy. [14:17:16] Namely, that I think objects are not allowed to impose requirements on their names/locations. [14:17:31] The name that I use to refer to something is up to me, not up to it. [14:17:54] This comes out when you try to use GNU stow, as the name that I am going to use is going to be /usr/local/lib/python2.5/site-packages/thingie. [14:18:04] Given that Stow's last release was 5 years ago, I think thats somewhat inevitable [14:18:12] But setuptools *thinks* that it is going to be /usr/local/stow/thingie/lib/python2.5/site-packages/thingie [14:18:55] Likewise, we have two projects here that we are open sourcing. [14:19:05] The former, zfec, is used by the latter, tahoe. [14:19:15] The way we currently do this is that we use distutils and use the [14:19:39] --install-lib and --install-scripts features to install zfec in a particular place, [14:19:46] and then tahoe adds that particular place to its PYTHONPATH. [14:20:15] Again, this is, philosophically, that the user of zfec gets to determine that name/path that it will use to denote zfec, and zfec itself is oblivious to what name/path is used to refer to it. [14:20:42] Okay, why doesn't that work with setuptools? [14:20:49] ... [14:20:50] Hm. [14:21:00] I must misunderstand -- I thought that setuptools would... [14:21:01] * zooko thinks. [14:21:16] It should fail for the same reason that setuptools with --prefix=/usr/local/stow/thingie fails, but I haven't actually tried it. [14:21:22] I think I'll go try it and report back. [14:26:16] You can install the .egg file where ever you want [14:26:53] Hm. [14:27:09] Then why does it fail when I try to install something with --prefix=/usr/local/stow/thingie ? [14:27:44] By the way, "#!python" doesn't work on my platforms as the shebang line, but "#!/usr/bin/env python" does. [14:28:50] Hm. I think that I really want tahoe's import of zfec to be through the Python builtin loader, and not through the egg loader. [14:30:30] The egg loader is part of the default loader ... [14:31:33] I'm sorry, I obviously misunderstand this whole setuptools idea. [14:31:41] Perhaps I should just report back after giving it a whirl. [14:32:00] My goal is to retain pretty much the exact same kind of control and minimal level of dependencies that I currently have, while [14:32:07] (a) getting an standardized way to invoke tests, and [14:32:24] (b) making it easy for people out there who prefer setuptools to use it with my packagees. [14:36:23] setuptools makes that no harder distutils, while making a and b possible [14:58:31] Great! [18:30:54] ** coderanger_ has left IRC ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007030919]") [19:37:38] zooko, FYI, setuptools packages can be installed in a backward-compatibility mode where they are just like the distutils [19:37:59] but with an extra .egg-info directory that gets put alongside to hold the package's metadata. [19:43:59] pje: thanks for the information. [20:23:59] ** pje has left IRC ("Client exiting")