From exarkun at divmod.com  Thu Jan 11 13:26:23 2007
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Thu, 11 Jan 2007 07:26:23 -0500
Subject: [Catalog-sig] Package removal
In-Reply-To: 0
Message-ID: <20070111122623.11447.2003702108.divmod.quotient.13042@ohm>

Can the Twisted Flow package, added yesterday to the cheeseshop, be removed or have its owner changed so I can hide it?  The project is deprecated, the home page URL is wrong, the latest release doesn't work, and we (Twisted developers) have no desire to publicize this project.

Thanks,

Jean-Paul

From cliff at develix.com  Tue Jan  9 00:37:48 2007
From: cliff at develix.com (Cliff Wells)
Date: Mon, 08 Jan 2007 15:37:48 -0800
Subject: [Catalog-sig] New category request
Message-ID: <1168299469.4367.3.camel@portable-evil>

Several of the major Python frameworks now support a template plugin API
known as Buffet and utilize the python.templating.engines entry_point in
setup.py. As such I think there should be a new category:

Environment :: Web Environment :: Buffet

This API is currently supported by (at least) TurboGears, CherryPy and
Pylons.

Regards,
Cliff



From constant.beta at gmail.com  Thu Jan 18 14:50:51 2007
From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=)
Date: Thu, 18 Jan 2007 14:50:51 +0100
Subject: [Catalog-sig] How to get a list of package releases
Message-ID: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>

[CC-ing this to distutils-sig, because it relates to setuptools as
well, but please keep discussion on the catalog-sig if possible.]

Hi,

Maybe this is a stupid question, but how can I list all versions of a
package that were registered on PyPI? For example, when I go to
http://python.org/pypi/setuptools/ I'm redirected to the page of last
version of setuptools. How can I check earlier versions of setuptools
from there? I know this functionality is available for project admins,
what about users?

Another thing, some packages offer a development versions by giving a
link to their subversion repository. Is there a way to list these
extra install options on PyPI? By "extra options" I mean all
non-standard version strings that will work with `easy_install
package==version`, like common "dev".

Related setuptools question: is there a way to get list of available
versions from easy_install?

Cheers,
mk

From pje at telecommunity.com  Thu Jan 18 17:54:11 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 18 Jan 2007 11:54:11 -0500
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.co
 m>
Message-ID: <5.1.1.6.0.20070118115051.045cb688@sparrow.telecommunity.com>

At 02:50 PM 1/18/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
>Related setuptools question: is there a way to get list of available
>versions from easy_install?

The setuptools.package_index.PackageIndex class knows about all 
discoverable versions.  However, this doesn't extend to versions that have 
been hidden by the package author.  To have more than one discoverable 
version at the PyPI level, the author has to have made them visible in the 
admin interface.

But, whichever ones *are* visible can be discovered by the PackageIndex 
class, along with any that are linked from the Home Page or Download URLs, 
or are linked on the package's PyPI page.

More precisely, PackageIndex doesn't track versions; it tracks available 
*distributions*, which may include source distributions, SVN checkouts, 
eggs, .exe's, etc.  But each distribution object carries version info 
determined from its filename.


From richardjones at optushome.com.au  Fri Jan 19 05:53:11 2007
From: richardjones at optushome.com.au (Richard Jones)
Date: Fri, 19 Jan 2007 15:53:11 +1100
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
Message-ID: <200701191553.11648.richardjones@optushome.com.au>

On Friday 19 January 2007 00:50, Micha? Kwiatkowski wrote:
> Maybe this is a stupid question, but how can I list all versions of a
> package that were registered on PyPI?

You can get a full list through the XML-RPC interface:

    http://wiki.python.org/moin/CheeseShopXmlRpc

Specifically the package_releases method.


> Another thing, some packages offer a development versions by giving a
> link to their subversion repository. Is there a way to list these
> extra install options on PyPI? By "extra options" I mean all
> non-standard version strings that will work with `easy_install
> package==version`, like common "dev".

The XML-RPC release_data method might tell you this information. I'm not sure 
how people are coding the repository information into their package 
meta-data.


    Richard

From richardjones at optushome.com.au  Fri Jan 19 06:07:11 2007
From: richardjones at optushome.com.au (Richard Jones)
Date: Fri, 19 Jan 2007 16:07:11 +1100
Subject: [Catalog-sig] New category request
In-Reply-To: <1168299469.4367.3.camel@portable-evil>
References: <1168299469.4367.3.camel@portable-evil>
Message-ID: <200701191607.11317.richardjones@optushome.com.au>

On Tuesday 09 January 2007 10:37, Cliff Wells wrote:
> Several of the major Python frameworks now support a template plugin API
> known as Buffet and utilize the python.templating.engines entry_point in
> setup.py. As such I think there should be a new category:
>
> Environment :: Web Environment :: Buffet
>
> This API is currently supported by (at least) TurboGears, CherryPy and
> Pylons.

Added. Sorry for the delay.


    Richard

From constant.beta at gmail.com  Fri Jan 19 18:06:00 2007
From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=)
Date: Fri, 19 Jan 2007 18:06:00 +0100
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <200701191553.11648.richardjones@optushome.com.au>
References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
Message-ID: <5e8b0f6b0701190906k46282764nae68f7938afad38e@mail.gmail.com>

