[05:29:39] [connected at Tue May 29 05:29:39 2007] [05:29:39] <> *** Looking up your hostname... [05:29:39] <> *** Checking ident [05:29:39] <> *** No identd (auth) response [05:29:39] <> *** Found your hostname [05:29:39] <> *** Your host is anthony.freenode.net[anthony.freenode.net/6667], running version hyperion-1.0.2b [05:29:41] [I have joined #peak] [12:01:46] ** pje has joined us [12:05:32] I have a conundrum. [12:05:45] I distribute a free-software library and command-line, tool, "zfec". [12:06:40] It uses some features from another library, "pyutil". [12:06:52] Currently, I have cp'ed the relevant modules from pyutil into zfec/util/. [12:07:39] Which means that people can download and use zfec without being aware that there are "dependencies" of it. [12:08:12] However, obviously, now I have a headache with version skew -- pyutil gets improved or changed, and I want zfec to use the new version, so I have to manually "cp" or merge the changes from the pyutil library into zfec/util. [12:09:11] I would be interested in using setuptools to automate the satisfaction of zfec's dependencies, but only if I can *bundle* a copy of pyutil with the zfec download, so that the dependency can be satisfied without another connection to the network. [12:09:44] E.g., so that if somebody downloads the zfec downloadable onto their laptop, then goes to a place with no Internet connection, and then installs zfec from the result of the download, that the install works. [12:09:47] Any ideas? [12:33:30] Are both libraries using Subversion? If so, you can use svn:externals [13:26:45] You could include a source distribution of the other package in your own source distribution (as a nested .tgz), and use a file:// in dependency_links [13:29:03] you might have to programmatically generate the file:// URL, though. [13:29:32] But anyway, setuptools would then be able to meet the dependency by unpacking the nested tarball. [14:38:45] coderanger: some users might not have subversion or might not have access at the time that they install. [14:38:51] pje: okay, thank you for the idea! [14:39:36] Hm. The problem is that the version of pyutil that I ship with zfec may conflict with a different version of pyutil already installed on the user's system. [14:39:37] * zooko sighs. [14:39:59] so? [14:40:11] So how will zfec know which one to import, for starters. [14:40:13] If they are both installed. [14:40:20] Or if they aren't both installed, which one gets installed? [14:40:38] well, your scripts will all import the version you need. [14:40:55] If the user has any scripts that depend on a different version, those scripts will import that version. [14:41:02] How do they specify which version of zfec to import? [14:41:08] in their setup.py [14:41:15] Ideally, they would do so because it would be installed in a local namespace that is invisible to the external system... [14:41:34] Using the version number to distinguish? [14:41:36] I see. Thanks. [14:41:36] you're reinventing wheels -- setuptools handles all this, for the packages it manages [14:42:48] Using the version number for this is unsatisfying in general, but good enough for now. [15:49:36] ** pje_ has joined us [16:07:35] ** pje has left IRC (Read error: 110 (Connection timed out)) [16:18:14] pje_ is now known as pje [17:54:21] ** pje_ has joined us [18:11:30] ** pje has left IRC (Read error: 110 (Connection timed out)) [18:23:11] pje_ is now known as pje [18:38:48] ** pje_ has joined us [18:52:31] ** pje has left IRC (Read error: 110 (Connection timed out)) [20:06:38] pje_ is now known as pje [21:27:12] ** pje has left IRC ("Client exiting")