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: 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: References: Message-ID: <9cee7ab80704061420y6dc21630tdd20b8c10015138c@mail.gmail.com> On 4/6/07, Kumar McMillan 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. "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: 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/? 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: 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: References: <5.1.1.6.0.20070407122140.02c67950@sparrow.telecommunity.com> <20070409144630.GA10277@localhost.localdomain> 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> <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/? 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/? 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/? 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> <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: > >On 1/28/07, Phillip J. Eby 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 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. "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 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 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. "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 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 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. "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 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: 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 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