On 1/19/07, Richard Jones <richardjones at optushome.com.au> wrote:
> On Friday 19 January 2007 00:50, Micha? Kwiatkowski wrote:
> > Maybe this is a stupid question, but how can I list all versions of a
> > package that were registered on PyPI?
>
> You can get a full list through the XML-RPC interface:
>
>     http://wiki.python.org/moin/CheeseShopXmlRpc
>
> Specifically the package_releases method.

Would you accept a patch that adds this kind of functionality to the
PyPI web interface? Specifically I'm thinking about "show all
versions" link that returns a page with full list of package releases.

Cheers,
mk

From pje at telecommunity.com  Fri Jan 19 18:46:20 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 19 Jan 2007 12:46:20 -0500
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <200701191553.11648.richardjones@optushome.com.au>
References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
Message-ID: <7.0.1.0.0.20070119124425.021ad550@telecommunity.com>

At 11:53 PM 1/18/2007, Richard Jones wrote:
>Specifically the package_releases method.

That method only lists non-hidden versions; the OP wanted to know how 
to get information on *all* versions.


>The XML-RPC release_data method might tell you this information. I'm 
>not sure how people are coding the repository information into their 
>package meta-data.

You'd need to convert the release_data into HTML, or have some other 
way to extract the URLs from it.


From richardjones at optushome.com.au  Fri Jan 19 21:55:08 2007
From: richardjones at optushome.com.au (Richard Jones)
Date: Sat, 20 Jan 2007 07:55:08 +1100
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
	<7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
Message-ID: <200701200755.09303.richardjones@optushome.com.au>

On Saturday 20 January 2007 04:46, you wrote:
> At 11:53 PM 1/18/2007, Richard Jones wrote:
> >Specifically the package_releases method.
>
> That method only lists non-hidden versions; the OP wanted to know how
> to get information on *all* versions.

Versions are hidden by the package maintainer for a reason. Why would you want 
to override that?

I'll grant that the current auto-hiding of old releases might hide some 
releases that some package maintainers might have wanted to keep public, and 
that the mechanism for keeping older releases visible is a little cumbersome, 
but there are some package maintainers who do put in the effort to explicitly 
keep some older versions exposed.


> >The XML-RPC release_data method might tell you this information. I'm
> >not sure how people are coding the repository information into their
> >package meta-data.
>
> You'd need to convert the release_data into HTML, or have some other
> way to extract the URLs from it.

Unless I'm missing something, release_data is "converted to HTML" in the web 
interface already - that's what the release display page is for.


    Richard

From richardjones at optushome.com.au  Fri Jan 19 21:56:38 2007
From: richardjones at optushome.com.au (Richard Jones)
Date: Sat, 20 Jan 2007 07:56:38 +1100
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <5e8b0f6b0701190906k46282764nae68f7938afad38e@mail.gmail.com>
References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
	<5e8b0f6b0701190906k46282764nae68f7938afad38e@mail.gmail.com>
Message-ID: <200701200756.38522.richardjones@optushome.com.au>

On Saturday 20 January 2007 04:06, Micha? Kwiatkowski wrote:
> On 1/19/07, Richard Jones <richardjones at optushome.com.au> wrote:
> > On Friday 19 January 2007 00:50, Micha? Kwiatkowski wrote:
> > > Maybe this is a stupid question, but how can I list all versions of a
> > > package that were registered on PyPI?
> >
> > You can get a full list through the XML-RPC interface:
> >
> >     http://wiki.python.org/moin/CheeseShopXmlRpc
> >
> > Specifically the package_releases method.
>
> Would you accept a patch that adds this kind of functionality to the
> PyPI web interface? Specifically I'm thinking about "show all
> versions" link that returns a page with full list of package releases.

Sure.


    Richard

From martin at v.loewis.de  Sat Jan 20 00:39:18 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 20 Jan 2007 00:39:18 +0100
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>	<200701191553.11648.richardjones@optushome.com.au>
	<7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
Message-ID: <45B156A6.8070501@v.loewis.de>

Phillip J. Eby schrieb:
>> Specifically the package_releases method.
> 
> That method only lists non-hidden versions; the OP wanted to know how 
> to get information on *all* versions.

He might have said that; I doubt he really meant it (of course, only
the OP can clarify here).

Regards,
Martin

From constant.beta at gmail.com  Sat Jan 20 02:12:09 2007
From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=)
Date: Sat, 20 Jan 2007 02:12:09 +0100
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <45B156A6.8070501@v.loewis.de>
References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
	<7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
	<45B156A6.8070501@v.loewis.de>
Message-ID: <5e8b0f6b0701191712x1f659807wd60f81234f9c6f65@mail.gmail.com>

On 1/20/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Phillip J. Eby schrieb:
> >> Specifically the package_releases method.
> >
> > That method only lists non-hidden versions; the OP wanted to know how
> > to get information on *all* versions.
>
> He might have said that; I doubt he really meant it (of course, only
> the OP can clarify here).

