From guido@digicool.com Wed Feb 21 03:00:20 2001 From: guido@digicool.com (Guido van Rossum) Date: Tue, 20 Feb 2001 22:00:20 -0500 Subject: [Catalog-sig] Python Siphon name change please? Message-ID: <200102210300.WAA08543@cj20424-a.reston1.va.home.com> Sorry for the introsion. I just found out that there's a thing called Python-Siphon being discussed on the distutils-sig (to which I'm not subscribed), which is CPAN functionality. I believe that falls under the Catalog SIG's charter too (to which I *am* subscribed, I believe -- but it's been dead since last November), so I'mm ccing there. I love the concept. But please don't use that name. I searched Google for "python siphon" and found out it is a technical term for something used to siphon water into or out of aquariums (?). That's cute, but makes it hard to find through web searches, and that's not what we want for a CPAN thingie! :-) Feel free to flame me if this is inappropriate! --Guido van Rossum (home page: http://www.python.org/~guido/) From dan@eevolved.com Wed Feb 21 04:44:05 2001 From: dan@eevolved.com (Dan Parisien) Date: Tue, 20 Feb 2001 23:44:05 -0500 Subject: [Catalog-sig] Python Siphon name change please? In-Reply-To: <200102210300.WAA08543@cj20424-a.reston1.va.home.com> References: <200102210300.WAA08543@cj20424-a.reston1.va.home.com> Message-ID: <01022023440502.02532@localhost.localdomain> On Tuesday 20 February 2001 22:00, you wrote: > Sorry for the introsion. I just found out that there's a thing called > Python-Siphon being discussed on the distutils-sig (to which I'm not > subscribed), which is CPAN functionality. I believe that falls under > the Catalog SIG's charter too (to which I *am* subscribed, I believe > -- but it's been dead since last November), so I'mm ccing there. > I love the concept. But please don't use that name. I searched > Google for "python siphon" and found out it is a technical term for > something used to siphon water into or out of aquariums (?). That's > cute, but makes it hard to find through web searches, and that's not > what we want for a CPAN thingie! :-) hehe :) I think that search engines would readjust themselves if Python-Siphon was the chosen name because of the amounts of links that would be created within the context of this project. Still, I am curious as to why that name was chosen; maybe a better one could be found... Dan From guido@digicool.com Thu Feb 22 13:11:41 2001 From: guido@digicool.com (Guido van Rossum) Date: Thu, 22 Feb 2001 08:11:41 -0500 Subject: [Catalog-sig] Re: [Pycabal] FW: [Distutils] Python Siphon name change please? In-Reply-To: Your message of "Thu, 22 Feb 2001 01:45:14 EST." References: Message-ID: <200102221311.IAA15371@cj20424-a.reston1.va.home.com> > Guido van Rossum writes > >Sorry for the introsion. I just found out that there's a thing called > >Python-Siphon being discussed on the distutils-sig (to which I'm not > >subscribed), which is CPAN functionality. I believe that falls under > >the Catalog SIG's charter too (to which I *am* subscribed, I believe > >-- but it's been dead since last November), so I'mm ccing there. > > > >I love the concept. But please don't use that name. I searched > >Google for "python siphon" and found out it is a technical term for > >something used to siphon water into or out of aquariums (?). That's > >cute, but makes it hard to find through web searches, and that's not > >what we want for a CPAN thingie! :-) > > > >Feel free to flame me if this is inappropriate! > > > >--Guido van Rossum (home page: http://www.python.org/~guido/) Robin Becker replied: > Well there was a very long discussion about this on clp, but I guess > dictators don't listen to ordinary folk. I guess the common fate of > dictators is that the masses eventually catch up with them in surprising > ways. Well, I guess I'm getting what I asked for! I did said "please" though. :-) > Siphon seems quite a good name in terms of the etymology and rhyme. If > all new decisions on module name have to be referred to google it'll be > a bit limiting. Sure. I thought this was going to be more than a module though? > Feel free to post an alternate and then we can submit it to google. It seems you've already made up your mind, so I'll back off now. Just one question: I wonder why did this never came up on the catalog-sig. Did we fail to advertise the SIG when it was created? How can we prevent such mistakes in the future? --Guido van Rossum (home page: http://www.python.org/~guido/) From bkc@murkworks.com Thu Feb 22 19:40:45 2001 From: bkc@murkworks.com (Brad Clements) Date: Thu, 22 Feb 2001 14:40:45 -0500 Subject: [Catalog-sig] Re: [Pycabal] FW: [Distutils] Python Siphon name change please? In-Reply-To: <200102221311.IAA15371@cj20424-a.reston1.va.home.com> References: Your message of "Thu, 22 Feb 2001 01:45:14 EST." Message-ID: <3A9524D2.19537.395282F0@localhost> On 22 Feb 2001, at 8:11, Guido van Rossum wrote: > > Siphon seems quite a good name in terms of the etymology and rhyme. If > > all new decisions on module name have to be referred to google it'll be > > a bit limiting. > > Sure. I thought this was going to be more than a module though? > > > Feel free to post an alternate and then we can submit it to google. > > It seems you've already made up your mind, so I'll back off now. > > Just one question: I wonder why did this never came up on the > catalog-sig. Did we fail to advertise the SIG when it was created? > How can we prevent such mistakes in the future? I have nothing to say about the name, but regarding Catalog-Sig: I've been on the list quite a while and I can't remember the last message I got from this list. well, the last message was GVRs questioning of the Siphon name. So .. Is this sig active? Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements From akuchlin@mems-exchange.org Thu Feb 22 19:43:24 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 22 Feb 2001 14:43:24 -0500 Subject: [Catalog-sig] SIG status In-Reply-To: <3A9524D2.19537.395282F0@localhost>; from bkc@murkworks.com on Thu, Feb 22, 2001 at 02:40:45PM -0500 References: <200102221311.IAA15371@cj20424-a.reston1.va.home.com> <3A9524D2.19537.395282F0@localhost> Message-ID: <20010222144324.A1946@ute.cnri.reston.va.us> On Thu, Feb 22, 2001 at 02:40:45PM -0500, Brad Clements wrote: >So .. Is this sig active? The issues were discussed for a while and some initial decisions made (see the archives for my proposed list of metadata fields), but no one has taken a stab at an implementation (until Suchandra's recent posting). Without an implementation to poke sticks at, there's little to discuss at this point. I've also cancelled the Catalog-SIG session on Developer's Day for the same reason. --amk From bkc@murkworks.com Fri Feb 23 18:04:32 2001 From: bkc@murkworks.com (Brad Clements) Date: Fri, 23 Feb 2001 13:04:32 -0500 Subject: [Catalog-sig] SIG status - Siphon name In-Reply-To: <20010222144324.A1946@ute.cnri.reston.va.us> References: <3A9524D2.19537.395282F0@localhost>; from bkc@murkworks.com on Thu, Feb 22, 2001 at 02:40:45PM -0500 Message-ID: <3A965FC3.9758.3E20C1F5@localhost> On 22 Feb 2001, at 14:43, Andrew Kuchling wrote: > On Thu, Feb 22, 2001 at 02:40:45PM -0500, Brad Clements wrote: > >So .. Is this sig active? > > The issues were discussed for a while and some initial decisions made > (see the archives for my proposed list of metadata fields), but no one > has taken a stab at an implementation (until Suchandra's recent > posting). Without an implementation to poke sticks at, there's little > to discuss at this point. I've also cancelled the Catalog-SIG session > on Developer's Day for the same reason. I went through the archives and noticed some postings from myself, so I guess I didn't miss anything. I tried to get myself listed as a "developer" at the siphon sourceforge site, but haven't yet been added by Suchandra. - oh wait, I see I am on the list now. Great! But, the Siphon name isn't going to work I think. http://siphon.sourceforge.net is a SIP soft phone (which is a nice discovery for me since I'm working with the Pingtel xPressa phones) And there's also http://www.subterrain.net/projects/siphon/ Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements From DOUGS@oceanic.com Fri Feb 23 20:32:31 2001 From: DOUGS@oceanic.com (Doug Stanfield) Date: Fri, 23 Feb 2001 10:32:31 -1000 Subject: [Catalog-sig] SIG status - Siphon name Message-ID: <8457258D741DD411BD3D0050DA62365907A65B@huina.oceanic.com> -----Original Message----- From: [mailto:bkc@murkworks.com] Sent: Friday, February 23, 2001 8:05 AM To: catalog-sig@python.org Subject: Re: [Catalog-sig] SIG status - Siphon name On 22 Feb 2001, at 14:43, Andrew Kuchling wrote: > On Thu, Feb 22, 2001 at 02:40:45PM -0500, Brad Clements wrote: > >So .. Is this sig active? > > The issues were discussed for a while and some initial decisions made > (see the archives for my proposed list of metadata fields), but no one > has taken a stab at an implementation (until Suchandra's recent > posting). Without an implementation to poke sticks at, there's little > to discuss at this point. I've also cancelled the Catalog-SIG session > on Developer's Day for the same reason. I went through the archives and noticed some postings from myself, so I guess I didn't miss anything. I tried to get myself listed as a "developer" at the siphon sourceforge site, but haven't yet been added by Suchandra. - oh wait, I see I am on the list now. Great! But, the Siphon name isn't going to work I think. http://siphon.sourceforge.net is a SIP soft phone (which is a nice discovery for me since I'm working with the Pingtel xPressa phones) And there's also http://www.subterrain.net/projects/siphon/ Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements _______________________________________________ Catalog-sig mailing list Catalog-sig@python.org http://mail.python.org/mailman/listinfo/catalog-sig From DOUGS@oceanic.com Fri Feb 23 20:39:16 2001 From: DOUGS@oceanic.com (Doug Stanfield) Date: Fri, 23 Feb 2001 10:39:16 -1000 Subject: [Catalog-sig] SIG status - Siphon name Message-ID: <8457258D741DD411BD3D0050DA62365907A65C@huina.oceanic.com> [Brad Clements said:] > the Siphon name isn't going to work I think. I'm partial to Psyphon. I'm not sure of the etymology of Siphon anyway. Any clues? Is Suchandra subscribed to this list or even the dist-utils? I've been hoping the discussion on this topic would migrate to this list, where I think it belongs. If not I need to start lurking elsewhere. BTW, I'm lurking in hopes of being able to set up a mirror early on. -Doug- From fgranger@altern.org Sat Feb 24 23:06:14 2001 From: fgranger@altern.org (Francois Granger) Date: Sun, 25 Feb 2001 00:06:14 +0100 Subject: [Catalog-sig] SIG status - Siphon name In-Reply-To: References: Message-ID: At 12:01 -0500 on 24/02/01, in message Catalog-sig digest, Vol 1 #12 - 3 msgs, you wrote: >I'm not sure of the etymology of Siphon anyway. Any clues? Seems to be the same word in french. From Latin sipho and greek siphon Tube for moving liquid from a level to a lower level throught an upper level. Tube with an S shape under lavatory to avoid smelling. (sorry for my bad english, even with the help of Harrap's ;-) -- "Faites des phrases courtes. Un sujet, un verbe, un complément. Quand vous voudrez ajouter un adjectif, vous viendrez me voir." - Georges Clemenceau, 1841-1929, médecin et homme politique français. Consignes aux journalistes de "L'Aurore". d'après From s-thapa-11@alumni.uchicago.edu Mon Feb 26 19:39:39 2001 From: s-thapa-11@alumni.uchicago.edu (s-thapa-11@alumni.uchicago.edu) Date: Mon, 26 Feb 2001 13:39:39 -0600 Subject: [Catalog-sig] Catching up/Status Message-ID: <20010226133939.A10094@hepcat.uchicago.edu> --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm now subscribed to both the distutils and catalog sig mailing=20 lists so I should be more accessible from now. This is just to catch up with some questions that came up on the list previously. To answer Guido's question about why I didn't go to catalog-sig first, I checked the archives in January for the list and noticed that there wasn't any activity since approximately November. I assumed that the list had become inactive due to this and some of the discussions on clp. In regards to the name, I initially was thinking of something like CPyAN but finally decided on siphon since the name is suugested how I would have pronounced CPyAN and the definition of siphon was thematically related to what the project would do. Instead of aquariums, I was thinking more of the situation where motorists would siphon gas from one car to anot= her help someone who had run out of gasoline. However, I would have no=20 problem changing the spelling of the project's name to something like cipyan or something similar if that would help people find it more easily. Finally, I placed an early implementation on sourceforge but I'm not real= ly happy with it currently since I didn't have time to properly document it or explain the design and implementation. Also there is a lot of missing=20 functionality and stubs. I hope to remedy this and having a better release done by Wednesday. =20 --=20 ------------------------------------------------------------------ Suchandra S. Thapa=20 s-thapa-11@alumni.uchicago.edu ------------------------------------------------------------------ --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6mrD60hoo1RInvaIRAk0yAJ97ARY9Bl5x0V7mkiuOEdJBHprOrQCg4Jrw GXjFDC4/5kpActd4/NM60xc= =aNuf -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From amos@digicool.com Mon Feb 26 23:12:04 2001 From: amos@digicool.com (Amos Latteier) Date: Mon, 26 Feb 2001 15:12:04 -0800 Subject: [Catalog-sig] [Announce] Distutils Catalog Prototype Message-ID: <3A9AE2C4.37CDFF22@digicool.com> Hi Guys, I finally got off my butt and built a distutils catalog prototype. Now for a limited time you can get to it at http://63.230.174.230:8080/ This is a Zope site that allows you to upload distutils archives and search them. I added a basic HTML and XML interface. The XML interface should be used by command-line clients. The user name and password for uploading are both 'guest'. I am going to remove this account in a couple days since it is fundamentally insecure. I mostly want to post this now so folks can see what I'm doing. If you want to play with the prototype more, get Zope 2.3 and install the DistutilsArchive20010226.tgz file. I've preloaded the site with one archive (distutils 1.0.1). Try out the site by uploading your own archives. If the site can't parse them take a look in Parse.py and figure out what the problem is and send me a patch. Issues * Executing setup.py to find meta-data is insecure. Plus I've found that many existing distutils archives don't actually expose the meta-data very well this way. I propose that we fix this by having distutils write a meta-data file when you build an archive. * What API would command-line tools like? XML in some home-cooked DTD? Maybe XML-RPC? Let me know what you think! -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From robin@alldunn.com Mon Feb 26 23:54:03 2001 From: robin@alldunn.com (Robin Dunn) Date: Mon, 26 Feb 2001 15:54:03 -0800 Subject: [Catalog-sig] [Announce] Distutils Catalog Prototype References: <3A9AE2C4.37CDFF22@digicool.com> Message-ID: <03c901c0a04f$66ea3720$0100a8c0@Rogue> > Hi Guys, > > I finally got off my butt and built a distutils catalog prototype. Now > for a limited time you can get to it at > > http://63.230.174.230:8080/ > > This is a Zope site that allows you to upload distutils archives and > search them. I added a basic HTML and XML interface. The XML interface > should be used by command-line clients. The user name and password for > uploading are both 'guest'. I am going to remove this account in a > couple days since it is fundamentally insecure. I mostly want to post > this now so folks can see what I'm doing. If you want to play with the > prototype more, get Zope 2.3 and install the > DistutilsArchive20010226.tgz file. > > I've preloaded the site with one archive (distutils 1.0.1). Try out the > site by uploading your own archives. If the site can't parse them take a > look in Parse.py and figure out what the problem is and send me a patch. > > Issues > > * Executing setup.py to find meta-data is insecure. Plus I've found > that many existing distutils archives don't actually expose the > meta-data very well this way. I propose that we fix this by having > distutils write a meta-data file when you build an archive. This sounds like a good idea. It would probably be useful for other things as well. > * What API would command-line tools like? XML in some home-cooked DTD? > Maybe XML-RPC? Definitily XML-RPC. It's so easy to use from the client side that it doesn't make sense to NOT have it IMHO. That isn't to say that some other format in addition to XML-RPC shouldn't be done too, both may make sense. > > Let me know what you think! > I don't have time to debug it right now (maybe later) but if you try to load this file: http://download.sourceforge.net/pybsddb/bsddb3-3.0b3.tar.gz then you get this error: Zope Error Zope has encountered an error while publishing this resource. Error Type: ParseError Error Value: Archive does not contain a setup.py file ... Traceback (innermost last): File /home/amos/DistSite/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /home/amos/DistSite/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/amos/DistSite/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook File /home/amos/DistSite/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/amos/DistSite/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: addMethod) File /home/amos/DistSite/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: addMethod) File /home/amos/DistSite/lib/python/Products/DistutilsArchive/Archive.py, line 25, in addMethod File /home/amos/DistSite/lib/python/Products/DistutilsArchive/Archive.py, line 84, in update (Object: RoleManager) File /home/amos/DistSite/lib/python/Products/DistutilsArchive/Parse.py, line 63, in parse_meta_data ParseError: (see above) The archive does have a setup.py. -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython! From amos@digicool.com Tue Feb 27 01:37:28 2001 From: amos@digicool.com (Amos Latteier) Date: Mon, 26 Feb 2001 17:37:28 -0800 Subject: [Catalog-sig] [Announce] Distutils Catalog Prototype References: <3A9AE2C4.37CDFF22@digicool.com> <03c901c0a04f$66ea3720$0100a8c0@Rogue> Message-ID: <3A9B04D8.B81DED2B@digicool.com> Robin Dunn wrote: > > * Executing setup.py to find meta-data is insecure. Plus I've found > > that many existing distutils archives don't actually expose the > > meta-data very well this way. I propose that we fix this by having > > distutils write a meta-data file when you build an archive. > > This sounds like a good idea. It would probably be useful for other things > as well. Once we get agreement that a meta-data file is needed then we can begin the horrific task if figuring out what format it should be in ;-) > > * What API would command-line tools like? XML in some home-cooked DTD? > > Maybe XML-RPC? > > Definitily XML-RPC. It's so easy to use from the client side that it > doesn't make sense to NOT have it IMHO. That isn't to say that some other > format in addition to XML-RPC shouldn't be done too, both may make sense. OK, I'll try to put together something with XML-RPC. > I don't have time to debug it right now (maybe later) but if you try to load > this file: > http://download.sourceforge.net/pybsddb/bsddb3-3.0b3.tar.gz Hmm. I get a different error: Error Type: RuntimeError Error Value: 'distutils.core.setup()' was never called -- perhaps '/var/tmp/@11142.3/bsddb3-3.0b3/setup.py' is not a Distutils setup script? ... File /home/amos/DistSite/lib/python/Products/DistutilsArchive/Parse.py, line 69, in parse_meta_data File /usr/local/lib/python1.5/site-packages/distutils/core.py, line 221, in run_setup RuntimeError: (see above) Sure enough, when I fire up the interpreter and try to manually use distutils.core.run_setup on your archive I get the same error. But your setup.py looks good. My guess is that this is a distutils error... -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From amos@digicool.com Tue Feb 27 01:46:10 2001 From: amos@digicool.com (Amos Latteier) Date: Mon, 26 Feb 2001 17:46:10 -0800 Subject: [Catalog-sig] [Announce] Distutils Catalog Prototype References: <3A9AE2C4.37CDFF22@digicool.com> <03c901c0a04f$66ea3720$0100a8c0@Rogue> Message-ID: <3A9B06E2.F782BB52@digicool.com> Robin Dunn wrote: > I don't have time to debug it right now (maybe later) but if you try to load > this file: > http://download.sourceforge.net/pybsddb/bsddb3-3.0b3.tar.gz OK, the problem is that I don't have berkeley db installed on my server. Therefor setup.py chokes with Can't find a local db3 installation. This keeps distutils.core.run_setup from being able to extract the meta-data from the archive. This is yet another reason that we need distutils to write meta-data to a file when building an archive. Extracting meta-data by running setup.py may fail for many reasons. -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From robin@alldunn.com Tue Feb 27 01:57:26 2001 From: robin@alldunn.com (Robin Dunn) Date: Mon, 26 Feb 2001 17:57:26 -0800 Subject: [Catalog-sig] [Announce] Distutils Catalog Prototype References: <3A9AE2C4.37CDFF22@digicool.com> <03c901c0a04f$66ea3720$0100a8c0@Rogue> <3A9B04D8.B81DED2B@digicool.com> Message-ID: <041a01c0a060$a36d0770$0100a8c0@Rogue> > Robin Dunn wrote: > > > > * Executing setup.py to find meta-data is insecure. Plus I've found > > > that many existing distutils archives don't actually expose the > > > meta-data very well this way. I propose that we fix this by having > > > distutils write a meta-data file when you build an archive. > > > > This sounds like a good idea. It would probably be useful for other things > > as well. > > Once we get agreement that a meta-data file is needed then we can begin > the horrific task if figuring out what format it should be in ;-) Well as long as there's a utility function in distutils somewhere to read it and populate a dictionary or an instance of some DistMetaData class then it doesn't matter what format it's stored in, right? ;-) > Error Type: RuntimeError > Error Value: 'distutils.core.setup()' was never called -- perhaps > '/var/tmp/@11142.3/bsddb3-3.0b3/setup.py' is not a Distutils setup > script? > RuntimeError: (see above) > > Sure enough, when I fire up the interpreter and try to manually use > distutils.core.run_setup on your archive I get the same error. But your > setup.py looks good. My guess is that this is a distutils error... > It does a sys.exit if it can't find a BerkeleyDB library. I imagine that is not a very good thing to do when trying to extract meta data this way... -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython! From R.Liebscher@gmx.de Tue Feb 27 08:27:27 2001 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Tue, 27 Feb 2001 09:27:27 +0100 Subject: [Catalog-sig] [Announce] Distutils Catalog Prototype References: <3A9AE2C4.37CDFF22@digicool.com> Message-ID: <3A9B64EF.7E5B8D4A@gmx.de> Amos Latteier wrote: > > Hi Guys, > > I finally got off my butt and built a distutils catalog prototype. Now > for a limited time you can get to it at > > http://63.230.174.230:8080/ > > This is a Zope site that allows you to upload distutils archives and > search them. I added a basic HTML and XML interface. The XML interface > should be used by command-line clients. The user name and password for > uploading are both 'guest'. I am going to remove this account in a > couple days since it is fundamentally insecure. I mostly want to post > this now so folks can see what I'm doing. If you want to play with the > prototype more, get Zope 2.3 and install the > DistutilsArchive20010226.tgz file. > > I've preloaded the site with one archive (distutils 1.0.1). Try out the > site by uploading your own archives. If the site can't parse them take a > look in Parse.py and figure out what the problem is and send me a patch. > > Issues > > * Executing setup.py to find meta-data is insecure. Plus I've found > that many existing distutils archives don't actually expose the > meta-data very well this way. I propose that we fix this by having > distutils write a meta-data file when you build an archive. I tried to upload PyOpenGL and got the following result: Zope Error Zope has encountered an error while publishing this resource. Error Type: ImportError Error Value: No module named my_install_data .... Traceback (innermost last): File /home/amos/DistSite/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /home/amos/DistSite/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/amos/DistSite/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook File /home/amos/DistSite/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/amos/DistSite/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: addMethod) File /home/amos/DistSite/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: addMethod) File /home/amos/DistSite/lib/python/Products/DistutilsArchive/Archive.py, line 25, in addMethod File /home/amos/DistSite/lib/python/Products/DistutilsArchive/Archive.py, line 84, in update (Object: RoleManager) File /home/amos/DistSite/lib/python/Products/DistutilsArchive/Parse.py, line 69, in parse_meta_data File /usr/local/lib/python1.5/site-packages/distutils/core.py, line 209, in run_setup File /var/tmp/@11671.4/PyOpenGL-1.5.6/setup.py, line 16, in ? ImportError: (see above) ---------------------------------- PyOpenGL uses an external module to install its data. (It is imported but not used if you don't execute an install command.) If your system doesn't unpack all files before executing setup.py it will fail for all packages which import other python files in their setup.py. (And I think there are many such packages.) Kind regards Rene Liebscher From doughellmann@home.com Tue Feb 27 15:17:06 2001 From: doughellmann@home.com (Doug Hellmann) Date: Tue, 27 Feb 2001 10:17:06 -0500 Subject: [Catalog-sig] Re: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: References: Message-ID: <01022710324002.20069@branagan> On Tue, 27 Feb 2001, Mark W. Alexander wrote: > I have no idea how this cc: list came to be. I'm adding catalog-sig > and will drop individuals on subsequent posts.... I've done that, too. It was getting a bit long. > On Tue, 27 Feb 2001, Bruce Sass wrote: > > Subject: [Distutils] Re: CPAN functionality for python - requirements > > > > > I sense a consensus that the "install" part should be handled by distutils. Is > > > that right? > > > > As long as distutils does not presume to know how to do the > > installation. > > > > > Other requirements we might lay down up front: > > > > > > 1. Should run on all platforms where Python runs. > > > 2. Must support mirrors on the server side. > > > 3. Need to include documentation along with source for packages. > > > > > > The features related to dependencies and downloads could be handled by a > > > platform-specific packaging system, but integrating with all of the different > > > options on all of the different platforms where Python runs increases the > > > complexity of the new tool. > > It seems there's a misunderstanding of what distutils does. It provides > a standard mechanism for producing installable python packages. IOW, I think the misunderstanding was on my part, and between your description and reviewing the distutils help I think I'm straightened out now. With that said, I agree that the network needs to allow, optionally, for binary distributions for platforms where building binary distributions is unusually difficult (like having no compiler on Win32). All packages should be available in source form (assuming some OS license) by default. The client should offer the user the option of downloading any available package format, which can then be installed using a separate tool ("./setup.py install" or rpm or whatever). If as a user, I choose to download an RPM, that's up to me. If no RPM is available, the thing I do download should be able to *make* an RPM, so that's where distutils comes in. So, we don't quite get to a *standard* set of download and install instructions because downloading different package types requires different installation steps. By trading that off we get package management using the user's favorite package system. That seems to be a reasonable trade. > So the catalog client will need to be able to acquire dependency > information from the network archive in order to ascertain whether > the module is buildable on the target system. If it is, it will > also need to acquire, invoke distutils to build and package, and > invoke the package manager to install all dependencies in order. I'm going to back off my request that this be an all-the-way tool. Let's stick to finding a package and all of its dependencies, and leave the installation to the packages which are downloaded. As a Python user, I may not have system privileges sufficient to allow me to install a downloaded package. As a system administrator, I may not know how to use this tool to find packages. So, the Python user can find the package and provide it to the sysadmin for installation. Nice and clean. Optionally, there could be an argument which would invoke an installation command for the package(s) being downloaded. > If it is not buildable, then it would need to seek out pre-built > binaries, download and install them. So, either the network archive > interfaces with distutils such that a back-end can produce binaries, Can I build binaries for all platforms on whatever platform I use for the network archive? > OR archive maintainers manually produce binaries for whatever > platforms they choose to support, OR automatically. If the source distribution is always available, part of the mirroring process could be to convert the source distributions into binary distributions for the platform serviced by the mirror site. > OR people without development tools (Windows, Macs(?), disk-space tight > OS's) are SOL. OR developers who do not have access to platforms where binary distributions are prefered enlist other interested parties to assist them in preparing binary packages. OR third party volunteers post binary distributions to other sites on the network > I hope this clarifies distutils (potential) role a bit. Significantly. Thanks, Doug From mwa@gate.net Tue Feb 27 15:55:03 2001 From: mwa@gate.net (Mark W. Alexander) Date: Tue, 27 Feb 2001 10:55:03 -0500 (EST) Subject: [Catalog-sig] Re: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: <01022710324002.20069@branagan> Message-ID: On Tue, 27 Feb 2001, Doug Hellmann wrote: > Date: Tue, 27 Feb 2001 10:17:06 -0500 > From: Doug Hellmann > To: python-list@python.org, distutils-sig@python.org, catalog-sig@python.org > Subject: [Catalog-sig] Re: [Distutils] Re: CPAN functionality for python > - requirements > [snip] > > It seems there's a misunderstanding of what distutils does. It provides > > a standard mechanism for producing installable python packages. IOW, > > I think the misunderstanding was on my part, and between your description and > reviewing the distutils help I think I'm straightened out now. > > With that said, I agree that the network needs to allow, optionally, for binary > distributions for platforms where building binary distributions is unusually > difficult (like having no compiler on Win32). All packages should be available > in source form (assuming some OS license) by default. The client should offer > the user the option of downloading any available package format, which can then > be installed using a separate tool ("./setup.py install" or rpm or whatever). > > If as a user, I choose to download an RPM, that's up to me. If no RPM is > available, the thing I do download should be able to *make* an RPM, so that's > where distutils comes in. Agreed. [snip] > I'm going to back off my request that this be an all-the-way tool. Let's stick > to finding a package and all of its dependencies, and leave the installation to > the packages which are downloaded. As a Python user, I may not have system > privileges sufficient to allow me to install a downloaded package. As a system > administrator, I may not know how to use this tool to find packages. So, the > Python user can find the package and provide it to the sysadmin for > installation. Nice and clean. > > Optionally, there could be an argument which would invoke an installation > command for the package(s) being downloaded. Yes, after I sent this off, I started thinking this as well. It's better as well for sites with multiple machines. Go get it once and install everywhere. > > If it is not buildable, then it would need to seek out pre-built > > binaries, download and install them. So, either the network archive > > interfaces with distutils such that a back-end can produce binaries, > > Can I build binaries for all platforms on whatever platform I use for the > network archive? That's an interesting question. What would it take to include cross-compiling support in distutils? > > OR archive maintainers manually produce binaries for whatever > > platforms they choose to support, > > OR automatically. If the source distribution is always available, part of the > mirroring process could be to convert the source distributions into binary > distributions for the platform serviced by the mirror site. That was my original thought. I would hate to see, however, that some platform gets "slighted" because there's no one to run a mirror for them. > > OR people without development tools (Windows, Macs(?), disk-space tight > > OS's) are SOL. > > OR developers who do not have access to platforms where binary distributions > are prefered enlist other interested parties to assist them in preparing binary > packages. > > OR third party volunteers post binary distributions to other sites on the > network These last 2 are where I hoped the combination of distutils and a network archive would reduce the number of volunteers needed. As long as distutils can produce a binary for a particular platform/ package manager combination, there's really no need for a dedicated (official or UNofficial) "package mantainer". All that's needed is a place where "python setup.py --bdist format=MyPackager" works. How about an interarchive-API (or redirector?), so archives can forward requests for binary packages to other sites known to support that type of binary package? Mark From s-thapa-11@alumni.uchicago.edu Tue Feb 27 17:52:56 2001 From: s-thapa-11@alumni.uchicago.edu (s-thapa-11@alumni.uchicago.edu) Date: Tue, 27 Feb 2001 11:52:56 -0600 Subject: [Catalog-sig] Re: [Distutils] Re: CPAN functionality for python - requirements Message-ID: <20010227115256.C1074@hepcat.uchicago.edu> --C94crkcyjafcjHxo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 27, 2001 at 08:44:02AM -0800, Michel Sanner wrote: > One issue that we are strugling with is versions of packages.Is there a > "standard" way to deal with versions ? how do you plan to find out whether > someone has a compatible version of any given package ? That's a problem that I've run across also. I don't think there is any standard way to pick up version numbers of installed packages. I=20 think this would be a useful addition to the distutils installation if it's not already present.=20 --=20 ------------------------------------------------------------------ Suchandra S. Thapa=20 s-thapa-11@alumni.uchicago.edu ------------------------------------------------------------------ --C94crkcyjafcjHxo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6m+l30hoo1RInvaIRAuibAKDQl2vN5MQItqH6Kyw2c2xL6lyTiwCfcyZ7 ir0ThbVlHDytGqNiE7dhlWM= =se6G -----END PGP SIGNATURE----- --C94crkcyjafcjHxo-- From phrxy@csv.warwick.ac.uk Tue Feb 27 18:03:56 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Tue, 27 Feb 2001 18:03:56 +0000 (GMT) Subject: [Catalog-sig] Re: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Mark W. Alexander wrote: [...] > As long as distutils can produce a binary for a particular platform/ > package manager combination, there's really no need for a dedicated > (official or UNofficial) "package mantainer". All that's needed > is a place where "python setup.py --bdist format=MyPackager" works. > How about an interarchive-API (or redirector?), so archives can > forward requests for binary packages to other sites known to support > that type of binary package? [...] In which case: 1. Distutils should be able to pgp-sign binary (and source as well come to think of it) packages. 2. CPyAN should be able to manage the signatures as appropriate. John From phrxy@csv.warwick.ac.uk Tue Feb 27 18:22:05 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Tue, 27 Feb 2001 18:22:05 +0000 (GMT) Subject: [Catalog-sig] Re: [Distutils] Re: CPAN functionality for python - requirements (fwd) Message-ID: Sorry, meant to send this to Catalog-sig, not Distutils-sig. ---------- Forwarded message ---------- Date: Tue, 27 Feb 2001 18:16:39 +0000 (GMT) From: John J. Lee To: python-list@python.org, distutils-sig@python.org Subject: Re: [Distutils] Re: CPAN functionality for python - requirements On Tue, 27 Feb 2001, Mark W. Alexander wrote: > On Tue, 27 Feb 2001, Doug Hellmann wrote: [...] > > I can't remember now whether CPAN did installations or just downloaded stuff > > and made you figure out how to install it. > > (My understanding of) CPAN is that it's a repository of things that > install a standard way. You download what you want and > > perl Makefile.pl > make install [...] There are two different 'CPAN's: 1. The archive itself -- a bunch of files in .tar.gz format, READMEs, etc. It uses a mirroring system that sets itself up on your first visit to point to a nearby mirror, and subsequently takes you there automatically. 2. The CPAN module, CPAN.pm, which can be used interactively or through its API. It lets you search for, download, find dependencies (and download again if required), build and install modules. [Activestate's windows distribution has its own binary package system, PPM, but CPAN (the module) works on windows as long as you have libwww-perl. I don't know what fraction of modules including C code compile without trouble on windows.] John From phrxy@csv.warwick.ac.uk Tue Feb 27 18:29:18 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Tue, 27 Feb 2001 18:29:18 +0000 (GMT) Subject: [Catalog-sig] Re: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: <20010227110803.Z1781@tummy.com> Message-ID: Followup to Catalog-sig only (pine doesn't seem to let me set that in the headers...)? I don't think this has much to do with Distutils. On Tue, 27 Feb 2001, Sean Reifschneider wrote: > On Tue, Feb 27, 2001 at 09:30:13AM -0700, Evelyn Mitchell wrote: > >But it will also discover and resolve dependences in your perl > >site-packages, and automatically fetch them from your closest > >CPAN archive. > > Not according to my tests the night before last. I did a test CPAN > install of "News::Newsrc", which failed because the "make test" was > failing. I then installed the "Set::BitSet" (? Something like that) > module and tried News::Newsrc again and it worked... [...] Did you use CPAN.pm? CPAN the archive doesn't do dependencies. Dependencies are listed in the Makefile.PL (BTW, I have no idea why the capitalised PL), and after the module CPAN.pm downloads what you asked for, it checks that to see if there are dependencies, then downloads them if you don't already have them installed. John From jafo@tummy.com Wed Feb 28 04:13:31 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Tue, 27 Feb 2001 21:13:31 -0700 Subject: [Catalog-sig] Re: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: <01022710324002.20069@branagan>; from doughellmann@home.com on Tue, Feb 27, 2001 at 10:17:06AM -0500 References: <01022710324002.20069@branagan> Message-ID: <20010227211331.A24378@tummy.com> On Tue, Feb 27, 2001 at 10:17:06AM -0500, Doug Hellmann wrote: >OR automatically. If the source distribution is always available, part of the >mirroring process could be to convert the source distributions into binary >distributions for the platform serviced by the mirror site. That seems like it would be a huge security issue. Sean -- Passionate hatred can give meaning and purpose to an empty life. -- Eric Hoffer Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Wed Feb 28 04:15:25 2001 From: jafo@tummy.com (Sean Reifschneider) Date: Tue, 27 Feb 2001 21:15:25 -0700 Subject: [Catalog-sig] Re: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: ; from mwa@gate.net on Tue, Feb 27, 2001 at 10:55:03AM -0500 References: <01022710324002.20069@branagan> Message-ID: <20010227211525.B24378@tummy.com> On Tue, Feb 27, 2001 at 10:55:03AM -0500, Mark W. Alexander wrote: >That was my original thought. I would hate to see, however, that some >platform gets "slighted" because there's no one to run a mirror for >them. It seems to me that instead of having the "mirrors" do it, some work be done on setting up "build nodes" that can take new source packages and turn them into binaries... Sean -- It often shows a fine command of a language to say nothing. Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python From jafo@tummy.com Wed Feb 28 04:16:26 2001 From: jafo@tummy.com (Sean Reifschneider) Date: 27 Feb 2001 20:16:26 -0800 Subject: [Catalog-sig] Re: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: <01022710324002.20069@branagan>; from doughellmann@home.com on Tue, Feb 27, 2001 at 10:17:06AM -0500 References: <01022710324002.20069@branagan> Message-ID: <20010227211331.A24378@tummy.com> On Tue, Feb 27, 2001 at 10:17:06AM -0500, Doug Hellmann wrote: >OR automatically. If the source distribution is always available, part of the >mirroring process could be to convert the source distributions into binary >distributions for the platform serviced by the mirror site. That seems like it would be a huge security issue. Sean -- Passionate hatred can give meaning and purpose to an empty life. -- Eric Hoffer Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python -- http://mail.python.org/mailman/listinfo/python-list From jafo@tummy.com Wed Feb 28 04:17:25 2001 From: jafo@tummy.com (Sean Reifschneider) Date: 27 Feb 2001 20:17:25 -0800 Subject: [Catalog-sig] Re: [Distutils] Re: CPAN functionality for python - requirements In-Reply-To: ; from mwa@gate.net on Tue, Feb 27, 2001 at 10:55:03AM -0500 References: <01022710324002.20069@branagan> Message-ID: <20010227211525.B24378@tummy.com> On Tue, Feb 27, 2001 at 10:55:03AM -0500, Mark W. Alexander wrote: >That was my original thought. I would hate to see, however, that some >platform gets "slighted" because there's no one to run a mirror for >them. It seems to me that instead of having the "mirrors" do it, some work be done on setting up "build nodes" that can take new source packages and turn them into binaries... Sean -- It often shows a fine command of a language to say nothing. Sean Reifschneider, Inimitably Superfluous tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python -- http://mail.python.org/mailman/listinfo/python-list From robin@alldunn.com Wed Feb 28 16:50:03 2001 From: robin@alldunn.com (Robin Dunn) Date: Wed, 28 Feb 2001 08:50:03 -0800 Subject: [Catalog-sig] The KISS principle [ Re: CPAN functionality for python - requirements ] References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD44@UKRUX002.rundc.uk.origin-it.com> Message-ID: <08af01c0a1a6$800b2130$0100a8c0@Rogue> > > But writing a "perfect" utility for automated download-and-install, with > dependency tracking, etc etc, is going to be VERY HARD. Don't get misled - > Perl doesn't have such a beast. And We won't even have what Perl has if we > focus on perfection rather than practicality. Agreed. There is an old saying about shooting for the stars to reach the moon. Some of the ideas and proposals for all this seem to be shooting for distant galaxies and are unable to even get off the ground. IMHO we should start with something simple that allows for some of the ultimate goals, and that can be built upon later to get to more of the goals. Here is what I think the simple version needs: 1. A standard place where a file containing a list of mirrors and maybe a bit of mirror meta-data can be fetched from. 2. A python module to parse that mirror data into a meaningful data structure such as a dictionary or a list of instance objects of some type. 3. At every site in the mirrors file there will be a file containing meta-data about all the packages in the archive. 4. A python module to parse the package meta-data into something the client code can easily use. (The meta-data format is probably XML, but hiding it like this means the tool developer doesn't need to know or care what format the file is in. Ditto for the mirror list.) 5. An automated way to extract at least most if not all of the package meta-data from a Distutils based package and upload the meta-data, the sdist, and any bdists that the developer has made to the archive. This could be a new command added to Distutils, with a bit of functionality on the server side for receiving the files, moving them into the "right place" in the archive, and updating the package meta-data file. 6. Define a file format and supporting Python code for tracking which packages and versions have been fetched from the network and installed. Again, this should probably be a function of Distutils so it will also catch the cases where you downloaded some package not in the archive network and ran "python setup.py install" yourself. That's it. With just that bit in place intelligent clients could be written as command-line or GUI tools, or even a web-based interface. They simply fetch the list of mirrors and fetch the package meta-data from a desired mirror and cache this info locally. Then the client tools can do things without having to talk to a server like list available packages, query dependencies, list packages you have installed, etc. When you want to fetch and install a package then the client tool can use the package meta-data and urllib to fetch the sdist and/or a desired bdist and then optionally install it either using the package's setup.py or by whatever command is neccessary for the bdist. -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython! From robin@alldunn.com Wed Feb 28 16:55:18 2001 From: robin@alldunn.com (Robin Dunn) Date: 28 Feb 2001 08:55:18 -0800 Subject: [Catalog-sig] The KISS principle [ Re: CPAN functionality for python - requirements ] References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD44@UKRUX002.rundc.uk.origin-it.com> Message-ID: <08af01c0a1a6$800b2130$0100a8c0@Rogue> > > But writing a "perfect" utility for automated download-and-install, with > dependency tracking, etc etc, is going to be VERY HARD. Don't get misled - > Perl doesn't have such a beast. And We won't even have what Perl has if we > focus on perfection rather than practicality. Agreed. There is an old saying about shooting for the stars to reach the moon. Some of the ideas and proposals for all this seem to be shooting for distant galaxies and are unable to even get off the ground. IMHO we should start with something simple that allows for some of the ultimate goals, and that can be built upon later to get to more of the goals. Here is what I think the simple version needs: 1. A standard place where a file containing a list of mirrors and maybe a bit of mirror meta-data can be fetched from. 2. A python module to parse that mirror data into a meaningful data structure such as a dictionary or a list of instance objects of some type. 3. At every site in the mirrors file there will be a file containing meta-data about all the packages in the archive. 4. A python module to parse the package meta-data into something the client code can easily use. (The meta-data format is probably XML, but hiding it like this means the tool developer doesn't need to know or care what format the file is in. Ditto for the mirror list.) 5. An automated way to extract at least most if not all of the package meta-data from a Distutils based package and upload the meta-data, the sdist, and any bdists that the developer has made to the archive. This could be a new command added to Distutils, with a bit of functionality on the server side for receiving the files, moving them into the "right place" in the archive, and updating the package meta-data file. 6. Define a file format and supporting Python code for tracking which packages and versions have been fetched from the network and installed. Again, this should probably be a function of Distutils so it will also catch the cases where you downloaded some package not in the archive network and ran "python setup.py install" yourself. That's it. With just that bit in place intelligent clients could be written as command-line or GUI tools, or even a web-based interface. They simply fetch the list of mirrors and fetch the package meta-data from a desired mirror and cache this info locally. Then the client tools can do things without having to talk to a server like list available packages, query dependencies, list packages you have installed, etc. When you want to fetch and install a package then the client tool can use the package meta-data and urllib to fetch the sdist and/or a desired bdist and then optionally install it either using the package's setup.py or by whatever command is neccessary for the bdist. -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython! -- http://mail.python.org/mailman/listinfo/python-list From akuchlin@mems-exchange.org Wed Feb 28 17:26:49 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 28 Feb 2001 12:26:49 -0500 Subject: [Catalog-sig] The KISS principle [ Re: CPAN functionality for python - requirements ] In-Reply-To: <08af01c0a1a6$800b2130$0100a8c0@Rogue>; from robin@alldunn.com on Wed, Feb 28, 2001 at 08:50:03AM -0800 References: <714DFA46B9BBD0119CD000805FC1F53B01B5AD44@UKRUX002.rundc.uk.origin-it.com> <08af01c0a1a6$800b2130$0100a8c0@Rogue> Message-ID: <20010228122649.F15343@ute.cnri.reston.va.us> On Wed, Feb 28, 2001 at 08:50:03AM -0800, Robin Dunn wrote: >IMHO we should start with something simple that allows for some of the >ultimate goals, and that can be built upon later to get to more of the >goals. Indeed. 75% of the module-related questions on comp.lang.python are "does a module to do X exist?", not "What are the dependencies for module X?". Encouraging people just to register their software is half the battle; not everyone adds their software to VoP, but practically every Perl module author is represented in CPAN. Dependencies are complicated and frankly, a solution could be very useful without even attempting to solve that problem. --amk From s-thapa-11@alumni.uchicago.edu Wed Feb 28 20:42:12 2001 From: s-thapa-11@alumni.uchicago.edu (s-thapa-11@alumni.uchicago.edu) Date: Wed, 28 Feb 2001 14:42:12 -0600 Subject: [Catalog-sig] [ANN] new release of ciphon/distutils requests Message-ID: <20010228144212.B4310@hepcat.uchicago.edu> --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've done a little more work on ciphon, it now sort of reads installed packages and is able to resolve dependencies in a limited fashion. It's available on sourceforge as siphon, but I'll change the project name fairly soon. =20 One thing I noticed while working on ciphon is that distutils doesn't seem to have a place to get information about packages currently installed. Is there any work being done on distutils to store information on installed= =20 modules like version, name, or files the module ha installed. The first= =20 two pieces of information would be extremely useful in resolving dependenci= es. I can do without information on the module's files but that would prevent= =20 a way to automatically remove installed modules. --=20 ------------------------------------------------------------------ Suchandra S. Thapa=20 s-thapa-11@alumni.uchicago.edu ------------------------------------------------------------------ --XF85m9dhOBO43t/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6nWKk0hoo1RInvaIRAu/2AJ4m985Mu0EgNf41LIySjRVU8PTBhgCgszxw ZVtO82eVetsdkDpFcCdTzrc= =pXu9 -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C--