From kumar.mcmillan at gmail.com Fri Apr 6 21:48:26 2007
From: kumar.mcmillan at gmail.com (Kumar McMillan)
Date: Fri, 6 Apr 2007 14:48:26 -0500
Subject: [Catalog-sig] pypi performance troubles, time to revisit?
Message-ID: <b571660a0704061248v3c76b80bid4c5fb3bd0f15e19@mail.gmail.com>
Hello.
I keep getting "error: Download error: (54, 'Connection reset by
peer')" when running easy_install and a few days ago was getting very
slow response times.
Is it worth opening up this discussion again?
http://mail.python.org/pipermail/catalog-sig/2006-October/000957.html
Perhaps to organize some volunteer work? Revisit the idea of
supporting mirrors?
To my limited knowledge of the system, it seems that at least a way to
cache an index of package links (not necessarily a two-way mirror)
would be beneficial because one could point easy_install at said local
index and, say, continuously run a test suite that wants to install
some fresh eggs upon each run. All that without hitting pypi every
single time.
Kumar
From fdrake at gmail.com Fri Apr 6 23:20:34 2007
From: fdrake at gmail.com (Fred Drake)
Date: Fri, 6 Apr 2007 17:20:34 -0400
Subject: [Catalog-sig] pypi performance troubles, time to revisit?
In-Reply-To: <b571660a0704061248v3c76b80bid4c5fb3bd0f15e19@mail.gmail.com>
References: <b571660a0704061248v3c76b80bid4c5fb3bd0f15e19@mail.gmail.com>
Message-ID: <9cee7ab80704061420y6dc21630tdd20b8c10015138c@mail.gmail.com>
On 4/6/07, Kumar McMillan <kumar.mcmillan at gmail.com> wrote:
> I keep getting "error: Download error: (54, 'Connection reset by
> peer')" when running easy_install and a few days ago was getting very
> slow response times.
Something's wrong with the database server. The friendly folks at
python.org are looking into this.
-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 Sat Apr 7 18:44:56 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 07 Apr 2007 12:44:56 -0400
Subject: [Catalog-sig] Time for a static cheeseshop mirror for easy_install?
Message-ID: <5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com>
For what easy_install does, there really isn't any dynamic API usage, so a
static mirror for easy_install could take a good bit of load off the
cheeseshop.
I don't know whether this will actually solve any problems the cheeseshop
itself is having; it may be that ill-behaved web spiders are at fault, or
something else altogether. However, since the downtime mostly creates
issues for people using easy_install, creating a solution for those people
certainly seems worthwhile.
Since easy_install was designed to be able to use simple directory indexes
and HTML pages as a package index, it should be possible to create a simple
directory tree of HTML pages, using PyPI's public XML-RPC API. The mirror
could use PyPI's RSS feed to know when a package's information is out of
date, although I'm not sure that the RSS includes all modifications, such
as when packages are deleted, releases are hidden, files uploaded, etc.
However, assuming that there's a scalable way to receive change
notifications, it should be straightforward to implement a mirror script
for easy_install, and have it run on one or more volunteered hosts, perhaps
with round-robin DNS (maybe easy-install.python.org?)
I'll be happy to assist anyone who wants to work on this, including updates
to easy_install itself, of course. I'd actually be hacking on this now, if
the cheeseshop weren't down (i.e., I can't download any XML-RPC data to do
prototyping at the moment!)
From g.brandl at gmx.net Sun Apr 8 14:29:58 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 08 Apr 2007 14:29:58 +0200
Subject: [Catalog-sig] Time for a static cheeseshop mirror for
easy_install?
In-Reply-To: <5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com>
References: <5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com>
Message-ID: <evan86$qvk$1@sea.gmane.org>
Phillip J. Eby schrieb:
> For what easy_install does, there really isn't any dynamic API usage, so a
> static mirror for easy_install could take a good bit of load off the
> cheeseshop.
>
> I don't know whether this will actually solve any problems the cheeseshop
> itself is having; it may be that ill-behaved web spiders are at fault, or
> something else altogether. However, since the downtime mostly creates
> issues for people using easy_install, creating a solution for those people
> certainly seems worthwhile.
>
> Since easy_install was designed to be able to use simple directory indexes
> and HTML pages as a package index, it should be possible to create a simple
> directory tree of HTML pages, using PyPI's public XML-RPC API. The mirror
> could use PyPI's RSS feed to know when a package's information is out of
> date, although I'm not sure that the RSS includes all modifications, such
> as when packages are deleted, releases are hidden, files uploaded, etc.
>
> However, assuming that there's a scalable way to receive change
> notifications, it should be straightforward to implement a mirror script
> for easy_install, and have it run on one or more volunteered hosts, perhaps
> with round-robin DNS (maybe easy-install.python.org?)
The German Python community is willing to contribute a host for PyPI mirroring.
Just contact me as soon as some solution is found.
Georg
From martin at v.loewis.de Mon Apr 9 01:22:03 2007
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 09 Apr 2007 01:22:03 +0200
Subject: [Catalog-sig] Flamenco queries
Message-ID: <4619791B.7030506@v.loewis.de>
In studying the Cheeseshop code, I ran into flamenco.py, which
"represents a flamenco-style query". What is that?
It appears that it contains a fairly expensive SQL operation,
select rc.trove_id, r.name, r.version, r.summary
from releases r, release_classifiers rc
where r.name=rc.name and r.version=rc.version
and r._pypi_hidden=FALSE
Postgres' 'explain analyze' gives this for the query:
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------
Merge Join (cost=6130.46..6512.03 rows=3545 width=100) (actual
time=1069.206..1194.849 rows=13149 loops=1)
Merge Cond: (("outer"."version" = "inner"."version") AND
("outer".name = "inner".name))
-> Sort (cost=1009.16..1017.43 rows=3309 width=96) (actual
time=58.092..58.968 rows=2272 loops=1)
Sort Key: r."version", r.name
-> Seq Scan on releases r (cost=0.00..815.71 rows=3309
width=96) (actual time=0.050..18.740 rows=2272 loops=1)
Filter: (_pypi_hidden = false)
-> Sort (cost=5121.30..5228.40 rows=42841 width=68) (actual
time=1011.050..1039.380 rows=42841 loops=1)
Sort Key: rc."version", rc.name
-> Seq Scan on release_classifiers rc (cost=0.00..749.41
rows=42841 width=68) (actual time=0.052..68.960 rows=42841 loops=1)
Total runtime: 1200.133 ms
This operation is the result of accessing, say
/pypi?:action=browse&c=229&c=5
which gives a total of 5 packages.
What puzzles me is that the parameter of the URL (229 and 5) don't
occur in the query. Isn't there some cheaper way to achieve the
same result? After all, on my machine, this query runs for 1s!
I measured it on ximinez, and it reported a running time of 3.5s.
Regards,
Martin
From amk at amk.ca Mon Apr 9 01:34:17 2007
From: amk at amk.ca (A.M. Kuchling)
Date: Sun, 8 Apr 2007 19:34:17 -0400
Subject: [Catalog-sig] Flamenco queries
In-Reply-To: <4619791B.7030506@v.loewis.de>
References: <4619791B.7030506@v.loewis.de>
Message-ID: <20070408233417.GA15832@andrew-kuchlings-computer.local>
On Mon, Apr 09, 2007 at 01:22:03AM +0200, "Martin v. L?wis" wrote:
> In studying the Cheeseshop code, I ran into flamenco.py, which
> "represents a flamenco-style query". What is that?
"Flamenco" is historical -- Ping has a browsing interface called "Flamenco"
for another project, and the idea was borrowed for PyPI's browsing interface.
> What puzzles me is that the parameter of the URL (229 and 5) don't
> occur in the query. Isn't there some cheaper way to achieve the
> same result? After all, on my machine, this query runs for 1s!
It looks like the __init__ builds a data structure and then
get_matches() and list_choices() run off this structure. It would
certainly be worth fixing this!
--amk
From richardjones at optushome.com.au Mon Apr 9 02:01:55 2007
From: richardjones at optushome.com.au (Richard Jones)
Date: Mon, 9 Apr 2007 10:01:55 +1000
Subject: [Catalog-sig] Cheese Shop performance
Message-ID: <200704091001.55963.richardjones@optushome.com.au>
I've been quiet on the latest happenings because I've have my attention wholly
consumed by PyWeek and gettng a new job.
The performance issues are related to spiders crawling the wiki and the Cheese
Shop "browse" interface. The PyPI code attempts to prevent bots from
accessing that interface, but that requires that we know user-agent strings
in advance. And people are writing newer, dumber bots all the time :(
There's a very good chance that I'll be able to do some work over the next few
weeks on the baking ideas that Jim Fulton proposed at PyCon. This would make
most of the user interface (except the browse) static where it currently goes
through CGI for all requests. In that situation I'm not sure we'll need to
have mirrors, though it would certainly help if they were needed.
Richard
From martin at v.loewis.de Mon Apr 9 05:17:10 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 09 Apr 2007 05:17:10 +0200
Subject: [Catalog-sig] Flamenco queries
In-Reply-To: <20070408233417.GA15832@andrew-kuchlings-computer.local>
References: <4619791B.7030506@v.loewis.de>
<20070408233417.GA15832@andrew-kuchlings-computer.local>
Message-ID: <4619B036.50903@v.loewis.de>
> It looks like the __init__ builds a data structure and then
> get_matches() and list_choices() run off this structure. It would
> certainly be worth fixing this!
I have now committed a fix in PyPI (r441) which performs the computation
of selected entries in SQL, considerably improving browsing if
categories are selected.
If no categories are selected, browsing is still slow. This could be
improved by caching a tally table, as the standard browse page does
not need to report any package names (just a tally).
Is there any efficient way to compute a tally in PostgreSQL on the
fly?
Regards,
Martin
From pje at telecommunity.com Mon Apr 9 05:28:28 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 08 Apr 2007 23:28:28 -0400
Subject: [Catalog-sig] Flamenco queries
In-Reply-To: <4619B036.50903@v.loewis.de>
References: <20070408233417.GA15832@andrew-kuchlings-computer.local>
<4619791B.7030506@v.loewis.de>
<20070408233417.GA15832@andrew-kuchlings-computer.local>
Message-ID: <5.1.1.6.0.20070408232349.02d620b8@sparrow.telecommunity.com>
At 05:17 AM 4/9/2007 +0200, Martin v. L?wis wrote:
> > It looks like the __init__ builds a data structure and then
> > get_matches() and list_choices() run off this structure. It would
> > certainly be worth fixing this!
>
>I have now committed a fix in PyPI (r441) which performs the computation
>of selected entries in SQL, considerably improving browsing if
>categories are selected.
>
>If no categories are selected, browsing is still slow. This could be
>improved by caching a tally table, as the standard browse page does
>not need to report any package names (just a tally).
>
>Is there any efficient way to compute a tally in PostgreSQL on the
>fly?
Perhaps this?
select rc.trove_id, count(*)
from releases r, release_classifiers rc
where r.name=rc.name and r.version=rc.version
and r._pypi_hidden=FALSE
group by rc.trove_id
I'm basing this strictly off the other query you posted and with no real
knowledge of the schema, so I could be way off here. But it seems like
this should be very efficient if there is an index on (trove_id, name,
version) in the release classifiers table and one on (name, version,
_pypi_hidden) in the releases table. That would allow the query to be
executed entirely on the indexes without needing any table contents. Of
course, given the relatively small space of trove identifiers compared to
releases, some other scan pattern might be equally efficient I suppose.
From martin at v.loewis.de Mon Apr 9 12:00:39 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 09 Apr 2007 12:00:39 +0200
Subject: [Catalog-sig] Flamenco queries
In-Reply-To: <5.1.1.6.0.20070408232349.02d620b8@sparrow.telecommunity.com>
References: <20070408233417.GA15832@andrew-kuchlings-computer.local>
<4619791B.7030506@v.loewis.de>
<20070408233417.GA15832@andrew-kuchlings-computer.local>
<5.1.1.6.0.20070408232349.02d620b8@sparrow.telecommunity.com>
Message-ID: <461A0EC7.6000309@v.loewis.de>
> Perhaps this?
>
> select rc.trove_id, count(*)
> from releases r, release_classifiers rc
> where r.name=rc.name and r.version=rc.version
> and r._pypi_hidden=FALSE
> group by rc.trove_id
This did work indeed (although it was slower than when doing
the counting in Python...)
I found that it was semantically incorrect, as packages that
have multiple level-three trove ids should be counted only
once.
I ended up writing a cache for the browse page that gets
regenerated after five minutes (r443).
Regards,
Martin
From martin at v.loewis.de Mon Apr 9 13:29:52 2007
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 09 Apr 2007 13:29:52 +0200
Subject: [Catalog-sig] Performing exact matches in Cheeseshop URLs
Message-ID: <461A23B0.20705@v.loewis.de>
Currently, an URL like
http://cheeseshop.python.org/pypi/PyXML
will match all packages that have PyXML in their name.
Should that be changed to only listing packages which
have PyXML as their exact name? (it would still give
two entries, as there are two visible releases of
that package).
Regards,
Martin
From richardjones at optushome.com.au Mon Apr 9 13:42:05 2007
From: richardjones at optushome.com.au (Richard Jones)
Date: Mon, 9 Apr 2007 21:42:05 +1000
Subject: [Catalog-sig] Performing exact matches in Cheeseshop URLs
In-Reply-To: <461A23B0.20705@v.loewis.de>
References: <461A23B0.20705@v.loewis.de>
Message-ID: <200704092142.06128.richardjones@optushome.com.au>
On Mon, 9 Apr 2007, Martin v. L?wis wrote:
> Currently, an URL like
>
> http://cheeseshop.python.org/pypi/PyXML
>
> will match all packages that have PyXML in their name.
>
> Should that be changed to only listing packages which
> have PyXML as their exact name? (it would still give
> two entries, as there are two visible releases of
> that package).
I'd say it should be exact.
Currently the EasyInstall doc says "Individual project version pages' URLs
must be of the form base/projectname/version, where base is the package
index's base URL." But it's not clear whether it would use the current URL
behaviour as a form of searching. Phillip?
Richard
From martin at v.loewis.de Mon Apr 9 14:01:28 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 09 Apr 2007 14:01:28 +0200
Subject: [Catalog-sig] Performing exact matches in Cheeseshop URLs
In-Reply-To: <200704092142.06128.richardjones@optushome.com.au>
References: <461A23B0.20705@v.loewis.de>
<200704092142.06128.richardjones@optushome.com.au>
Message-ID: <461A2B18.6050703@v.loewis.de>
> Currently the EasyInstall doc says "Individual project version pages' URLs
> must be of the form base/projectname/version, where base is the package
> index's base URL."
Ok, I have changed it in r444. The original search semantics of that is
still available in /pypi?:action=index&name=PyXML
Regards,
Martin
From martin at v.loewis.de Mon Apr 9 14:36:53 2007
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 09 Apr 2007 14:36:53 +0200
Subject: [Catalog-sig] Full package list
Message-ID: <461A3365.1060209@v.loewis.de>
With the browse pages hidden from spiders, the search engines
cannot find out the complete list of packages anymore (AFAICT).
Would it be useful to have a page with just the names of all
packages, linking to pypi/<package>? It could go into the
navigation bar, below "List trove classifiers".
Regards,
Martin
From amk at amk.ca Mon Apr 9 16:46:30 2007
From: amk at amk.ca (A.M. Kuchling)
Date: Mon, 9 Apr 2007 10:46:30 -0400
Subject: [Catalog-sig] Time for a static cheeseshop mirror for
easy_install?
In-Reply-To: <5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com>
References: <5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com>
Message-ID: <20070409144630.GA10277@localhost.localdomain>
On Sat, Apr 07, 2007 at 12:44:56PM -0400, Phillip J. Eby wrote:
> I don't know whether this will actually solve any problems the cheeseshop
> itself is having; it may be that ill-behaved web spiders are at fault, or
> something else altogether.
In this recent case, two different spiders were crawling the wiki very
quickly, the machine's load average was in the 70s, and the
out-of-memory killer was killing off PostgreSQL processes.
I don't think the load caused from people running easy_install is
especially high -- it's certainly not a source of problems -- but
making static pages would still be good to make mirroring the package
archive more useful. Right now people could mirror
http://cheeseshop.python.org/packages/, but there's nothing there for
easy_install or for human readers; it's just a tree of package
directories.
--amk
From jim at zope.com Mon Apr 9 17:06:56 2007
From: jim at zope.com (Jim Fulton)
Date: Mon, 9 Apr 2007 11:06:56 -0400
Subject: [Catalog-sig] Time for a static cheeseshop mirror for
easy_install?
In-Reply-To: <20070409144630.GA10277@localhost.localdomain>
References: <5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com>
<20070409144630.GA10277@localhost.localdomain>
Message-ID: <E3E11B59-EDA5-4619-B8F8-42C90B3EDB57@zope.com>
On Apr 9, 2007, at 10:46 AM, A.M. Kuchling wrote:
...
> Right now people could mirror
> http://cheeseshop.python.org/packages/, but there's nothing there for
> easy_install
Is there any reason why easy_install shouldn't look there?
Jim
--
Jim Fulton mailto:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
From martin at v.loewis.de Mon Apr 9 17:32:20 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 09 Apr 2007 17:32:20 +0200
Subject: [Catalog-sig] Time for a static cheeseshop mirror
for easy_install?
In-Reply-To: <E3E11B59-EDA5-4619-B8F8-42C90B3EDB57@zope.com>
References: <5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com> <20070409144630.GA10277@localhost.localdomain>
<E3E11B59-EDA5-4619-B8F8-42C90B3EDB57@zope.com>
Message-ID: <461A5C84.8010101@v.loewis.de>
Jim Fulton schrieb:
> On Apr 9, 2007, at 10:46 AM, A.M. Kuchling wrote:
> ...
>> Right now people could mirror
>> http://cheeseshop.python.org/packages/, but there's nothing there for
>> easy_install
>
> Is there any reason why easy_install shouldn't look there?
It's only files, no descriptions.
Also, some authors don't have their files on /packages, but at their
own servers - i.e. they use the Cheeseshop just as a Python
package index, not as a comprehensive package archive network.
Regards,
Martin
From jim at zope.com Mon Apr 9 17:35:34 2007
From: jim at zope.com (Jim Fulton)
Date: Mon, 9 Apr 2007 11:35:34 -0400
Subject: [Catalog-sig] Time for a static cheeseshop mirror
for easy_install?
In-Reply-To: <461A5C84.8010101@v.loewis.de>
References: <5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com> <20070409144630.GA10277@localhost.localdomain>
<E3E11B59-EDA5-4619-B8F8-42C90B3EDB57@zope.com>
<461A5C84.8010101@v.loewis.de>
Message-ID: <56EE93DB-F8DB-476A-AD8A-ADE48E02C858@zope.com>
On Apr 9, 2007, at 11:32 AM, Martin v. L?wis wrote:
> Jim Fulton schrieb:
>> On Apr 9, 2007, at 10:46 AM, A.M. Kuchling wrote:
>> ...
>>> Right now people could mirror
>>> http://cheeseshop.python.org/packages/, but there's nothing there
>>> for
>>> easy_install
>>
>> Is there any reason why easy_install shouldn't look there?
>
> It's only files, no descriptions.
>
> Also, some authors don't have their files on /packages, but at their
> own servers - i.e. they use the Cheeseshop just as a Python
> package index, not as a comprehensive package archive network.
Sorry, I wasn't clear. I wasn't suggesting that easy_install should
look here instead of where it already looks, but this seems like a
good and cheap place to look especially when a specific version
number is given.
Jim
--
Jim Fulton mailto:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
From matt at matt-good.net Mon Apr 9 17:56:25 2007
From: matt at matt-good.net (Matt Good)
Date: Mon, 09 Apr 2007 11:56:25 -0400
Subject: [Catalog-sig] [Distutils] Time for a static cheeseshop mirror
for easy_install?
In-Reply-To: <5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com>
References: <5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com>
Message-ID: <1176134186.5675.4.camel@nny>
On Sat, 2007-04-07 at 12:44 -0400, Phillip J. Eby wrote:
> For what easy_install does, there really isn't any dynamic API usage, so a
> static mirror for easy_install could take a good bit of load off the
> cheeseshop.
Jon Rosebaugh (aka Chairos) actually started working on this a couple
days ago during a Cheeseshop downtime. I mentioned this post to him, so
he may join the list to follow up, but you can reach him on #python.web
to check on this.
-- Matt Good
From jeremy.kloth at 4suite.org Mon Apr 9 18:19:01 2007
From: jeremy.kloth at 4suite.org (Jeremy Kloth)
Date: Mon, 9 Apr 2007 10:19:01 -0600
Subject: [Catalog-sig] Full package list
In-Reply-To: <461A3365.1060209@v.loewis.de>
References: <461A3365.1060209@v.loewis.de>
Message-ID: <200704091019.02042.jeremy.kloth@4suite.org>
On Monday 09 April 2007 6:36:53 am Martin v. L?wis wrote:
> With the browse pages hidden from spiders, the search engines
> cannot find out the complete list of packages anymore (AFAICT).
>
> Would it be useful to have a page with just the names of all
> packages, linking to pypi/<package>? It could go into the
> navigation bar, below "List trove classifiers".
Do you mean a page like: http://cheeseshop.python.org/pypi?:action=index
I had that bookmarked from the old PyPI interface and could never seem to
locate that page on the newer Cheese Shop pages.
+1 to adding it back onto the navbar.
--
Jeremy Kloth
http://4suite.org/
From martin at v.loewis.de Mon Apr 9 19:21:49 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 09 Apr 2007 19:21:49 +0200
Subject: [Catalog-sig] Full package list
In-Reply-To: <200704091019.02042.jeremy.kloth@4suite.org>
References: <461A3365.1060209@v.loewis.de>
<200704091019.02042.jeremy.kloth@4suite.org>
Message-ID: <461A762D.8080100@v.loewis.de>
Jeremy Kloth schrieb:
> On Monday 09 April 2007 6:36:53 am Martin v. L?wis wrote:
>> With the browse pages hidden from spiders, the search engines
>> cannot find out the complete list of packages anymore (AFAICT).
>>
>> Would it be useful to have a page with just the names of all
>> packages, linking to pypi/<package>? It could go into the
>> navigation bar, below "List trove classifiers".
>
> Do you mean a page like: http://cheeseshop.python.org/pypi?:action=index
Oops, yes.
> I had that bookmarked from the old PyPI interface and could never seem to
> locate that page on the newer Cheese Shop pages.
> +1 to adding it back onto the navbar.
Meanwhile, I added
http://cheeseshop.python.org/pypi?%3Aaction=packagelist
but I guess I revert that in favour the index.
Regards,
Martin
From pje at telecommunity.com Mon Apr 9 19:54:16 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 09 Apr 2007 13:54:16 -0400
Subject: [Catalog-sig] Flamenco queries
In-Reply-To: <461A0EC7.6000309@v.loewis.de>
References: <5.1.1.6.0.20070408232349.02d620b8@sparrow.telecommunity.com>
<20070408233417.GA15832@andrew-kuchlings-computer.local>
<4619791B.7030506@v.loewis.de>
<20070408233417.GA15832@andrew-kuchlings-computer.local>
<5.1.1.6.0.20070408232349.02d620b8@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20070409135149.05052ec0@sparrow.telecommunity.com>
At 12:00 PM 4/9/2007 +0200, Martin v. L?wis wrote:
> > Perhaps this?
> >
> > select rc.trove_id, count(*)
> > from releases r, release_classifiers rc
> > where r.name=rc.name and r.version=rc.version
> > and r._pypi_hidden=FALSE
> > group by rc.trove_id
>
>This did work indeed (although it was slower than when doing
>the counting in Python...)
It would only be efficient if there were indexes the optimizer could use;
without at least an index beginning with trove_id, a temporary table would
be required to build the result.
>I found that it was semantically incorrect, as packages that
>have multiple level-three trove ids should be counted only
>once.
Ah... that would require something like "count(distinct name+version)"
instead of count(*), so the Python approach is probably best.
From pje at telecommunity.com Mon Apr 9 20:00:34 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 09 Apr 2007 14:00:34 -0400
Subject: [Catalog-sig] Performing exact matches in Cheeseshop URLs
In-Reply-To: <200704092142.06128.richardjones@optushome.com.au>
References: <461A23B0.20705@v.loewis.de>
<461A23B0.20705@v.loewis.de>
Message-ID: <5.1.1.6.0.20070409135518.050c5db0@sparrow.telecommunity.com>
At 09:42 PM 4/9/2007 +1000, Richard Jones wrote:
>On Mon, 9 Apr 2007, Martin v. L?wis wrote:
> > Currently, an URL like
> >
> > http://cheeseshop.python.org/pypi/PyXML
> >
> > will match all packages that have PyXML in their name.
> >
> > Should that be changed to only listing packages which
> > have PyXML as their exact name? (it would still give
> > two entries, as there are two visible releases of
> > that package).
>
>I'd say it should be exact.
>
>Currently the EasyInstall doc says "Individual project version pages' URLs
>must be of the form base/projectname/version, where base is the package
>index's base URL." But it's not clear whether it would use the current URL
>behaviour as a form of searching. Phillip?
Either behavior is acceptable to easy_install. When it encounters links
that point to any "base/projectname/version", it simply squirrels the
information away in its memory cache, and will spider the listed pages if
it needs URLs for "projectname". So it's perfectly safe to have any number
of project pages linked from a base/projectname/ page, for any number of
projects. easy_install only cares that base/projectname/ *include* links
to available pages for that project name.
From pje at telecommunity.com Mon Apr 9 20:03:02 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 09 Apr 2007 14:03:02 -0400
Subject: [Catalog-sig] Full package list
In-Reply-To: <461A762D.8080100@v.loewis.de>
References: <200704091019.02042.jeremy.kloth@4suite.org>
<461A3365.1060209@v.loewis.de>
<200704091019.02042.jeremy.kloth@4suite.org>
Message-ID: <5.1.1.6.0.20070409140118.050e7d68@sparrow.telecommunity.com>
At 07:21 PM 4/9/2007 +0200, Martin v. L?wis wrote:
>Jeremy Kloth schrieb:
> > On Monday 09 April 2007 6:36:53 am Martin v. L?wis wrote:
> >> With the browse pages hidden from spiders, the search engines
> >> cannot find out the complete list of packages anymore (AFAICT).
> >>
> >> Would it be useful to have a page with just the names of all
> >> packages, linking to pypi/<package>? It could go into the
> >> navigation bar, below "List trove classifiers".
> >
> > Do you mean a page like: http://cheeseshop.python.org/pypi?:action=index
>
>Oops, yes.
It is also available at http://cheeseshop.python.org/pypi/ - which is where
EasyInstall looks for it.
(EasyInstall never uses query strings to access the package index, so that
users can create and use alternative package indexes without needing any
dynamic technologies; everything easy_install needs can be done with Apache
directory indexes and perhaps some index.html files.)
From pje at telecommunity.com Mon Apr 9 20:24:02 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 09 Apr 2007 14:24:02 -0400
Subject: [Catalog-sig] [Distutils] Time for a static cheeseshop mirror
for easy_install?
In-Reply-To: <20070409144630.GA10277@localhost.localdomain>
References: <5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com>
<5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20070409141838.02dc73c8@sparrow.telecommunity.com>
At 10:46 AM 4/9/2007 -0400, A.M. Kuchling wrote:
>On Sat, Apr 07, 2007 at 12:44:56PM -0400, Phillip J. Eby wrote:
> > I don't know whether this will actually solve any problems the cheeseshop
> > itself is having; it may be that ill-behaved web spiders are at fault, or
> > something else altogether.
>
>In this recent case, two different spiders were crawling the wiki very
>quickly, the machine's load average was in the 70s, and the
>out-of-memory killer was killing off PostgreSQL processes.
>
>I don't think the load caused from people running easy_install is
>especially high -- it's certainly not a source of problems -- but
>making static pages would still be good to make mirroring the package
>archive more useful. Right now people could mirror
>http://cheeseshop.python.org/packages/, but there's nothing there for
>easy_install or for human readers; it's just a tree of package
>directories.
Hm. Well, actually, if that directory structure were something I could
code to, easy_install could sure as heck be *made* to use it. The only
thing easy_install couldn't get from it was external links to downloads,
SVN versions, etc.
Notice, for example, that if you use "easy_install -f
http://cheeseshop.python.org/packages/source/s/simple_json/ simple_json",
easy_install won't look at the main package index, but just download
directly. So an automated form of that calculation could easily be added
to easy_install.
What I had in mind for an easy_install mirror, however, was a script that
would just create a /packagename/index.html file with links gathered from
all versions of a package on the original Cheeseshop, and with packagename
generated as a setuptools "safe name" in lower case. This pattern would
allow easy_install to find every possible relevant link in just one
(static) web hit.
From pje at telecommunity.com Mon Apr 9 20:30:17 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 09 Apr 2007 14:30:17 -0400
Subject: [Catalog-sig] Time for a static cheeseshop mirror
for easy_install?
In-Reply-To: <56EE93DB-F8DB-476A-AD8A-ADE48E02C858@zope.com>
References: <461A5C84.8010101@v.loewis.de>
<5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com>
<20070409144630.GA10277@localhost.localdomain>
<E3E11B59-EDA5-4619-B8F8-42C90B3EDB57@zope.com>
<461A5C84.8010101@v.loewis.de>
Message-ID: <5.1.1.6.0.20070409142441.0503fa78@sparrow.telecommunity.com>
At 11:35 AM 4/9/2007 -0400, Jim Fulton wrote:
>On Apr 9, 2007, at 11:32 AM, Martin v. L?wis wrote:
>
> > Jim Fulton schrieb:
> >> On Apr 9, 2007, at 10:46 AM, A.M. Kuchling wrote:
> >> ...
> >>> Right now people could mirror
> >>> http://cheeseshop.python.org/packages/, but there's nothing there
> >>> for
> >>> easy_install
> >>
> >> Is there any reason why easy_install shouldn't look there?
> >
> > It's only files, no descriptions.
> >
> > Also, some authors don't have their files on /packages, but at their
> > own servers - i.e. they use the Cheeseshop just as a Python
> > package index, not as a comprehensive package archive network.
>
>Sorry, I wasn't clear. I wasn't suggesting that easy_install should
>look here instead of where it already looks, but this seems like a
>good and cheap place to look especially when a specific version
>number is given.
Actually, version number doesn't help here; it's Python version, and source
vs. binary that are the relevant distinctions. The download directories
include files for all versions of a given project, so we would want to hit
these three locations:
http://cheeseshop.python.org/packages/*pyver*/p/projectname/
http://cheeseshop.python.org/packages/any/p/projectname/
http://cheeseshop.python.org/packages/source/p/projectname/
And we would then have all the downloadable-from-cheeseshop links. (I
thought we could skip the "any", but some win32 exe's are classed as "any"
Python version, and easy_install supports win32 exe's.)
This is more web hits than is currently required to obtain similar
information, but on the plus side they are efficient hits for the
server. They also allow access to *all* versions of a package that are
downloadable, whether they are "hidden" or not.
On the minus side, there is no way to find externally-hosted files or SVN
links, which means we would still have to always hit the dynamic page to
know if we had found everything relevant.
From jeremy.kloth at 4suite.org Tue Apr 10 20:43:26 2007
From: jeremy.kloth at 4suite.org (Jeremy Kloth)
Date: Tue, 10 Apr 2007 12:43:26 -0600
Subject: [Catalog-sig] Full package list
In-Reply-To: <5.1.1.6.0.20070409140118.050e7d68@sparrow.telecommunity.com>
References: <200704091019.02042.jeremy.kloth@4suite.org>
<5.1.1.6.0.20070409140118.050e7d68@sparrow.telecommunity.com>
Message-ID: <200704101243.26932.jeremy.kloth@4suite.org>
On Monday 09 April 2007 12:03:02 pm Phillip J. Eby wrote:
> It is also available at http://cheeseshop.python.org/pypi/ - which is where
> EasyInstall looks for it.
When I access that page it just lists the last 20 updates. For example, PyXML
is nowhere to be seen on that page.
--
Jeremy Kloth
http://4suite.org/
From jeremy.kloth at 4suite.org Tue Apr 10 20:59:47 2007
From: jeremy.kloth at 4suite.org (Jeremy Kloth)
Date: Tue, 10 Apr 2007 12:59:47 -0600
Subject: [Catalog-sig] Full package list
In-Reply-To: <200704101243.26932.jeremy.kloth@4suite.org>
References: <200704091019.02042.jeremy.kloth@4suite.org>
<5.1.1.6.0.20070409140118.050e7d68@sparrow.telecommunity.com>
<200704101243.26932.jeremy.kloth@4suite.org>
Message-ID: <200704101259.47581.jeremy.kloth@4suite.org>
On Tuesday 10 April 2007 12:43:26 pm Jeremy Kloth wrote:
> On Monday 09 April 2007 12:03:02 pm Phillip J. Eby wrote:
> > It is also available at http://cheeseshop.python.org/pypi/ - which is
> > where EasyInstall looks for it.
>
> When I access that page it just lists the last 20 updates. For example,
> PyXML is nowhere to be seen on that page.
Ah, my apologies. The URL I used didn't have the trailing '/'. That, IMO, is
too subtle a difference. The index page shouldn't be that easily confused
with another URL.
--
Jeremy Kloth
http://4suite.org/
From martin at v.loewis.de Tue Apr 10 22:59:50 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 10 Apr 2007 22:59:50 +0200
Subject: [Catalog-sig] Full package list
In-Reply-To: <200704101259.47581.jeremy.kloth@4suite.org>
References: <200704091019.02042.jeremy.kloth@4suite.org> <5.1.1.6.0.20070409140118.050e7d68@sparrow.telecommunity.com> <200704101243.26932.jeremy.kloth@4suite.org>
<200704101259.47581.jeremy.kloth@4suite.org>
Message-ID: <461BFAC6.9080509@v.loewis.de>
Jeremy Kloth schrieb:
> On Tuesday 10 April 2007 12:43:26 pm Jeremy Kloth wrote:
>> On Monday 09 April 2007 12:03:02 pm Phillip J. Eby wrote:
>>> It is also available at http://cheeseshop.python.org/pypi/ - which is
>>> where EasyInstall looks for it.
>> When I access that page it just lists the last 20 updates. For example,
>> PyXML is nowhere to be seen on that page.
>
> Ah, my apologies. The URL I used didn't have the trailing '/'. That, IMO, is
> too subtle a difference. The index page shouldn't be that easily confused
> with another URL.
I think the history is this:
- originally, the index page listed all packages, and there were only
query parameters
- I then added support for a URL structure at some PyCon sprint,
implementing /, /package, and /package/version
- at some point, the standard index was replace with the current home
page, probably because the full index is expensive to generate.
So I don't think that /pypi should be restored to answer the index -
the current approach (home page) seems fine to me. I also don't think
that /pypi/ should be dropped, if setuptools is using it. So while
I see the inconsistency and subtlety, I don't think anything can,
or should, be done about it.
In any case, I added a link in the navbar pointing to that list (for
ease of implementation, using the query parameter). So the /pypi/
form remains unlinked - I don't see a problem with doing so. There
are many other unlinked URLs in PyPI, too.
Regards,
Martin
From taleinat at gmail.com Thu Apr 12 14:26:58 2007
From: taleinat at gmail.com (Tal Einat)
Date: Thu, 12 Apr 2007 15:26:58 +0300
Subject: [Catalog-sig] IDLE extensions category
Message-ID: <7afdee2f0704120526p408208bbq771500b15fb76d12@mail.gmail.com>
Hello,
IDLE supports extensions, which can add all sorts of functionality to IDLE.
Several such extensions are included with the IDLE that is packaged with the
Python distribution. Several other such extensions have been written but are
hard to find and obtain. The Cheese Shop is the ideal place for IDLE
extensions which aren't (yet) shipped with the main version of IDLE/
A category is needed since IDLE extensions are pieces of code with little
meaning outside the context of IDLE, and of course to make them easier to
find and browse.
Thanks,
- Tal Einat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/catalog-sig/attachments/20070412/b2ff3236/attachment.html
From gentoodev at gmail.com Sat Apr 14 05:33:08 2007
From: gentoodev at gmail.com (Rob)
Date: Fri, 13 Apr 2007 20:33:08 -0700
Subject: [Catalog-sig] How to get a list of package releases
Message-ID: <a064d2420704132033p55cd7e12nc54b89ddb508e30f@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.
> >
> >
As a Python package maintainer for a Linux distro I would find this info
very useful (I found this thread today when I was about to ask for
this feature).
For instance, yesterday we had a bug report about a package with an
incorrect license (pexpect changed from PSF to MIT). We have several
versions available and it would have been handy to be able to check the
license for each version to make sure they were all correct instead of
downloading each tarball and reading the metadata manually.
I wrote yolk, which queries PyPI via the XML-RPC interface, to help with this
type of thing and it would be nice to have an option via XML-RPC to
query all the hidden packages also.
Another problem I've come across is that sometimes you'll find a link to
a PyPI web page for a package that has been hidden, through google
or another project that has it listed as a dependency etc. It would be nice
if you were looking at a web page for a hidden package that it said in
big bold writing that this package is hidden and have a link to the
newer version(s).
Rob
From jim at zope.com Mon Apr 23 21:00:38 2007
From: jim at zope.com (Jim Fulton)
Date: Mon, 23 Apr 2007 15:00:38 -0400
Subject: [Catalog-sig] I don't want implicit hiding of old releases
Message-ID: <36DD36B2-78E3-4D65-B43F-0363725233A8@zope.com>
When a new release for a project is created (e.g. with the register
command), old releases are hidden. I'm finding that this is almost
never what I want. It's a pain to go back after registering a new
release and unhide old releases. Is there any way to suppress this
behavior?
Jim
--
Jim Fulton mailto:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
From richardjones at optushome.com.au Fri Apr 27 01:43:22 2007
From: richardjones at optushome.com.au (Richard Jones)
Date: Fri, 27 Apr 2007 09:43:22 +1000
Subject: [Catalog-sig] IDLE extensions category
In-Reply-To: <7afdee2f0704120526p408208bbq771500b15fb76d12@mail.gmail.com>
References: <7afdee2f0704120526p408208bbq771500b15fb76d12@mail.gmail.com>
Message-ID: <200704270943.22696.richardjones@optushome.com.au>
On Thu, 12 Apr 2007, Tal Einat wrote:
> IDLE supports extensions, which can add all sorts of functionality to IDLE.
> Several such extensions are included with the IDLE that is packaged with
> the Python distribution. Several other such extensions have been written
> but are hard to find and obtain. The Cheese Shop is the ideal place for
> IDLE extensions which aren't (yet) shipped with the main version of IDLE/
>
> A category is needed since IDLE extensions are pieces of code with little
> meaning outside the context of IDLE, and of course to make them easier to
> find and browse.
I have added "Framework :: IDLE"
Richard
From richardjones at optushome.com.au Fri Apr 27 01:44:03 2007
From: richardjones at optushome.com.au (Richard Jones)
Date: Fri, 27 Apr 2007 09:44:03 +1000
Subject: [Catalog-sig] I don't want implicit hiding of old releases
In-Reply-To: <36DD36B2-78E3-4D65-B43F-0363725233A8@zope.com>
References: <36DD36B2-78E3-4D65-B43F-0363725233A8@zope.com>
Message-ID: <200704270944.03791.richardjones@optushome.com.au>
On Tue, 24 Apr 2007, Jim Fulton wrote:
> When a new release for a project is created (e.g. with the register
> command), old releases are hidden. I'm finding that this is almost
> never what I want. It's a pain to go back after registering a new
> release and unhide old releases. Is there any way to suppress this
> behavior?
Not currently. What would you suggest?
Richard
From fdrake at gmail.com Fri Apr 27 02:34:57 2007
From: fdrake at gmail.com (Fred Drake)
Date: Thu, 26 Apr 2007 20:34:57 -0400
Subject: [Catalog-sig] I don't want implicit hiding of old releases
In-Reply-To: <200704270944.03791.richardjones@optushome.com.au>
References: <36DD36B2-78E3-4D65-B43F-0363725233A8@zope.com>
<200704270944.03791.richardjones@optushome.com.au>
Message-ID: <9cee7ab80704261734j3aa808a0odafeb3640e98db22@mail.gmail.com>
On 4/26/07, Richard Jones <richardjones at optushome.com.au> wrote:
> Not currently. What would you suggest?
Ideally, an option per package, since this has more to do with the
release policy for the package than any other (single) thing. Failing
that, an option in the distutils "register" command.
-Fred
--
Fred L. Drake, Jr. <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller
From richardjones at optushome.com.au Fri Apr 27 02:41:57 2007
From: richardjones at optushome.com.au (Richard Jones)
Date: Fri, 27 Apr 2007 10:41:57 +1000
Subject: [Catalog-sig] I don't want implicit hiding of old releases
In-Reply-To: <9cee7ab80704261734j3aa808a0odafeb3640e98db22@mail.gmail.com>
References: <36DD36B2-78E3-4D65-B43F-0363725233A8@zope.com>
<200704270944.03791.richardjones@optushome.com.au>
<9cee7ab80704261734j3aa808a0odafeb3640e98db22@mail.gmail.com>
Message-ID: <200704271041.57246.richardjones@optushome.com.au>
On Fri, 27 Apr 2007, Fred Drake wrote:
> On 4/26/07, Richard Jones <richardjones at optushome.com.au> wrote:
> > Not currently. What would you suggest?
>
> Ideally, an option per package, since this has more to do with the
> release policy for the package than any other (single) thing.
Yep. Anyone else have other thoughts?
> Failing
> that, an option in the distutils "register" command.
Unfortunately adding an option to the register command is not possible without
patching Python itself.
Richard
From fdrake at gmail.com Fri Apr 27 02:44:20 2007
From: fdrake at gmail.com (Fred Drake)
Date: Thu, 26 Apr 2007 20:44:20 -0400
Subject: [Catalog-sig] I don't want implicit hiding of old releases
In-Reply-To: <200704271041.57246.richardjones@optushome.com.au>
References: <36DD36B2-78E3-4D65-B43F-0363725233A8@zope.com>
<200704270944.03791.richardjones@optushome.com.au>
<9cee7ab80704261734j3aa808a0odafeb3640e98db22@mail.gmail.com>
<200704271041.57246.richardjones@optushome.com.au>
Message-ID: <9cee7ab80704261744l16da709bg5e3893e9b9a45612@mail.gmail.com>
On 4/26/07, Richard Jones <richardjones at optushome.com.au> wrote:
> Unfortunately adding an option to the register command is not possible without
> patching Python itself.
Of course. Another count against giant conglomerated distributions. ;-)
-Fred
--
Fred L. Drake, Jr. <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller
From pje at telecommunity.com Fri Apr 27 03:13:40 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 26 Apr 2007 21:13:40 -0400
Subject: [Catalog-sig] I don't want implicit hiding of old releases
In-Reply-To: <200704271041.57246.richardjones@optushome.com.au>
References: <9cee7ab80704261734j3aa808a0odafeb3640e98db22@mail.gmail.com>
<36DD36B2-78E3-4D65-B43F-0363725233A8@zope.com>
<200704270944.03791.richardjones@optushome.com.au>
<9cee7ab80704261734j3aa808a0odafeb3640e98db22@mail.gmail.com>
Message-ID: <5.1.1.6.0.20070426211014.00a04748@sparrow.telecommunity.com>
At 10:41 AM 4/27/2007 +1000, Richard Jones wrote:
>On Fri, 27 Apr 2007, Fred Drake wrote:
> > On 4/26/07, Richard Jones <richardjones at optushome.com.au> wrote:
> > > Not currently. What would you suggest?
> >
> > Ideally, an option per package, since this has more to do with the
> > release policy for the package than any other (single) thing.
>
>Yep. Anyone else have other thoughts?
>
>
> > Failing
> > that, an option in the distutils "register" command.
>
>Unfortunately adding an option to the register command is not possible
>without
>patching Python itself.
Not so, actually. Simply make a separate release of a replacement
"register" command, marked as a 'distutils.command' entry point in
setup.py. See:
http://peak.telecommunity.com/DevCenter/setuptools#creating-distutils-extensions
for details.
Or, if you prefer not to do it using setuptools, you can add a cmdclass
dictionary to your setup() calls, but distutils extensions can still be
distributed separately.
From fdrake at gmail.com Fri Apr 27 03:45:25 2007
From: fdrake at gmail.com (Fred Drake)
Date: Thu, 26 Apr 2007 21:45:25 -0400
Subject: [Catalog-sig] I don't want implicit hiding of old releases
In-Reply-To: <5.1.1.6.0.20070426211014.00a04748@sparrow.telecommunity.com>
References: <36DD36B2-78E3-4D65-B43F-0363725233A8@zope.com>
<200704270944.03791.richardjones@optushome.com.au>
<9cee7ab80704261734j3aa808a0odafeb3640e98db22@mail.gmail.com>
<200704271041.57246.richardjones@optushome.com.au>
<5.1.1.6.0.20070426211014.00a04748@sparrow.telecommunity.com>
Message-ID: <9cee7ab80704261845w4b1719b8j7594b135c483a7bc@mail.gmail.com>
On 4/26/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> Or, if you prefer not to do it using setuptools, you can add a cmdclass
> dictionary to your setup() calls, but distutils extensions can still be
> distributed separately.
Ok, so there are ways to force the client side to make use of an
option that still needs support on the server (I suspect), or the
somewhat simpler and more useful approach can be used: make it a
per-project setting.
-Fred
--
Fred L. Drake, Jr. <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller
From pje at telecommunity.com Fri Apr 27 06:53:39 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 27 Apr 2007 00:53:39 -0400
Subject: [Catalog-sig] I don't want implicit hiding of old releases
In-Reply-To: <9cee7ab80704261845w4b1719b8j7594b135c483a7bc@mail.gmail.co
m>
References: <5.1.1.6.0.20070426211014.00a04748@sparrow.telecommunity.com>
<36DD36B2-78E3-4D65-B43F-0363725233A8@zope.com>
<200704270944.03791.richardjones@optushome.com.au>
<9cee7ab80704261734j3aa808a0odafeb3640e98db22@mail.gmail.com>
<200704271041.57246.richardjones@optushome.com.au>
<5.1.1.6.0.20070426211014.00a04748@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20070427005246.02e63008@sparrow.telecommunity.com>
At 09:45 PM 4/26/2007 -0400, Fred Drake wrote:
>On 4/26/07, Phillip J. Eby <pje at telecommunity.com> wrote:
>>Or, if you prefer not to do it using setuptools, you can add a cmdclass
>>dictionary to your setup() calls, but distutils extensions can still be
>>distributed separately.
>
>Ok, so there are ways to force the client side to make use of an
>option that still needs support on the server (I suspect), or the
>somewhat simpler and more useful approach can be used: make it a
>per-project setting.
I didn't say it was a good idea; I was just correcting the misperception
that it was *impossible*.
From jim at zope.com Fri Apr 27 12:02:47 2007
From: jim at zope.com (Jim Fulton)
Date: Fri, 27 Apr 2007 06:02:47 -0400
Subject: [Catalog-sig] I don't want implicit hiding of old releases
In-Reply-To: <200704271041.57246.richardjones@optushome.com.au>
References: <36DD36B2-78E3-4D65-B43F-0363725233A8@zope.com>
<200704270944.03791.richardjones@optushome.com.au>
<9cee7ab80704261734j3aa808a0odafeb3640e98db22@mail.gmail.com>
<200704271041.57246.richardjones@optushome.com.au>
Message-ID: <DD4F4C6A-1F2F-4A06-B10A-6F0BCEA06223@zope.com>
On Apr 26, 2007, at 8:41 PM, Richard Jones wrote:
> On Fri, 27 Apr 2007, Fred Drake wrote:
>> On 4/26/07, Richard Jones <richardjones at optushome.com.au> wrote:
>>> Not currently. What would you suggest?
>>
>> Ideally, an option per package, since this has more to do with the
>> release policy for the package than any other (single) thing.
>
> Yep. Anyone else have other thoughts?
A per-package setting would be really great. :)
Jim
--
Jim Fulton mailto:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
From kantrn at rpi.edu Fri Apr 27 13:31:39 2007
From: kantrn at rpi.edu (Noah Kantrowitz)
Date: Fri, 27 Apr 2007 07:31:39 -0400
Subject: [Catalog-sig] I don't want implicit hiding of old releases
In-Reply-To: <200704270944.03791.richardjones@optushome.com.au>
References: <36DD36B2-78E3-4D65-B43F-0363725233A8@zope.com>
<200704270944.03791.richardjones@optushome.com.au>
Message-ID: <4631DF1B.4010900@rpi.edu>
Richard Jones wrote:
> On Tue, 24 Apr 2007, Jim Fulton wrote:
>
>> When a new release for a project is created (e.g. with the register
>> command), old releases are hidden. I'm finding that this is almost
>> never what I want. It's a pain to go back after registering a new
>> release and unhide old releases. Is there any way to suppress this
>> behavior?
>>
>
> Not currently. What would you suggest?
>
>
>
Some kind of slotting (to steal a term from Gentoo) mechanism might be a
nice solution. The slot name (otherwise just an opaque string) would be
looked at for each upload, and all other releases in the same slot would
be hidden. This could be piggybacked in the keywords field to avoid the
need for client-side changes (keywords = 'slot:1'). This seems more
flexible than a simple package-level switch. If you never want any
versions hidden, just use your version number as the slot name, but you
can also do more traditional stuff with multiple release branches.
--Noah
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20070427/f5f58bd0/attachment.pgp