I meant listing all releases that can be installed via command
"easy_install package==release". If hidden versions can't be installed
this way I don't want them listed. The problem as I see it is that
although easy_install can find all possible versions they are not
listed on PyPI. I think this kind of asymmetry is bad for usability. I
would like to work out this problem in two steps. First, port
package_releases RPC to WWW interface (which will list all non-hidden
versions). Second, use setuptools mechanisms to discover additional
versions in package description (as described here:
http://peak.telecommunity.com/DevCenter/setuptools#making-your-package-available-for-easyinstall).
First is straightforward and second a bit harder, as I don't know
setuptools codebase as well as PyPI's. This all can hopefully be
worked out.

Cheers,
mk

From rmunn at pobox.com  Sun Jan 21 10:46:13 2007
From: rmunn at pobox.com (Robin Munn)
Date: Sun, 21 Jan 2007 10:46:13 +0100
Subject: [Catalog-sig] Cheeseshop: How do I find someone's email address?
Message-ID: <e9b2421d0701210146vc93e8f5t8c1f97416da88d85@mail.gmail.com>

Say I notice that the Cheeseshop entry for the SpamSpamEggsAndSpam
module needs to be updated. (Perhaps it points to an out-of-date URL).
I can see that the Cheese Shop Owner of that module is HungryViking,
and I want to give him an email nudge to update the entry. But how
would I find HungryViking's email address?

-- 
Robin Munn
rmunn at pobox.com
GPG key 0x4543D577

From richardjones at optushome.com.au  Sun Jan 21 21:48:34 2007
From: richardjones at optushome.com.au (Richard Jones)
Date: Mon, 22 Jan 2007 07:48:34 +1100
Subject: [Catalog-sig] Cheeseshop: How do I find someone's email address?
In-Reply-To: <e9b2421d0701210146vc93e8f5t8c1f97416da88d85@mail.gmail.com>
References: <e9b2421d0701210146vc93e8f5t8c1f97416da88d85@mail.gmail.com>
Message-ID: <200701220748.34609.richardjones@optushome.com.au>

On Sunday 21 January 2007 20:46, Robin Munn wrote:
> Say I notice that the Cheeseshop entry for the SpamSpamEggsAndSpam
> module needs to be updated. (Perhaps it points to an out-of-date URL).
> I can see that the Cheese Shop Owner of that module is HungryViking,
> and I want to give him an email nudge to update the entry. But how
> would I find HungryViking's email address?

At the moment you ask for support and I handle the enquiry manually. Given 
that I get asked for this kind of thing about once a year it seems a 
reasonable way to handle things.


    Richard

From renesd at gmail.com  Mon Jan 22 07:45:34 2007
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Mon, 22 Jan 2007 17:45:34 +1100
Subject: [Catalog-sig] pypi caching. Can I please have apache config to test?
Message-ID: <64ddb72c0701212245r17dbc9bbo9e6129133b0d939c@mail.gmail.com>

Hi,

I would like to help with caching pypi - so that browsing categories is faster.

If the site is using apache 2, or 2.2 this can be done with the apache
cache module.

Could I please get the database dump, the current apache config, as
well as everything else needed to test it out?

I've read this page on development of pypi:
http://wiki.python.org/moin/CheeseShopDev


Richard:  is this the place to discuss pypi dev?  Or should I just
email you directly.


Cheers,

From richardjones at optushome.com.au  Mon Jan 22 08:04:41 2007
From: richardjones at optushome.com.au (Richard Jones)
Date: Mon, 22 Jan 2007 18:04:41 +1100
Subject: [Catalog-sig] pypi caching. Can I please have apache config to
	test?
In-Reply-To: <64ddb72c0701212245r17dbc9bbo9e6129133b0d939c@mail.gmail.com>
References: <64ddb72c0701212245r17dbc9bbo9e6129133b0d939c@mail.gmail.com>
Message-ID: <200701221804.41949.richardjones@optushome.com.au>

On Monday 22 January 2007 17:45, Ren? Dudfield wrote:
> I would like to help with caching pypi - so that browsing categories is
> faster.
>
> If the site is using apache 2, or 2.2 this can be done with the apache
> cache module.
>
> Could I please get the database dump, the current apache config, as
> well as everything else needed to test it out?
>
> I've read this page on development of pypi:
> http://wiki.python.org/moin/CheeseShopDev
>
>
> Richard:  is this the place to discuss pypi dev?  Or should I just
> email you directly.

This is more of a discussion forum for ideas - and sometimes support 
requests ;)

Direct email is fine for the above stuff. I'll try to get the dump for you 
tomorrow (I'm just heading out of the house for the night now, sorry). I'm 
also not certain of the apache version, but IIRC it is 2+


    Richard

From pje at telecommunity.com  Mon Jan 22 16:17:51 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 22 Jan 2007 10:17:51 -0500
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <5e8b0f6b0701191712x1f659807wd60f81234f9c6f65@mail.gmail.co
 m>
References: <45B156A6.8070501@v.loewis.de>
	<5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
	<7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
	<45B156A6.8070501@v.loewis.de>
Message-ID: <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com>

At 02:12 AM 1/20/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
>The problem as I see it is that
>although easy_install can find all possible versions they are not
>listed on PyPI.

I'm confused.  easy_install can only find versions that are listed on 
PyPI.  If there is a download link or homepage link on PyPI that points to 
a page with lots of downloadable versions, easy_install can discover them 
from there, but that's not something you're going to get through any PyPI API.


From constant.beta at gmail.com  Mon Jan 22 17:15:26 2007
From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=)
Date: Mon, 22 Jan 2007 17:15:26 +0100
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com>
References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
	<7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
	<45B156A6.8070501@v.loewis.de>
	<5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com>
