From fred at ucar.edu Fri Aug 4 02:02:36 2006 From: fred at ucar.edu (Fred Clare) Date: Thu, 3 Aug 2006 18:02:36 -0600 Subject: [Catalog-sig] new classifier for CheeseShop Message-ID: <1E6D05A7-CB8E-492D-A6CF-4D0EF242DAC8@ucar.edu> I would like to see a classifier: Topic :: Scientific/Engineering :: Atmospheric Science Regards, Fred Clare National Center for Atmospheric Research From richardjones at optushome.com.au Fri Aug 4 03:52:15 2006 From: richardjones at optushome.com.au (Richard Jones) Date: Fri, 4 Aug 2006 11:52:15 +1000 Subject: [Catalog-sig] new classifier for CheeseShop In-Reply-To: <1E6D05A7-CB8E-492D-A6CF-4D0EF242DAC8@ucar.edu> References: <1E6D05A7-CB8E-492D-A6CF-4D0EF242DAC8@ucar.edu> Message-ID: <200608041152.15738.richardjones@optushome.com.au> On Friday 04 August 2006 10:02, Fred Clare wrote: > I would like to see a classifier: > > Topic :: Scientific/Engineering :: Atmospheric Science Added! Richard From haley at ucar.edu Mon Aug 7 22:30:58 2006 From: haley at ucar.edu (Mary Haley) Date: Mon, 7 Aug 2006 14:30:58 -0600 Subject: [Catalog-sig] Would like to request a classifier. Message-ID: This is an official request for a classifier to be added: Topic :: Scientific/Engineering :: Data Formats Thanks! --Mary ------------------------------------------------- Mary Haley haley at ucar.edu NCAR/SCD/VETS 303-497-1254 (voice) 1850 Table Mesa Dr 303-497-1239 (fax) Boulder, CO 80305 ------------------------------------------------- From richardjones at optushome.com.au Tue Aug 8 13:47:04 2006 From: richardjones at optushome.com.au (Richard Jones) Date: Tue, 8 Aug 2006 21:47:04 +1000 Subject: [Catalog-sig] Would like to request a classifier. In-Reply-To: References: Message-ID: <200608082147.04559.richardjones@optushome.com.au> On Tuesday 08 August 2006 06:30, Mary Haley wrote: > This is an official request for a classifier to be added: > > Topic :: Scientific/Engineering :: Data Formats How about just "Topic :: Data Formats"? Comments, anyone? Richard From pje at telecommunity.com Wed Aug 30 21:48:58 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 30 Aug 2006 15:48:58 -0400 Subject: [Catalog-sig] "UNKNOWN" URLs being generated Message-ID: <5.1.1.6.0.20060830154629.0281dc60@sparrow.telecommunity.com> When a package doesn't specify a download URL, a relative link to "UNKNOWN" is being generated by the PyPI web interface. This doesn't seem very useful; in particular it causes easy_install to retrieve an extra URL that isn't there. (It also seems a bit odd to even bother displaying "unknown" fields anyway.) From fdrake at gmail.com Wed Aug 30 21:52:25 2006 From: fdrake at gmail.com (Fred Drake) Date: Wed, 30 Aug 2006 15:52:25 -0400 Subject: [Catalog-sig] "UNKNOWN" URLs being generated In-Reply-To: <5.1.1.6.0.20060830154629.0281dc60@sparrow.telecommunity.com> References: <5.1.1.6.0.20060830154629.0281dc60@sparrow.telecommunity.com> Message-ID: <9cee7ab80608301252g33edf389nc49b808e2752e3ec@mail.gmail.com> On 8/30/06, Phillip J. Eby wrote: > When a package doesn't specify a download URL, a relative link to "UNKNOWN" > is being generated by the PyPI web interface. I blame distutils, which does this in it's metadata handling instead of just letting the values be None. ;-( -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca From pje at telecommunity.com Wed Aug 30 22:52:34 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 30 Aug 2006 16:52:34 -0400 Subject: [Catalog-sig] "UNKNOWN" URLs being generated In-Reply-To: <9cee7ab80608301252g33edf389nc49b808e2752e3ec@mail.gmail.co m> References: <5.1.1.6.0.20060830154629.0281dc60@sparrow.telecommunity.com> <5.1.1.6.0.20060830154629.0281dc60@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20060830165153.022e1540@sparrow.telecommunity.com> At 03:52 PM 8/30/2006 -0400, Fred Drake wrote: >On 8/30/06, Phillip J. Eby wrote: >>When a package doesn't specify a download URL, a relative link to "UNKNOWN" >>is being generated by the PyPI web interface. > >I blame distutils, which does this in it's metadata handling instead >of just letting the values be None. ;-( Really? But this behavior is new, as far as I know. It used to be that missing metadata wasn't displayed at all. From fdrake at gmail.com Wed Aug 30 22:56:22 2006 From: fdrake at gmail.com (Fred Drake) Date: Wed, 30 Aug 2006 16:56:22 -0400 Subject: [Catalog-sig] "UNKNOWN" URLs being generated In-Reply-To: <5.1.1.6.0.20060830165153.022e1540@sparrow.telecommunity.com> References: <5.1.1.6.0.20060830154629.0281dc60@sparrow.telecommunity.com> <5.1.1.6.0.20060830165153.022e1540@sparrow.telecommunity.com> Message-ID: <9cee7ab80608301356pf30c6bcw9dc9551f0c6e2c14@mail.gmail.com> On 8/30/06, Phillip J. Eby wrote: > Really? But this behavior is new, as far as I know. It used to be that > missing metadata wasn't displayed at all. PyPI may have masked this in the past; I'm not sure. It's worth checking for the removal of checks for this from PyPI. distutils definately does the non-Pythonic thing here for the dozen or so fields it thinks of as metadata. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca From richardjones at optushome.com.au Thu Aug 31 11:17:49 2006 From: richardjones at optushome.com.au (Richard Jones) Date: Thu, 31 Aug 2006 19:17:49 +1000 Subject: [Catalog-sig] "UNKNOWN" URLs being generated In-Reply-To: <5.1.1.6.0.20060830154629.0281dc60@sparrow.telecommunity.com> References: <5.1.1.6.0.20060830154629.0281dc60@sparrow.telecommunity.com> Message-ID: <200608311917.49502.richardjones@optushome.com.au> On Thursday 31 August 2006 05:48, Phillip J. Eby wrote: > When a package doesn't specify a download URL, a relative link to "UNKNOWN" > is being generated by the PyPI web interface. > > This doesn't seem very useful; in particular it causes easy_install to > retrieve an extra URL that isn't there. (It also seems a bit odd to even > bother displaying "unknown" fields anyway.) My fault (well, OK, it's distutil's fault, but I can take the blame in *this* instance). The database layer is returning unicode objects so my naive test "isinstance(info, string) and info.strip() == 'UNKNOWN'" was now failing. I've fixed it, and a couple of other unicode issues. We love str vs. unicode. Bring on Py3k! Richard