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."
<LNBBLJKPBEHFEDALKOLCMECFJBAA.tim.one@home.com>
References: <LNBBLJKPBEHFEDALKOLCMECFJBAA.tim.one@home.com>
Message-ID: <200102221311.IAA15371@cj20424-a.reston1.va.home.com>
> Guido van Rossum <guido@digicool.com> 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." <LNBBLJKPBEHFEDALKOLCMECFJBAA.tim.one@home.com>
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: <LNBBLJKPBEHFEDALKOLCMECFJBAA.tim.one@home.com> <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: <E14Wi48-0002Z7-00@mail.python.org>
References: <E14Wi48-0002Z7-00@mail.python.org>
Message-ID: <v04210104b6bded88664c@[213.228.21.206]>
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
<http://www.sit.ulaval.ca/pagespersonnelles/phf/pensee.html>
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: <Pine.A41.4.21.0102270924480.53710-100000@dakota.gate.net>
References: <Pine.A41.4.21.0102270924480.53710-100000@dakota.gate.net>
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: <Pine.A41.4.21.0102271045480.16050-100000@seminole.gate.net>
On Tue, 27 Feb 2001, Doug Hellmann wrote:
> Date: Tue, 27 Feb 2001 10:17:06 -0500
> From: Doug Hellmann <doughellmann@home.com>
> 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: <Pine.A41.4.21.0102271045480.16050-100000@seminole.gate.net>
Message-ID: <Pine.SOL.4.30.0102271758510.22762-100000@mimosa.csv.warwick.ac.uk>
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: <Pine.SOL.4.30.0102271817550.22762-100000@mimosa.csv.warwick.ac.uk>
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 <phrxy@csv.warwick.ac.uk>
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: <Pine.SOL.4.30.0102271823190.22762-100000@mimosa.csv.warwick.ac.uk>
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: <Pine.A41.4.21.0102270924480.53710-100000@dakota.gate.net> <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 <jafo@tummy.com>
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: <Pine.A41.4.21.0102271045480.16050-100000@seminole.gate.net>; from mwa@gate.net on Tue, Feb 27, 2001 at 10:55:03AM -0500
References: <01022710324002.20069@branagan> <Pine.A41.4.21.0102271045480.16050-100000@seminole.gate.net>
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 <jafo@tummy.com>
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: <Pine.A41.4.21.0102270924480.53710-100000@dakota.gate.net> <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 <jafo@tummy.com>
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: <Pine.A41.4.21.0102271045480.16050-100000@seminole.gate.net>; from mwa@gate.net on Tue, Feb 27, 2001 at 10:55:03AM -0500
References: <01022710324002.20069@branagan> <Pine.A41.4.21.0102271045480.16050-100000@seminole.gate.net>
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 <jafo@tummy.com>
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--