Message-ID: <5e8b0f6b0701220815y16bd69d3u41582f30e5ddf126@mail.gmail.com>

On 1/22/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 02:12 AM 1/20/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
> >The problem as I see it is that
> >although easy_install can find all possible versions they are not
> >listed on PyPI.
>
> I'm confused.  easy_install can only find versions that are listed on
> PyPI.  If there is a download link or homepage link on PyPI that points
> to a page with lots of downloadable versions, easy_install can discover
> them from there, but that's not something you're going to get through any
> PyPI API.

Setuptools is too smart. ;) The question I'm trying to get an answer
for is: "what versions of foobar can I install?". Going to
http://python.org/pypi/foobar doesn't yield me any useful results - it
just shows the latest release. It's not so uncommon for projects to
have more than one official release - even as simple as development
and stable branches. They can be installed via easy_install and
setuptools is great at finding out the download locations, but there's
no easy way to see what options are available from a PyPI project
page. For starters, there is no "list all releases" page, and that's
what my mail is mainly about.

But I also have another doubt, related to this discussion. Should PyPI
be treated more as a proxy or a repository? If it's a proxy, it's
perfectly OK to just point people to relevant sites, when they can
learn their installation options on their own. On the other hand, PyPI
is a part of setuptools chain, which is a base of Python package
distribution, and that means it simply cannot be treated as a plain
proxy.

Ambiguity may come from the fact that, opposed to its name, PyPI isn't
a simple index of packages. It is also an infrastructure that makes
distribution of Python packages easy. PyPI isn't only about indexing
packages, but also about making them publicly available for vast
community of Python developers. I understand that to encourage
developers to list their packages on PyPI some compromises had to be
made. Smart functionality built in into setuptools make a transition
as simple as putting a link to project homepage into PyPI package
info. Question is how long this transitional state should be kept?
Currently we have a lot more logic in the client (easy_install) than
in the server (PyPI). So now we have this strange situation when an
installation client knows more about a package than the packages
server. Shouldn't we constantly move toward removing magic from
setuptools and porting important bits to PyPI?

Cheers,
mk

From pje at telecommunity.com  Mon Jan 22 18:54:32 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 22 Jan 2007 12:54:32 -0500
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <5e8b0f6b0701220815y16bd69d3u41582f30e5ddf126@mail.gmail.co
 m>
References: <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com>
	<5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
	<7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
	<45B156A6.8070501@v.loewis.de>
	<5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com>

At 05:15 PM 1/22/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
>Currently we have a lot more logic in the client (easy_install) than
>in the server (PyPI). So now we have this strange situation when an
>installation client knows more about a package than the packages
>server. Shouldn't we constantly move toward removing magic from
>setuptools and porting important bits to PyPI?

I dunno.  What actual problem are you trying to solve, or what use case are 
you trying to support?  For example, why do you want to know what versions 
are available *in an automated way*?


From constant.beta at gmail.com  Tue Jan 23 03:54:46 2007
From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=)
Date: Tue, 23 Jan 2007 03:54:46 +0100
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com>
References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
	<7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
	<45B156A6.8070501@v.loewis.de>
	<5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com>
	<5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com>
Message-ID: <5e8b0f6b0701221854j1dc293f2g8652ff080cb4e44@mail.gmail.com>

On 1/22/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 05:15 PM 1/22/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
> >Currently we have a lot more logic in the client (easy_install) than
> >in the server (PyPI). So now we have this strange situation when an
> >installation client knows more about a package than the packages
> >server. Shouldn't we constantly move toward removing magic from
> >setuptools and porting important bits to PyPI?
>
> I dunno.  What actual problem are you trying to solve, or what use case
> are you trying to support?

Cleaner architecture probably. Or is sourceforge magic going to stay?
I always thought sourceforge support was temporary, just to ease
migration toward setuptools.

> For example, why do you want to know what versions are available *in an
> automated way*?

Why we write programs at all? To automate things we don't want to
repeatedly do ourselves. If setuptools is so good at finding available
versions of a package, why should we force user to find these
information themself? If we can take out pain from PyPI user
experience, we should do it. You already done that for finding out
download locations with easy_install. Users don't have to click links
and find eggs themselves. The same goes for finding out available
versions. Since this data is already available to setuptools I really
don't understand why we should not port this to PyPI, so that users
will be able to check their options even without setuptools installed.

Maybe you ask about why on earth someone needs a list of releases?
Well, maybe someone finds a bug in current release and want to try
earlier version. If the current release is 0.8 how user will know what
was the previous? Was it 0.7? 0.7.5? Maybe 0.8rc3? Of course there are
more use cases. I don't really understand why this have to be
explained - probably each package index out there (freshmeat, CPAN,
rubyforge, sourceforge, berlios) have a list of releases available. Of
course there is a possibility that this functionality is useless and
I'm the only one that needs it, but IMHO chances for that are slim.

