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: <F28E1287-6DAD-430E-BB5E-7EDC20245190@ucar.edu>
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: <F28E1287-6DAD-430E-BB5E-7EDC20245190@ucar.edu>
References: <F28E1287-6DAD-430E-BB5E-7EDC20245190@ucar.edu>
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 <pje at telecommunity.com> 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. <fdrake at gmail.com>
"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 <pje at telecommunity.com> 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 <pje at telecommunity.com> 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. <fdrake at gmail.com>
"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