The thing with PyPI is that it really needs usability improvements. We
hear complains from time to time on this list, sometimes in
blogosphere, about things like non-functional search or broken links
etc. Complains aren't the problem - because we can react to these -
problem is with general user experience. If a user won't find what he
is looking for on PyPI he probably won't shout about it, but will go
somewhere else (like CPAN or Rubygems). "We don't need this because
nobody asked for it" is a really bad excuse. Setuptools may do a great
job at the low level but the whole system may suck because user is
pushed off because of bad PyPI experience.

Having said that I'll try to propose few more improvements in oncoming
weeks, that will make PyPI experience better, I hope. If you have any
suggestions on what is lacking, I will love to hear them.

Cheers,
mk

From pje at telecommunity.com  Tue Jan 23 06:15:02 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 23 Jan 2007 00:15:02 -0500
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <5e8b0f6b0701221854j1dc293f2g8652ff080cb4e44@mail.gmail.com
 >
References: <5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com>
	<5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
	<7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
	<45B156A6.8070501@v.loewis.de>
	<5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com>
	<5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com>

At 03:54 AM 1/23/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
>On 1/22/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > At 05:15 PM 1/22/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
> > >Currently we have a lot more logic in the client (easy_install) than
> > >in the server (PyPI). So now we have this strange situation when an
> > >installation client knows more about a package than the packages
> > >server. Shouldn't we constantly move toward removing magic from
> > >setuptools and porting important bits to PyPI?
> >
> > I dunno.  What actual problem are you trying to solve, or what use case
> > are you trying to support?
>
>Cleaner architecture probably.

To accomplish what goals?  "Cleaner" can't be defined without reference to 
some goal, like reduction of bugs, ease of extension/change, etc.


>  Or is sourceforge magic going to stay?
>I always thought sourceforge support was temporary, just to ease
>migration toward setuptools.

The SourceForge magic is essentially gone as of 0.6c5; SourceForge fixed 
their system so that neither screenscraping nor SF URL recognition is required.


> > For example, why do you want to know what versions are available *in an
> > automated way*?
>
>Why we write programs at all? To automate things we don't want to
>repeatedly do ourselves. If setuptools is so good at finding available
>versions of a package, why should we force user to find these
>information themself?

I still don't understand you.  What will they be using that information *for*?


>  If we can take out pain from PyPI user
>experience, we should do it.

You haven't shown that the absence of this information is causing anybody 
any pain, beause I don't know what you are expecting anybody to *do* with 
this information.  I can't say I have ever needed this; I just install the 
latest version, or I specify a specific version.

I can't recall ever wanting to find out "what versions are available", in 
other words.  So I still don't know what problem you're trying to solve.


>Maybe you ask about why on earth someone needs a list of releases?

Yes.

>Well, maybe someone finds a bug in current release and want to try
>earlier version. If the current release is 0.8 how user will know what
>was the previous? Was it 0.7? 0.7.5? Maybe 0.8rc3?

"easy_install 'thepackage<0.8'" will find it and install it.


>Of course there are more use cases.

Such as?


>I don't really understand why this have to be
>explained - probably each package index out there (freshmeat, CPAN,
>rubyforge, sourceforge, berlios) have a list of releases available.

So does PyPI - you just have to manually follow the links right now, unless 
you want it in *machine-readable* form (e.g. so you can then display it to 
the user).

So, the use case of "I just want to know what releases are available" is 
handled already, if you assume a human user.  It may not be *convenient*, 
but it is clearly *possible*.


>"We don't need this because nobody asked for it" is a really bad excuse

You seem to be under the impression that I said the feature isn't 
needed.  In fact, I am *still* merely trying to find out what problem you 
are trying to solve!

This is an essential first step before trying to design a solution, but you 
appear to be under the impression that people should somehow telepathically 
know what problem you are trying to solve, perhaps by reverse-engineering 
your proposed solution (which is underspecified in any event).

I think perhaps that you are also under the mistaken impression that I have 
anything to do with how PyPI is maintained, developed, or operated; I only 
maintain setuptools, so anything you want done server-side is another 
issue.  setuptools uses PyPI, but the two are conceptually distinct (unlike 
say, CPAN, where the client and server are more-or-less considered parts of 
one whole).


>Having said that I'll try to propose few more improvements in oncoming
>weeks, that will make PyPI experience better, I hope. If you have any
>suggestions on what is lacking, I will love to hear them.

Certainly there are UI (and other) improvements to PyPI that I would like 
to see, and I've proposed/requested many of them on this list more than 
once in the past.  However, in the absence of volunteers to *implement* 
those requested improvements, there is unlikely to be any change in the 
status quo.


From constant.beta at gmail.com  Sat Jan 27 18:07:51 2007
From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=)
Date: Sat, 27 Jan 2007 18:07:51 +0100
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com>
References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
	<7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
	<45B156A6.8070501@v.loewis.de>
	<5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com>
	<5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com>
	<5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com>
Message-ID: <5e8b0f6b0701270907i5260d512wcf6c4faec1c23268@mail.gmail.com>

On 1/23/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 03:54 AM 1/23/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
> >  Or is sourceforge magic going to stay?
> >I always thought sourceforge support was temporary, just to ease
> >migration toward setuptools.
>
> The SourceForge magic is essentially gone as of 0.6c5; SourceForge fixed
> their system so that neither screenscraping nor SF URL recognition is
> required.

Still sourceforge is treated in a special way. Users of other systems
have to manually put their links/files on PyPI. Is this special
support going to stay? And is it working, for example, with
BerliOS-hosted projects?

> >Well, maybe someone finds a bug in current release and want to try
> >earlier version. If the current release is 0.8 how user will know what
> >was the previous? Was it 0.7? 0.7.5? Maybe 0.8rc3?
>
> "easy_install 'thepackage<0.8'" will find it and install it.

What if user doesn't have easy_install installed when he is looking
for an answer? Maybe he knows where in the code the problem lies, so
he want to check earlier versions' code without installing? Maybe he
want to skim through changelog?

> >Of course there are more use cases.
>
> Such as?

You said sometimes you need a specific release. So you may be told you
need 0.7. You may just go and try to do easy_install==0.7. Or you may
look at list of releases and check if 0.7.5 is there. 0.8rc2 won't buy
it, so doing easy_install<0.8 won't work here.

Sometimes you're just looking at available libraries for doing a
specific task. You may want to look at a few versions of a package
from any computer, even if it doesn't have easy_install installed (or
even Python for that matter). PyPI should be usable on itself, it's a
web interface after all. We can't assume that every PyPI user have
easy_install on his local machine.

List of packages is also useful for historical reasons. A library that
had few dozens of releases starting from 2003 is probably better
tested than a library with three versions released this year.

> >I don't really understand why this have to be
> >explained - probably each package index out there (freshmeat, CPAN,
> >rubyforge, sourceforge, berlios) have a list of releases available.
>
> So does PyPI - you just have to manually follow the links right now,
> unless you want it in *machine-readable* form (e.g. so you can then
> display it to the user).

What links? Where are the links for all published releases of a given
package? Did I miss something?

> >"We don't need this because nobody asked for it" is a really bad excuse
>
> You seem to be under the impression that I said the feature isn't
> needed.  In fact, I am *still* merely trying to find out what problem you
> are trying to solve!

Again: "PyPI can't show a list of package releases" (isn't this in a
message subject?). Is this a problem? Maybe not. Does other popular
package indexes have it? Yes. (I don't even know one which doesn't
have it) It may be that everyone is wrong and solved non-existing
problem with this functionality, but I goes not.

> I think perhaps that you are also under the mistaken impression that I
> have anything to do with how PyPI is maintained, developed, or operated;
> I only maintain setuptools, so anything you want done server-side is
> another issue.  setuptools uses PyPI, but the two are conceptually
> distinct (unlike say, CPAN, where the client and server are more-or-less
> considered parts of one whole).

I think who mantains what isn't an issue here. What matters is user
experience and this binds PyPI and setuptools very tightly.

> >Having said that I'll try to propose few more improvements in oncoming
> >weeks, that will make PyPI experience better, I hope. If you have any
> >suggestions on what is lacking, I will love to hear them.
>
> Certainly there are UI (and other) improvements to PyPI that I would like
> to see, and I've proposed/requested many of them on this list more than
> once in the past.  However, in the absence of volunteers to *implement*
> those requested improvements, there is unlikely to be any change in the
> status quo.

Talking about whenever an average PyPI user would need a given
functionality won't change it either. So lets just say I'll implement
this, it will get merged and we'll look at some PyPI logs after some
time. If people use it (for whatever reason) - it will stay.

I'm currently during my exam session but it will hopefully end soon,
so I'll have some time under my belt to implement some functionality
for PyPI. Feel free to post your list of changes you'd like to see in
PyPI, so we'd have better understanding of what is needed. Or even
better: update TODO on http://wiki.python.org/moin/CheeseShopDev (I
don't know if it's up-to-date and represent real needs, so claryfing
that would be nice as well).

Cheers,
mk

From pje at telecommunity.com  Sat Jan 27 18:40:45 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 27 Jan 2007 12:40:45 -0500
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <5e8b0f6b0701270907i5260d512wcf6c4faec1c23268@mail.gmail.co
 m>
References: <5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com>
	<5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
	<7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
	<45B156A6.8070501@v.loewis.de>
	<5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com>
	<5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com>
	<5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20070127122938.0280c100@sparrow.telecommunity.com>

At 06:07 PM 1/27/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
>On 1/23/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > At 03:54 AM 1/23/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
> > >  Or is sourceforge magic going to stay?
> > >I always thought sourceforge support was temporary, just to ease
> > >migration toward setuptools.
> >
> > The SourceForge magic is essentially gone as of 0.6c5; SourceForge fixed
> > their system so that neither screenscraping nor SF URL recognition is
> > required.
>
>Still sourceforge is treated in a special way.

Uh, no, it isn't.


>  Users of other systems
>have to manually put their links/files on PyPI.

So do users of SourceForge.


>Is this special
>support going to stay? And is it working, for example, with
>BerliOS-hosted projects?

If your "Home Page" or "Download URL" on PyPI is a page that contains 
direct download links, easy_install will recognize them.  This means that 
if your Download URL is a SF files page, the links will get recognized.  If 
BerliOS or whatever has similar pages, and somebody links the right page 
from their download URL, then it should also work.


> > >Well, maybe someone finds a bug in current release and want to try
> > >earlier version. If the current release is 0.8 how user will know what
> > >was the previous? Was it 0.7? 0.7.5? Maybe 0.8rc3?
> >
> > "easy_install 'thepackage<0.8'" will find it and install it.
>
>What if user doesn't have easy_install installed when he is looking
>for an answer? Maybe he knows where in the code the problem lies, so
>he want to check earlier versions' code without installing? Maybe he
>want to skim through changelog?

And how is that a requirement for an automated list of versions?  All of 
that is stuff that requires manual searching anyway; the data that 
easy_install gathers isn't going to help you there.


>PyPI should be usable on itself, it's a web interface after all.

Yep, and it works just fine.  See, it has a "home page" link where people 
can go to the project's actual home page to find things out about it.


>What links? Where are the links for all published releases of a given
>package? Did I miss something?

PyPI shows the packages the owner has chosen to show.  If the owner doesn't 
show old releases, that's his or her choice.


> > >"We don't need this because nobody asked for it" is a really bad excuse
> >
> > You seem to be under the impression that I said the feature isn't
> > needed.  In fact, I am *still* merely trying to find out what problem you
> > are trying to solve!
>
>Again: "PyPI can't show a list of package releases" (isn't this in a
>message subject?).

I still fail to see why this is a problem.  It's not PyPI's job to show 
releases a package owner has chosen to hide.

However, you could argue perhaps that the mere act of creating a new 
release shouldn't cause older releases to become hidden -- in other words, 
showing releases by default instead of hiding them.  You could also argue 
for changelog-like features, or other features.

What is still NOT clear -- because you still haven't explained it -- is why 
this information needs to be available to automated tools, as opposed to 
simply being available to humans through the web interface.  None of the 
use cases you've presented seem to call for an automated tool.


From renesd at gmail.com  Sun Jan 28 00:21:02 2007
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Sun, 28 Jan 2007 10:21:02 +1100
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <5.1.1.6.0.20070127122938.0280c100@sparrow.telecommunity.com>
References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
	<7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
	<45B156A6.8070501@v.loewis.de>
	<5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com>
	<5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com>
	<5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com>
	<5.1.1.6.0.20070127122938.0280c100@sparrow.telecommunity.com>
Message-ID: <64ddb72c0701271521l39682893x767c017d59c4c068@mail.gmail.com>

On 1/28/07, Phillip J. Eby <pje at telecommunity.com> wrote:
>
> What is still NOT clear -- because you still haven't explained it -- is why
> this information needs to be available to automated tools, as opposed to
> simply being available to humans through the web interface.  None of the
> use cases you've presented seem to call for an automated tool.


For tools which make interfaces to read pypi.  There is at least one
application that browses pypi that is not the web based interface.

From pje at telecommunity.com  Sun Jan 28 02:44:28 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 27 Jan 2007 20:44:28 -0500
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <64ddb72c0701271521l39682893x767c017d59c4c068@mail.gmail.co
 m>
References: <5.1.1.6.0.20070127122938.0280c100@sparrow.telecommunity.com>
	<5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
	<7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
	<45B156A6.8070501@v.loewis.de>
	<5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com>
	<5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com>
	<5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com>
	<5.1.1.6.0.20070127122938.0280c100@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20070127204400.028a8a98@sparrow.telecommunity.com>

At 10:21 AM 1/28/2007 +1100, Ren? Dudfield wrote:
>On 1/28/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> >
> > What is still NOT clear -- because you still haven't explained it -- is why
> > this information needs to be available to automated tools, as opposed to
> > simply being available to humans through the web interface.  None of the
> > use cases you've presented seem to call for an automated tool.
>
>
>For tools which make interfaces to read pypi.  There is at least one
>application that browses pypi that is not the web based interface.

And all the information available to it is exactly the same as what a human 
user obtains, no?


From renesd at gmail.com  Sun Jan 28 03:50:44 2007
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Sun, 28 Jan 2007 13:50:44 +1100
Subject: [Catalog-sig] How to get a list of package releases
In-Reply-To: <5.1.1.6.0.20070127204400.028a8a98@sparrow.telecommunity.com>
References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com>
	<200701191553.11648.richardjones@optushome.com.au>
	<7.0.1.0.0.20070119124425.021ad550@telecommunity.com>
	<45B156A6.8070501@v.loewis.de>
	<5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com>
	<5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com>
	<5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com>
	<5.1.1.6.0.20070127122938.0280c100@sparrow.telecommunity.com>
	<5.1.1.6.0.20070127204400.028a8a98@sparrow.telecommunity.com>
Message-ID: <64ddb72c0701271850q49299fav7465846aa9909853@mail.gmail.com>

It uses the xmlrpc interface.  Not sure if that answers your question.

On 1/28/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 10:21 AM 1/28/2007 +1100, Ren? Dudfield wrote:
> >On 1/28/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > >
> > > What is still NOT clear -- because you still haven't explained it -- is why
> > > this information needs to be available to automated tools, as opposed to
> > > simply being available to humans through the web interface.  None of the
> > > use cases you've presented seem to call for an automated tool.
> >
> >
> >For tools which make interfaces to read pypi.  There is at least one
> >application that browses pypi that is not the web based interface.
>
> And all the information available to it is exactly the same as what a human
> user obtains, no?
>
>

From ghazel at gmail.com  Tue Jan 30 23:54:02 2007
From: ghazel at gmail.com (ghazel at gmail.com)
Date: Tue, 30 Jan 2007 14:54:02 -0800
Subject: [Catalog-sig] greenlets
Message-ID: <151643b20701301454n561b990ey8bcb78886ae05463@mail.gmail.com>

I have noticed the greenlet module
http://cheeseshop.python.org/pypi/greenlet

is out of date with the library it is copied from
http://codespeak.net/py/

I recently submitted a bug fix for this package in py.lib, and it's possible
I'm the only developer actively working on greenlets. If Bob would rather,
I'd like to be the package maintainer of the cheeseshop greenlet module.

-Greg Hazel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/catalog-sig/attachments/20070130/266aee9b/attachment.html 

From bob at redivi.com  Wed Jan 31 00:10:04 2007
From: bob at redivi.com (Bob Ippolito)
Date: Tue, 30 Jan 2007 15:10:04 -0800
Subject: [Catalog-sig] greenlets
In-Reply-To: <151643b20701301454n561b990ey8bcb78886ae05463@mail.gmail.com>
References: <151643b20701301454n561b990ey8bcb78886ae05463@mail.gmail.com>
Message-ID: <6a36e7290701301510h30110ec2qcced91779904b5c2@mail.gmail.com>

That works for me. What's your CheeseShop user name?

-bob

On 1/30/07, ghazel at gmail.com <ghazel at gmail.com> wrote:
> I have noticed the greenlet module
> http://cheeseshop.python.org/pypi/greenlet
>
> is out of date with the library it is copied from
> http://codespeak.net/py/
>
> I recently submitted a bug fix for this package in py.lib, and it's possible
> I'm the only developer actively working on greenlets. If Bob would rather,
> I'd like to be the package maintainer of the cheeseshop greenlet module.
>
> -Greg Hazel
> _______________________________________________
> Catalog-sig mailing list
> Catalog-sig at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
>
>

From ghazel at gmail.com  Wed Jan 31 00:28:12 2007
From: ghazel at gmail.com (ghazel at gmail.com)
Date: Tue, 30 Jan 2007 15:28:12 -0800
Subject: [Catalog-sig] greenlets
In-Reply-To: <6a36e7290701301510h30110ec2qcced91779904b5c2@mail.gmail.com>
References: <151643b20701301454n561b990ey8bcb78886ae05463@mail.gmail.com>
	<6a36e7290701301510h30110ec2qcced91779904b5c2@mail.gmail.com>
Message-ID: <151643b20701301528m65d38ff1o60e38249fe1589d6@mail.gmail.com>

ghazel

-Greg

On 1/30/07, Bob Ippolito <bob at redivi.com> wrote:
>
> That works for me. What's your CheeseShop user name?
>
> -bob
>
> On 1/30/07, ghazel at gmail.com <ghazel at gmail.com> wrote:
> > I have noticed the greenlet module
> > http://cheeseshop.python.org/pypi/greenlet
> >
> > is out of date with the library it is copied from
> > http://codespeak.net/py/
> >
> > I recently submitted a bug fix for this package in py.lib, and it's
> possible
> > I'm the only developer actively working on greenlets. If Bob would
> rather,
> > I'd like to be the package maintainer of the cheeseshop greenlet module.
> >
> > -Greg Hazel
> > _______________________________________________
> > Catalog-sig mailing list
> > Catalog-sig at python.org
> > http://mail.python.org/mailman/listinfo/catalog-sig
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/catalog-sig/attachments/20070130/d66e03e5/attachment.html 

From bob at redivi.com  Wed Jan 31 00:29:06 2007
From: bob at redivi.com (Bob Ippolito)
Date: Tue, 30 Jan 2007 15:29:06 -0800
Subject: [Catalog-sig] greenlets
In-Reply-To: <151643b20701301528m65d38ff1o60e38249fe1589d6@mail.gmail.com>
References: <151643b20701301454n561b990ey8bcb78886ae05463@mail.gmail.com>
	<6a36e7290701301510h30110ec2qcced91779904b5c2@mail.gmail.com>
	<151643b20701301528m65d38ff1o60e38249fe1589d6@mail.gmail.com>
Message-ID: <6a36e7290701301529p7a579054v73c7e20843b1a574@mail.gmail.com>

Done.

-bob

On 1/30/07, ghazel at gmail.com <ghazel at gmail.com> wrote:
> ghazel
>
> -Greg
>
>
> On 1/30/07, Bob Ippolito <bob at redivi.com> wrote:
> > That works for me. What's your CheeseShop user name?
> >
> > -bob
> >
> > On 1/30/07, ghazel at gmail.com <ghazel at gmail.com> wrote:
> > > I have noticed the greenlet module
> > > http://cheeseshop.python.org/pypi/greenlet
> > >
> > > is out of date with the library it is copied from
> > > http://codespeak.net/py/
> > >
> > > I recently submitted a bug fix for this package in py.lib, and it's
> possible
> > > I'm the only developer actively working on greenlets. If Bob would
> rather,
> > > I'd like to be the package maintainer of the cheeseshop greenlet module.
> > >
> > > -Greg Hazel
> > > _______________________________________________
> > > Catalog-sig mailing list
> > > Catalog-sig at python.org
> > > http://mail.python.org/mailman/listinfo/catalog-sig
> > >
> > >
> > >
> >
>
>