From wander.lairson at gmail.com Tue Jan 4 17:30:45 2011 From: wander.lairson at gmail.com (wander.lairson) Date: Tue, 4 Jan 2011 14:30:45 -0200 Subject: [Catalog-sig] Updating a package Message-ID: Dear all, I am the PyUSB author and recently I was asked to update pyusb package in the PyPi. The point is that I am not the maintainer and don't know who is. Now I need to contact the current package maintainer but I could not find how to do so through PyPi (as maintainer's email does not show). Does anyone know how am I supposed to proceed (open a support request, maybe) ? Thanks in advance. -- Best Regards, Wander Lairson Costa LCoN - Laborat?rio de Computa??o Natural - Natural Computing Laboratory (http://www.mackenzie.com.br/lcon.html) Programa de P?s-Gradua??o em Engenharia El?trica (PPGEE) Faculdade de Computa??o e Inform?tica (FCI) Universidade Presbiteriana Mackenzie - SP - Brazil From lists at zopyx.com Tue Jan 4 17:43:54 2011 From: lists at zopyx.com (Andreas Jung) Date: Tue, 04 Jan 2011 17:43:54 +0100 Subject: [Catalog-sig] Updating a package In-Reply-To: References: Message-ID: <4D234E4A.8070703@zopyx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Huh? http://pypi.python.org/pypi/pyusb/0.4.2 lists an email and http://sourceforge.net/users/wander_lairson has a "See me a message" link. In addition: this project has a mailing list. - -aj wander.lairson wrote: > Dear all, > > I am the PyUSB author and recently I was asked to update pyusb package > in the PyPi. The point is that I am not the maintainer and don't know > who is. Now I need to contact the current package maintainer but I > could not find how to do so through PyPi (as maintainer's email does > not show). Does anyone know how am I supposed to proceed (open a > support request, maybe) ? > > Thanks in advance. > - -- ZOPYX Limited | zopyx group Charlottenstr. 37/1 | The full-service network for Zope & Plone D-72070 T?bingen | Produce & Publish www.zopyx.com | www.produce-and-publish.com - ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGUBAEBAgAGBQJNI05KAAoJEADcfz7u4AZjAoULv0OA6fxuVs+F6DYVXSek2Kq5 kWHR5fw6Sxlta3ACM9WhFpoj1vv/dik/VJ8gtbwcCt8xX5sOU7265DGar6DS0sji zKhdMfK/35g1VpCatylO+NIhllJBhI+ZFmGHgjK/ShbRzDq3tMXnKHXxRSvKRrFn NRPOulyCFi+oxPATGMX1K/vT04ZKhZDOFXud9dHSxPFWriWsJxX+5hsMLSsgsImd IykrsQp0UeFpOjVvAEdJ2ay+dJCviSktx07Easd7B1GOU4fJSrPzbkfu+Q3JUKWe FcGGHWxYjQsHnfmKf4BDaantvypxl6dG+JO/c4ldDUpFIp6vSrC1C6uHpWEiKjKr kb9GnGRwt6Q/q4KR5MmyVDf10byyniv9PTwx+4ln0LVLv4sMR+7+zDnbsK7tNC0H vshnRRNsVaFE8WeJ27oD/c3AmXN1Nb0ezxsEmHInc1tVf3pt28f3IIanI2Q6F+5/ St22cLqGSY19Yjd0SpDGVkWa+Ks2Few= =/HM5 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available URL: From wander.lairson at gmail.com Tue Jan 4 18:30:29 2011 From: wander.lairson at gmail.com (wander.lairson) Date: Tue, 4 Jan 2011 15:30:29 -0200 Subject: [Catalog-sig] Updating a package In-Reply-To: <4D234E4A.8070703@zopyx.com> References: <4D234E4A.8070703@zopyx.com> Message-ID: 2011/1/4 Andreas Jung : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Huh? > > http://pypi.python.org/pypi/pyusb/0.4.2 > > lists an email > > and > > http://sourceforge.net/users/wander_lairson > > has a "See me a message" link. > > In addition: this project has a mailing list. > > - -aj > I think my last email was a bit confused (or I could not undertand yours). When I try to submit pyusb 1.0 to PyPi, I got an error, because the maintainer in the PyPi is not me, it feels like the maintainer is an user called reid, I didn't find an email to contact him, this is the source of trouble. If I am doing some mistake, please let me know, I am a newbie in PyPi... Wander From mal at egenix.com Tue Jan 4 18:57:35 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 04 Jan 2011 18:57:35 +0100 Subject: [Catalog-sig] Updating a package In-Reply-To: References: <4D234E4A.8070703@zopyx.com> Message-ID: <4D235F8F.50507@egenix.com> wander.lairson wrote: > 2011/1/4 Andreas Jung : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Huh? >> >> http://pypi.python.org/pypi/pyusb/0.4.2 >> >> lists an email >> >> and >> >> http://sourceforge.net/users/wander_lairson >> >> has a "See me a message" link. >> >> In addition: this project has a mailing list. >> >> - -aj >> > I think my last email was a bit confused (or I could not undertand > yours). When I try to submit pyusb 1.0 to PyPi, I got an error, > because the maintainer in the PyPi is not me, it feels like the > maintainer is an user called reid, I didn't find an email to contact > him, this is the source of trouble. If I am doing some mistake, please > let me know, I am a newbie in PyPi... You will have to file a support request to get the PyPI owner of the package changed. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 04 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From carl at oddbird.net Tue Jan 4 18:23:05 2011 From: carl at oddbird.net (Carl Meyer) Date: Tue, 04 Jan 2011 12:23:05 -0500 Subject: [Catalog-sig] Updating a package In-Reply-To: <4D234E4A.8070703@zopyx.com> References: <4D234E4A.8070703@zopyx.com> Message-ID: <4D235779.509@oddbird.net> On 01/04/2011 11:43 AM, Andreas Jung wrote: > Huh? > > http://pypi.python.org/pypi/pyusb/0.4.2 > > lists an email > > and > > http://sourceforge.net/users/wander_lairson > > has a "See me a message" link. > > In addition: this project has a mailing list. The email listed on the PyPI page (and the sourceforge user you link to) are the author of the package, Wander Lairson, who is the very person you are responding to -- it's not likely that he's having a problem contacting himself ;-). The PyPI index owner appears to be the PyPI user "reid", for whom no email is listed. The package author is enquiring how to get in touch with "reid" in order to take over ownership (or request an update of) the PyPI index listing. Carl From monitor at jacobian.org Tue Jan 4 19:46:05 2011 From: monitor at jacobian.org (monitor at jacobian.org) Date: Tue, 04 Jan 2011 12:46:05 -0600 Subject: [Catalog-sig] [monit] d.pypi.python.org - Connection failed Message-ID: <1294166770.1@jacobian.org> Connection failed Service d.pypi.python.org Date: Tue, 04 Jan 2011 12:46:05 -0600 Action: alert Host: jacobian.org Description: failed, cannot open a connection to INET[d.pypi.python.org:80] via TCP Your faithful employee, monit From monitor at jacobian.org Tue Jan 4 19:52:16 2011 From: monitor at jacobian.org (monitor at jacobian.org) Date: Tue, 04 Jan 2011 12:52:16 -0600 Subject: [Catalog-sig] [monit] d.pypi.python.org - Connection succeeded Message-ID: <1294167138.1@jacobian.org> Connection succeeded Service d.pypi.python.org Date: Tue, 04 Jan 2011 12:52:16 -0600 Action: alert Host: jacobian.org Description: connection succeeded to INET[d.pypi.python.org:80] via TCP Your faithful employee, monit From tjreedy at udel.edu Tue Jan 4 22:20:23 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 04 Jan 2011 16:20:23 -0500 Subject: [Catalog-sig] Updating a package In-Reply-To: <4D235779.509@oddbird.net> References: <4D234E4A.8070703@zopyx.com> <4D235779.509@oddbird.net> Message-ID: On 1/4/2011 12:23 PM, Carl Meyer wrote: > The PyPI index owner appears to be the PyPI user "reid", for whom no > email is listed. The package author is enquiring how to get in touch > with "reid" in order to take over ownership (or request an update of) > the PyPI index listing. It seems to me that if there is a disjunction between listing owner and package author/maintainer, then the owner should also be listed with email so one can send such requests. -- Terry Jan Reedy From martin at v.loewis.de Tue Jan 4 22:57:09 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 04 Jan 2011 22:57:09 +0100 Subject: [Catalog-sig] Updating a package In-Reply-To: <4D235F8F.50507@egenix.com> References: <4D234E4A.8070703@zopyx.com> <4D235F8F.50507@egenix.com> Message-ID: <4D2397B5.4040400@v.loewis.de> > You will have to file a support request to get the PyPI owner of > the package changed. Indeed, that's still the proper procedure. I'm -1 on publishing email addresses of people who didn't agree to have their email address published originally - if they want to become visible, they are free to post contact information to the release information already. Regards, Martin From ben+python at benfinney.id.au Tue Jan 4 23:21:55 2011 From: ben+python at benfinney.id.au (Ben Finney) Date: Wed, 05 Jan 2011 09:21:55 +1100 Subject: [Catalog-sig] Updating a package References: <4D234E4A.8070703@zopyx.com> <4D235779.509@oddbird.net> Message-ID: <87k4ikfgxo.fsf@benfinney.id.au> Terry Reedy writes: > It seems to me that if there is a disjunction between listing owner > and package author/maintainer, then the owner should also be listed > with email so one can send such requests. +1. What arguments are there for having packages maintained by people whose contact details are hard to find? I can't think of any that outweigh the problems caused by maintainers with contact details that are hard-to-find or absent. -- \ ?I was the kid next door's imaginary friend.? ?Emo Philips | `\ | _o__) | Ben Finney From ben+python at benfinney.id.au Tue Jan 4 23:28:05 2011 From: ben+python at benfinney.id.au (Ben Finney) Date: Wed, 05 Jan 2011 09:28:05 +1100 Subject: [Catalog-sig] Updating a package References: <4D234E4A.8070703@zopyx.com> <4D235779.509@oddbird.net> <87k4ikfgxo.fsf@benfinney.id.au> Message-ID: <87fwt8fgne.fsf@benfinney.id.au> Ben Finney writes: > What arguments are there for having packages maintained by people > whose contact details are hard to find? I can't think of any that > outweigh the problems caused by maintainers with contact details that > are hard-to-find or absent. Poorly written. I meant not that problems are caused *by* such maintainers; rather, the obvious problems of being unable to reliably get contact details for a maintainer when necessary. -- \ ?Few things are harder to put up with than the annoyance of a | `\ good example.? ?Mark Twain, _Pudd'n'head Wilson_ | _o__) | Ben Finney From martin at v.loewis.de Tue Jan 4 23:42:39 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Tue, 04 Jan 2011 23:42:39 +0100 Subject: [Catalog-sig] Updating a package In-Reply-To: <87fwt8fgne.fsf@benfinney.id.au> References: <4D234E4A.8070703@zopyx.com> <4D235779.509@oddbird.net> <87k4ikfgxo.fsf@benfinney.id.au> <87fwt8fgne.fsf@benfinney.id.au> Message-ID: <4D23A25F.5080105@v.loewis.de> Am 04.01.2011 23:28, schrieb Ben Finney: > Ben Finney writes: > >> What arguments are there for having packages maintained by people >> whose contact details are hard to find? I can't think of any that >> outweigh the problems caused by maintainers with contact details that >> are hard-to-find or absent. > > Poorly written. I meant not that problems are caused *by* such > maintainers; rather, the obvious problems of being unable to reliably > get contact details for a maintainer when necessary. Publishing the email addresses typically won't make it more easy to contact them, in the cases at question. Please trust me that this is an experience of many years dealing with this specific issue. Regards, Martin From monitor at jacobian.org Wed Jan 5 22:14:23 2011 From: monitor at jacobian.org (monitor at jacobian.org) Date: Wed, 05 Jan 2011 15:14:23 -0600 Subject: [Catalog-sig] [monit] b.pypi.python.org - Connection failed Message-ID: <1294262067.1@jacobian.org> Connection failed Service b.pypi.python.org Date: Wed, 05 Jan 2011 15:14:23 -0600 Action: alert Host: jacobian.org Description: failed protocol test [HTTP] at INET[b.pypi.python.org:80] via TCP Your faithful employee, monit From monitor at jacobian.org Wed Jan 5 22:32:05 2011 From: monitor at jacobian.org (monitor at jacobian.org) Date: Wed, 05 Jan 2011 15:32:05 -0600 Subject: [Catalog-sig] [monit] b.pypi.python.org - Connection succeeded Message-ID: <1294263128.1@jacobian.org> Connection succeeded Service b.pypi.python.org Date: Wed, 05 Jan 2011 15:32:05 -0600 Action: alert Host: jacobian.org Description: connection succeeded to INET[b.pypi.python.org:80] via TCP Your faithful employee, monit From baiju.m.mail at gmail.com Tue Jan 18 07:33:51 2011 From: baiju.m.mail at gmail.com (Baiju M) Date: Tue, 18 Jan 2011 12:03:51 +0530 Subject: [Catalog-sig] Trove categories for Buildout recipes and extensions Message-ID: Hi, Currently there are 270+ distributions in "Framework :: Buildout" trove category. http://pypi.python.org/pypi?:action=browse&c=512 It would be nice if we can add two sub categories: Framework :: Buildout :: Recipe Framework :: Buildout :: Extension (Recipes and extensions are two type of plugin mechanisms used in Buildout) Regards, Baiju M From bkjones at gmail.com Tue Jan 25 15:06:56 2011 From: bkjones at gmail.com (Brian Jones) Date: Tue, 25 Jan 2011 09:06:56 -0500 Subject: [Catalog-sig] API search by python version (or classifier) Message-ID: Hi all, I'm wondering how hard it would be to provide a search by either Python version, or better, classifier? In truth, I'm wondering about all sorts of features that might bring PyPI into the current century, for example, a REST interface, more robust (and faster) searching capabilities (like searching by dependency), a more intuitive notion of 'ranking', tagging, an API for easy_install-like tools that don't require scraping, etc. Is any of this on the radar? Is there a published document along the lines of '2011 Goals'? Is the TODO list the only current notion of a roadmap for PyPI? I've written an application myself to provide PyPI-like features internally due to frustration in dealing with PyPI itself from a dev perspective. I gather that supporting external developers was probably not an initial design goal of PyPI. Is that still the case, or are there any concrete plans to enhance this side of the offering? I'd be willing to have a look and help out if there was some consensus around what direction things need to move. brian -- Brian K. Jones My Blog http://www.protocolostomy.com Follow me http://twitter.com/bkjones -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at python.org Tue Jan 25 23:27:47 2011 From: richard at python.org (Richard Jones) Date: Wed, 26 Jan 2011 09:27:47 +1100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: Message-ID: On Wed, Jan 26, 2011 at 1:06 AM, Brian Jones wrote: > I'm wondering how hard it would be to provide a search by either Python > version, or better, classifier? You clearly mean something other than the "browse" interface already present in the web interface. What sort of search would you mean? > In truth, I'm wondering about all sorts of features that might bring PyPI > into the current century, for example, a REST interface, more robust (and > faster) searching capabilities (like searching by dependency), a more > intuitive notion of 'ranking', tagging, an API for easy_install-like tools > that don't require scraping, etc. These all sound like great ideas. I would love for developers of tools like easy_install to help design more efficient, non-scraping interfaces for PyPI. I've stated this publicly for years now :-) Note that the recent mirroring efforts probably limit some of the really fancy things you can do in a distributed sense. > Is any of this on the radar? Is there a > published document along the lines of '2011 Goals'? Is the TODO list the > only current notion of a roadmap for PyPI? I have no current goals for the system. I'm not aware of any that Martin (the other developer) might have, not am I aware of anyone actively working on any patches. As has been stated a bazillion times, code contributions are almost always welcome :-) > I've written an application myself to provide PyPI-like features internally > due to frustration in dealing with PyPI itself from a dev perspective. Frustration which at least I was completely unaware of :-) > I gather that supporting external developers was probably not an initial > design goal of PyPI. I'm not sure what you mean by "supporting external developers". The initial design goals of PyPI were captured in PEP 301 http://www.python.org/dev/peps/pep-0301/ ... and it's grown organically since then. Richard From richard at python.org Tue Jan 25 23:38:59 2011 From: richard at python.org (Richard Jones) Date: Wed, 26 Jan 2011 09:38:59 +1100 Subject: [Catalog-sig] Trove categories for Buildout recipes and extensions In-Reply-To: References: Message-ID: On Tue, Jan 18, 2011 at 5:33 PM, Baiju M wrote: > It would be nice if we can add two sub categories: > > ?Framework :: Buildout :: Recipe > ?Framework :: Buildout :: Extension There being no objections I've added these classifiers. Richard From martin at v.loewis.de Wed Jan 26 00:09:29 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 26 Jan 2011 00:09:29 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: Message-ID: <4D3F5829.4060806@v.loewis.de> > searching capabilities (like searching by dependency), I tried adding this functionality to PyPI, but it was shot down quickly by many catalog-sig readers, see the thread starting at http://mail.python.org/pipermail/catalog-sig/2010-September/003301.html > a more intuitive notion of 'ranking' You would have to be more specific: I don't understand what that is (or how the current ranking is unintuitive) Please be prepared that any changes to this feature likely get shot down, also. > an API for easy_install-like tools that don't require scraping That's already available. > I've written an application myself to provide PyPI-like features > internally due to frustration in dealing with PyPI itself from a dev > perspective. I gather that supporting external developers was probably > not an initial design goal of PyPI. Is that still the case, or are there > any concrete plans to enhance this side of the offering? I'd be willing > to have a look and help out if there was some consensus around what > direction things need to move. PyPI already supports external developers. If the specific feature you would want is not there, you would have to specify what that feature is, and propose it to catalog-sig. If it doesn't get shot down, we can ponder implementing it, in which case contributions would be welcome. Regards, Martin From bkjones at gmail.com Wed Jan 26 03:36:34 2011 From: bkjones at gmail.com (Brian Jones) Date: Tue, 25 Jan 2011 21:36:34 -0500 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: Message-ID: Sorry, including the list. ---------- Forwarded message ---------- From: Brian Jones Date: Tue, Jan 25, 2011 at 9:19 PM Subject: Re: [Catalog-sig] API search by python version (or classifier) To: Richard Jones On Tue, Jan 25, 2011 at 5:27 PM, Richard Jones wrote: > On Wed, Jan 26, 2011 at 1:06 AM, Brian Jones wrote: > > I'm wondering how hard it would be to provide a search by either Python > > version, or better, classifier? > > You clearly mean something other than the "browse" interface already > present in the web interface. What sort of search would you mean? > Sorry, I left out the word "programmatic". Of course the search feature is in the browser. I'd like access to that data programmatically. Read-only is all I'm looking for, though I see no reason to limit a hypothetical API that way. > > > In truth, I'm wondering about all sorts of features that might bring PyPI > > into the current century, for example, a REST interface, more robust (and > > faster) searching capabilities (like searching by dependency), a more > > intuitive notion of 'ranking', tagging, an API for easy_install-like > tools > > that don't require scraping, etc. > > These all sound like great ideas. I would love for developers of tools > like easy_install to help design more efficient, non-scraping > interfaces for PyPI. I've stated this publicly for years now :-) > So what's the holdup? Why has nothing happened? I'm not attempting to come off as a curmudgeon, I'm really interested in the process and hurdles. I guess I just don't get how the dev cycle works for this project. I mean, if a maintainer of a project would like something to happen, I can think of few people in a better position to make it happen. It would seem to follow, then, that the chances of *my* getting anything done myself are probably slim if the maintainer himself has affected no change in my area of interest. > Note that the recent mirroring efforts probably limit some of the > really fancy things you can do in a distributed sense. > I'm not sure I understand this. I understand that there's a mirroring process, but I don't understand how that limits me. > > > Is any of this on the radar? Is there a > > published document along the lines of '2011 Goals'? Is the TODO list the > > only current notion of a roadmap for PyPI? > > I have no current goals for the system. I'm not aware of any that > Martin (the other developer) might have, not am I aware of anyone > actively working on any patches. > But... you just stated goals that align with mine above. And why is it that a maintainer of the project has no goals for said project, and isn't working on patches? And if nobody is working on patches, then what is the role of catalog-sig? Is it just a committee who deems potential patches worthy or not? > > I've written an application myself to provide PyPI-like features > internally > > due to frustration in dealing with PyPI itself from a dev perspective. > > Frustration which at least I was completely unaware of :-) > I had spoken about it to others, and only from those conversations did I get pointed to this mailing list, presumably in the hopes that something could be done (I can dream anyway). > > I gather that supporting external developers was probably not an initial > > design goal of PyPI. > > I'm not sure what you mean by "supporting external developers". > I mean, in short: "making as much data available publicly and programmatically as possible, in a manner that is not tied to or driven by a particular language, platform, or tool". As it stands, it would appear that while there have been some piecemeal achievements, the only external development that is really supported by PyPI are those that are already known entities, mostly named in the PEPs. I'm suggesting that PyPI would be of wider value to the community in general, and would increase the velocity of improvements in the packaging and distribution areas specifically if PyPI provided a generic interface to make use of all of the available data. > The initial design goals of PyPI were captured in PEP 301 > http://www.python.org/dev/peps/pep-0301/ ... and it's grown > organically since then. > Richard, I thank you and any other participants for your work and your time on this project. I hope my frustrations aren't taken as a sign of disrespect. None is intended. All the best. brian > > > Richard > -- Brian K. Jones My Blog http://www.protocolostomy.com Follow me http://twitter.com/bkjones -- Brian K. Jones My Blog http://www.protocolostomy.com Follow me http://twitter.com/bkjones -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkjones at gmail.com Wed Jan 26 03:36:55 2011 From: bkjones at gmail.com (Brian Jones) Date: Tue, 25 Jan 2011 21:36:55 -0500 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> Message-ID: Again, including the list. ---------- Forwarded message ---------- From: Brian Jones Date: Tue, Jan 25, 2011 at 9:35 PM Subject: Re: [Catalog-sig] API search by python version (or classifier) To: "Martin v. L?wis" On Tue, Jan 25, 2011 at 6:09 PM, "Martin v. L?wis" wrote: > > searching capabilities (like searching by dependency), > > I tried adding this functionality to PyPI, but it was shot down quickly > by many catalog-sig readers, see the thread starting at > > http://mail.python.org/pipermail/catalog-sig/2010-September/003301.html I'm not positive we're on the same page. You seem to be talking about adding some specific new data in a specific way to the index, and *then* making it available. I'm talking about making the *current* data available to programs the same way it's available via a web interface. It seems your ideas were shot down because "it's coming", if I read it right. I myself am kind of confused about that, because my understanding is also that "it's coming" in the form of a tool that can only be used for Python 3 packages :/ > > > a more intuitive notion of 'ranking' > > You would have to be more specific: I don't understand what that is > (or how the current ranking is unintuitive) > I'm sorry -- I meant "scoring" and not "ranking". I have yet to meet a Python user (at least in person) who actually understands what that score means and what it consists of. And a note on the PyPI site claims that packages are no longer automatically scored, leading to confusion about the potential for 'stale' scores. In addition, I can't seem to find any detailed description of what exactly goes into the score. Other package archives have methods of indicating to the user the 'vitality' and 'popularity' of a project, for example: http://help.freshmeat.net/kb/statistics/how-do-you-measure-a-projects-popularity http://help.freshmeat.net/kb/statistics/how-do-you-measure-a-projects-vitality Also note that the methods, while probably simpler than PyPIs 'score', are precisely (if not verbosely) documented. > > Please be prepared that any changes to this feature likely get shot > down, also. > Thanks for the heads up. > If it doesn't get shot down, we can > ponder implementing it, in which case contributions would be welcome. > You'd do that for me? Thanks, brian > > Regards, > Martin > -- Brian K. Jones My Blog http://www.protocolostomy.com Follow me http://twitter.com/bkjones -- Brian K. Jones My Blog http://www.protocolostomy.com Follow me http://twitter.com/bkjones -------------- next part -------------- An HTML attachment was scrubbed... URL: From ziade.tarek at gmail.com Wed Jan 26 09:49:43 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Wed, 26 Jan 2011 09:49:43 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> Message-ID: On Wed, Jan 26, 2011 at 3:36 AM, Brian Jones wrote: ... >> http://mail.python.org/pipermail/catalog-sig/2010-September/003301.html > > I'm not positive we're on the same page. You seem to be talking about adding > some specific new data in a specific way to the index, and *then* making it > available. I'm talking about making the *current* data available to programs > the same way it's available via a web interface. It seems your ideas were > shot down because "it's coming", if I read it right. I myself am kind of > confused about that, because my understanding is also that "it's coming" in > the form of a tool that can only be used for Python 3 packages :/ No, the tool will be usable by python2 packages as well. I don't want to do that thread again but basically, egg_info are platform-specific, whereas the new metadata version (PEP 345) will have them right. PyPI already supports PEP 345. .. >> >> Please be prepared that any changes to this feature likely get shot >> down, also. > > Thanks for the heads up. > >> >> ?If it doesn't get shot down, we can >> ponder implementing it, in which case contributions would be welcome. > > You'd do that for me? > Thanks, I would not use the word "get shot down", that is scary for people that want to contribute here. I'd rather say "get a consensus on a feature before implementing it", because that's really what it is. -- Tarek Ziad? | http://ziade.org From mal at egenix.com Wed Jan 26 10:33:59 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 26 Jan 2011 10:33:59 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> Message-ID: <4D3FEA87.30706@egenix.com> Tarek Ziad? wrote: > On Wed, Jan 26, 2011 at 3:36 AM, Brian Jones wrote: > ... >>> http://mail.python.org/pipermail/catalog-sig/2010-September/003301.html >> >> I'm not positive we're on the same page. You seem to be talking about adding >> some specific new data in a specific way to the index, and *then* making it >> available. I'm talking about making the *current* data available to programs >> the same way it's available via a web interface. It seems your ideas were >> shot down because "it's coming", if I read it right. I myself am kind of >> confused about that, because my understanding is also that "it's coming" in >> the form of a tool that can only be used for Python 3 packages :/ > > No, the tool will be usable by python2 packages as well. > > I don't want to do that thread again but basically, egg_info are > platform-specific, whereas the new metadata version (PEP 345) will > have them right. PyPI already supports PEP 345. Does that mean that the XML-RPC interface .release_data(package_name, version) (see http://wiki.python.org/moin/PyPiXmlRpc for details) already returns the full set of PEP 345 meta data ? I don't really see any problem with adding those new fields to the .search() API, but perhaps I'm missing something. The discussion Martin mentioned was about egg-infos files or directories. It doesn't seem to relate to searching for meta data, since - as you say - egg-info is meta data for egg files that is individual build files, not releases. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 26 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From martin at v.loewis.de Wed Jan 26 10:49:43 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 26 Jan 2011 10:49:43 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: <4D3FEA87.30706@egenix.com> References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> Message-ID: <4D3FEE37.5080103@v.loewis.de> > The discussion Martin mentioned was about egg-infos files or > directories. It doesn't seem to relate to searching for meta > data, since - as you say - egg-info is meta data for egg files > that is individual build files, not releases. While this is technically true, dependency information is for releases, not individual builds, in the majority of the cases; the OP was asking for searchable dependency information in particular. Regards, Martin From ziade.tarek at gmail.com Wed Jan 26 10:51:23 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Wed, 26 Jan 2011 10:51:23 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: <4D3FEA87.30706@egenix.com> References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> Message-ID: On Wed, Jan 26, 2011 at 10:33 AM, M.-A. Lemburg wrote: > Tarek Ziad? wrote: >> On Wed, Jan 26, 2011 at 3:36 AM, Brian Jones wrote: >> ... >>>> http://mail.python.org/pipermail/catalog-sig/2010-September/003301.html >>> >>> I'm not positive we're on the same page. You seem to be talking about adding >>> some specific new data in a specific way to the index, and *then* making it >>> available. I'm talking about making the *current* data available to programs >>> the same way it's available via a web interface. It seems your ideas were >>> shot down because "it's coming", if I read it right. I myself am kind of >>> confused about that, because my understanding is also that "it's coming" in >>> the form of a tool that can only be used for Python 3 packages :/ >> >> No, the tool will be usable by python2 packages as well. >> >> I don't want to do that thread again but basically, egg_info are >> platform-specific, whereas the new metadata version (PEP 345) will >> have them right. PyPI already supports PEP 345. > > Does that mean that the XML-RPC interface .release_data(package_name, version) > (see http://wiki.python.org/moin/PyPiXmlRpc for details) > already returns the full set of PEP 345 meta data ? Yes I did that change last year. If your package is PEP 345, you'll get those metadata published. > > I don't really see any problem with adding those new fields to the > .search() API, but perhaps I'm missing something. If you are talking about the new PEP 345 fields, I don't see any problem either. having them in the search() API needs to be done, I forgot to do it IIRC > > The discussion Martin mentioned was about egg-infos files or > directories. It doesn't seem to relate to searching for meta > data, since - as you say - egg-info is meta data for egg files > that is individual build files, not releases. The goal was to publish build data yes, but the intent was to create a dependency graph by browsing them without having to rebuild them (that's what easy_install or Pip has to do today). But they were no intent to tag them with all the information related to the system that built them. And we already have them when people are uploading binary releases (but burried in the archives) And "searching for dependencies" seems like the same need Brian has. > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source ?(#1, Jan 26 2011) >>>> Python/Zope Consulting and Support ... ? ? ? ?http://www.egenix.com/ >>>> mxODBC.Zope.Database.Adapter ... ? ? ? ? ? ? http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... ? ? ? ?http://python.egenix.com/ > ________________________________________________________________________ > > ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: > > > ? eGenix.com Software, Skills and Services GmbH ?Pastor-Loeh-Str.48 > ? ?D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > ? ? ? ? ? Registered at Amtsgericht Duesseldorf: HRB 46611 > ? ? ? ? ? ? ? http://www.egenix.com/company/contact/ > -- Tarek Ziad? | http://ziade.org From bkjones at gmail.com Wed Jan 26 14:23:28 2011 From: bkjones at gmail.com (Brian Jones) Date: Wed, 26 Jan 2011 08:23:28 -0500 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> Message-ID: On Wed, Jan 26, 2011 at 4:51 AM, Tarek Ziad? wrote: > > > And "searching for dependencies" seems like the same need Brian has. > I just want to clarify that need: I want to be able to search PyPI for all packages dependent on some package 'x'. I would think that easy_install/pip probably need the reverse: to find all dependencies of some package 'x'. It boils down to finding packages with similar attributes, and hopefully it shouldn't matter what that attribute is ('dependent on x', 'target python version y', etc). This alone doesn't seem like it should be particularly difficult, though I could see an implementation of a search for stacked attributes ('depends on x *and* target python version y *and*...) really becoming a performance/infrastructure-related issue (but I don't know anything about the current infrastructure). > > -- > > Marc-Andre Lemburg > > eGenix.com > > > > Professional Python Services directly from the Source (#1, Jan 26 2011) > >>>> Python/Zope Consulting and Support ... http://www.egenix.com/ > >>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ > >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > > ________________________________________________________________________ > > > > ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: > > > > > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > > Registered at Amtsgericht Duesseldorf: HRB 46611 > > http://www.egenix.com/company/contact/ > > > > > > -- > Tarek Ziad? | http://ziade.org > -- Brian K. Jones My Blog http://www.protocolostomy.com Follow me http://twitter.com/bkjones -------------- next part -------------- An HTML attachment was scrubbed... URL: From ziade.tarek at gmail.com Wed Jan 26 14:47:40 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Wed, 26 Jan 2011 14:47:40 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> Message-ID: On Wed, Jan 26, 2011 at 2:23 PM, Brian Jones wrote: > > > On Wed, Jan 26, 2011 at 4:51 AM, Tarek Ziad? wrote: >> >> >> And "searching for dependencies" seems like the same need Brian has. > > I just want to clarify that need: I want to be able to search PyPI for all > packages dependent on some package 'x'. I would think that easy_install/pip > probably need the reverse: to find all dependencies of some package 'x'. Yes. > It boils down to finding packages with similar attributes, and hopefully it > shouldn't matter what that attribute is ('dependent on x', 'target python > version y', etc). This alone doesn't seem like it should be particularly > difficult, though I could see an implementation of a search for stacked > attributes ('depends on x *and* target python version y *and*...) really > becoming a performance/infrastructure-related issue (but I don't know > anything about the current infrastructure). Yeah, you'd need to index the result I don't remember which, but some packaging systems repositories do this to speed up installers work. (Debian maybe). Maybe a good way to prototype this would be to create a standalone index that gets built by visiting PyPI to provide a search engine. Alexis has started such a prototype using CouchDB, because he wanted to experiment a REST-like interface to replace our current XML-RPC APIs, CC'ing him. In any case we should focus on having these tools built on the standard metadata sets: Metadata 1.0, 1.1 and 1.2. Then suggest that people add Metadata 1.2 support in their projects --target for first d2 beta: pycon-- The latter contains static dependencies definitions. see PEP 345. Working on common metadata standards for publishing depgraphs is the only sane way to do it. Cheers, Tarek -- Tarek Ziad? | http://ziade.org From ziade.tarek at gmail.com Wed Jan 26 15:16:16 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Wed, 26 Jan 2011 15:16:16 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: <4D402BBD.7040700@notmyidea.org> References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> Message-ID: 2011/1/26 Alexis M?taireau : > Hi Brian, Tarek, > > Le 26/01/2011 13:47, Tarek Ziad? a ?crit : >> Alexis has started such a prototype using CouchDB, because he wanted >> to experiment a REST-like interface to replace our current XML-RPC >> APIs, CC'ing him. > > Yes, I'm currently writing a PEP proposition, which is by now available > in here: > https://bitbucket.org/ametaireau/pypioncouch/src/79681bd0caa3/pep.rst > (but is not finished yet). Minor nitpick: You should remove all implementation specific things from that future PEP, of put them in another place. PEPs are more about standards, API etc.. and using CouchDB is a detail and not relevant for its acceptance Cheers Tarek -- Tarek Ziad? | http://ziade.org From alexis at notmyidea.org Wed Jan 26 15:12:13 2011 From: alexis at notmyidea.org (=?ISO-8859-1?Q?Alexis_M=E9taireau?=) Date: Wed, 26 Jan 2011 14:12:13 +0000 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> Message-ID: <4D402BBD.7040700@notmyidea.org> Hi Brian, Tarek, Le 26/01/2011 13:47, Tarek Ziad? a ?crit : > Alexis has started such a prototype using CouchDB, because he wanted > to experiment a REST-like interface to replace our current XML-RPC > APIs, CC'ing him. Yes, I'm currently writing a PEP proposition, which is by now available in here: https://bitbucket.org/ametaireau/pypioncouch/src/79681bd0caa3/pep.rst (but is not finished yet). You can also see a blog post I've made about that on http://blog.notmyidea.org/pypi-on-couchdb.html Also, a CouchDB instance with all the data is available at http://couchdb.notmyidea.org/pypi/ Bear in mind this *is* a work in progress. It should address the search problems you're talking about, and provide a RESTful API to query. Next step is to work on a distutils2 client to query the couchdb instance. > In any case we should focus on having these tools built on the > standard metadata sets. +1. eggs are unfortunately a hell to deal with when it comes to metadata: we are forced to downlad the distributions and extract the metadata using the setuptools egg_info command. Cheers, Alex PS: please, use my @notmyidea.org adress for python related stuff. From martin at v.loewis.de Wed Jan 26 21:44:55 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 26 Jan 2011 21:44:55 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: <4D402BBD.7040700@notmyidea.org> References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> Message-ID: <4D4087C7.3000906@v.loewis.de> > You can also see a blog post I've made about that on > http://blog.notmyidea.org/pypi-on-couchdb.html > > Also, a CouchDB instance with all the data is available at > http://couchdb.notmyidea.org/pypi/ > > Bear in mind this *is* a work in progress. It should address the search > problems you're talking about, and provide a RESTful API to query. > > Next step is to work on a distutils2 client to query the couchdb instance. FWIW, another copy of the PyPI metadata is available in FluidDB, which is also a rest-based database: http://www.fluidinfo.com/ http://fluiddb.fluidinfo.com/about/pypi-fluiddb-mirror http://fluiddb.fluidinfo.com/namespaces/loewis?returnNamespaces=True http://fluiddb.fluidinfo.com/namespaces/loewis/cheeseshop?returnTags=True > +1. eggs are unfortunately a hell to deal with when it comes to > metadata: we are forced to downlad the distributions and extract the > metadata using the setuptools egg_info command. It's your (catalog-sig reader's) choice that this is a hell to deal with: I offered to provide the metadata on PyPI, and the proposal was shot down. Had I been allowed to implement the feature, the data would have been available to everybody without downloading. Regards, Martin From martin at v.loewis.de Wed Jan 26 21:45:50 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 26 Jan 2011 21:45:50 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> Message-ID: <4D4087FE.8010500@v.loewis.de> > Minor nitpick: You should remove all implementation specific things > from that future PEP, of put them in another place. > > PEPs are more about standards, API etc.. and using CouchDB is a detail > and not relevant for its acceptance Indeed - if the URLs are specified, I'd probably implement it "directly", instead of trying to keep a couchdb instance updated. Regards, Martin From alexis at notmyidea.org Wed Jan 26 22:07:18 2011 From: alexis at notmyidea.org (=?ISO-8859-1?Q?Alexis_M=E9taireau?=) Date: Wed, 26 Jan 2011 21:07:18 +0000 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: <4D4087C7.3000906@v.loewis.de> References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087C7.3000906@v.loewis.de> Message-ID: <4D408D06.70102@notmyidea.org> Le 26/01/2011 20:44, "Martin v. L?wis" a ?crit : > FWIW, another copy of the PyPI metadata is available in FluidDB, which > is also a rest-based database: > > http://www.fluidinfo.com/ > http://fluiddb.fluidinfo.com/about/pypi-fluiddb-mirror > http://fluiddb.fluidinfo.com/namespaces/loewis?returnNamespaces=True > http://fluiddb.fluidinfo.com/namespaces/loewis/cheeseshop?returnTags=True Great ! > >> +1. eggs are unfortunately a hell to deal with when it comes to >> metadata: we are forced to downlad the distributions and extract the >> metadata using the setuptools egg_info command. > > It's your (catalog-sig reader's) choice that this is a hell to deal > with: I offered to provide the metadata on PyPI, and the proposal > was shot down. Had I been allowed to implement the feature, the data > would have been available to everybody without downloading. As stated before, the problem with those metadata is they are os specific, and one version can't be determined once for all. Putting those metadata on PyPI could be wrong, because not accurate. PEP 345 deals with those os specific issues and propose a metadata format to statically describe those os specific informations. Alex From alexis at notmyidea.org Wed Jan 26 22:10:29 2011 From: alexis at notmyidea.org (=?ISO-8859-1?Q?Alexis_M=E9taireau?=) Date: Wed, 26 Jan 2011 21:10:29 +0000 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: <4D4087FE.8010500@v.loewis.de> References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087FE.8010500@v.loewis.de> Message-ID: <4D408DC5.1050707@notmyidea.org> Le 26/01/2011 20:45, "Martin v. L?wis" a ?crit : > Indeed - if the URLs are specified, I'd probably implement it > "directly", instead of trying to keep a couchdb instance updated. That's certainly a feature to have. Nevertheless, I do think that CouchDB still have a value here, because it's greatly simplifying the replication processus, and offers a way to build local websites to browse the data in each couchdb instance (i.e. on each node). I'll do that first and let you know when something will be up and running. Alex From ziade.tarek at gmail.com Wed Jan 26 22:09:59 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Wed, 26 Jan 2011 22:09:59 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: <4D4087FE.8010500@v.loewis.de> References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087FE.8010500@v.loewis.de> Message-ID: On Wed, Jan 26, 2011 at 9:45 PM, "Martin v. L?wis" wrote: >> Minor nitpick: You should remove all implementation specific things >> from that future PEP, of put them in another place. >> >> PEPs are more about standards, API etc.. and using CouchDB is a detail >> and not relevant for its acceptance > > Indeed - if the URLs are specified, I'd probably implement it > "directly", instead of trying to keep a couchdb instance updated. Yeah - I think a CouchDB server is a good way to build a prototype / proof of concept to begin with, then push it back into PyPI if it's good and useful. > > Regards, > Martin > -- Tarek Ziad? | http://ziade.org From richard at python.org Wed Jan 26 23:55:10 2011 From: richard at python.org (Richard Jones) Date: Thu, 27 Jan 2011 09:55:10 +1100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: <4D408DC5.1050707@notmyidea.org> References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087FE.8010500@v.loewis.de> <4D408DC5.1050707@notmyidea.org> Message-ID: On Thu, Jan 27, 2011 at 8:10 AM, Alexis M?taireau wrote: > Le 26/01/2011 20:45, "Martin v. L?wis" a ?crit : >> Indeed - if the URLs are specified, I'd probably implement it >> "directly", instead of trying to keep a couchdb instance updated. > > That's certainly a feature to have. Nevertheless, I do think that > CouchDB still have a value here, because it's greatly simplifying the > replication processus, and offers a way to build local websites to > browse the data in each couchdb instance (i.e. on each node). Let's try not to conflate the one thing (access to meta-data) with the other thing (changing the backend database for other reasons). Each on their own merits :-) Richard From tseaver at palladion.com Thu Jan 27 00:23:06 2011 From: tseaver at palladion.com (Tres Seaver) Date: Wed, 26 Jan 2011 18:23:06 -0500 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: <4D408D06.70102@notmyidea.org> References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087C7.3000906@v.loewis.de> <4D408D06.70102@notmyidea.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2011 04:07 PM, Alexis M?taireau wrote: > Le 26/01/2011 20:44, "Martin v. L?wis" a ?crit : >> FWIW, another copy of the PyPI metadata is available in FluidDB, which >> is also a rest-based database: >> >> http://www.fluidinfo.com/ >> http://fluiddb.fluidinfo.com/about/pypi-fluiddb-mirror >> http://fluiddb.fluidinfo.com/namespaces/loewis?returnNamespaces=True >> http://fluiddb.fluidinfo.com/namespaces/loewis/cheeseshop?returnTags=True > > Great ! >> >>> +1. eggs are unfortunately a hell to deal with when it comes to >>> metadata: we are forced to downlad the distributions and extract the >>> metadata using the setuptools egg_info command. >> >> It's your (catalog-sig reader's) choice that this is a hell to deal >> with: I offered to provide the metadata on PyPI, and the proposal >> was shot down. Had I been allowed to implement the feature, the data >> would have been available to everybody without downloading. > > As stated before, the problem with those metadata is they are os > specific, and one version can't be determined once for all. Putting > those metadata on PyPI could be wrong, because not accurate. > > PEP 345 deals with those os specific issues and propose a metadata > format to statically describe those os specific informations. I think the SIG's response in September was a good example of "the perfect is the ene good": - - A miniscule fraction of all PyPI releases actually declare PEP 345 metadata. I see no evidence that the number is growing[1]. - - A very significant number of the packages on PyPI declare dependencies via setuptools'requires.txt'; "practicality beats purity." - - Of the packages which were made with setuptools metadata, the number for which one distribution of a given release has different dependencies than another of the same release is likely insignificant. - - Resolving conflicts in favor of source distributions would be the simplest and most useful heuristicc (binary eggs suck as a sharing format!) Exposing even imperfect dependency data while we await PEP 345 adoption would have been a useful, pragmatic thing to do. [1] Of the forty most recent releases on PyPI as of this writing: - Nnot one* correctly declared a PEP 345 'Requires-Dist' (one seemed to want that, but used 'Requires' with a version string). - Twenty-six of the forty used setuptools to declare dependencies; - Four had no package uploaded. - Five used PEP 314-style 'Requires' (no versions, not necessarily project names - FIve were "bare" distutils with no dependency metadata at all. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ArNoACgkQ+gerLs4ltQ6PowCePYji/AAlT/ORVI3InWIxqko+ 6rgAnjFJEAtjl8bTbqqEngCz1QwqmNF/ =lMhZ -----END PGP SIGNATURE----- From alexis at notmyidea.org Thu Jan 27 02:35:43 2011 From: alexis at notmyidea.org (=?ISO-8859-1?Q?Alexis_M=E9taireau?=) Date: Thu, 27 Jan 2011 01:35:43 +0000 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087C7.3000906@v.loewis.de> <4D408D06.70102@notmyidea.org> Message-ID: <4D40CBEF.9070007@notmyidea.org> Hi Tres, Le 26/01/2011 23:23, Tres Seaver a ?crit : > I think the SIG's response in September was a good example of "the > perfect is the ene good": > > - - A miniscule fraction of all PyPI releases actually declare PEP 345 > metadata. I see no evidence that the number is growing[1]. I do agree. By now, the PEP 345 is not adopted. Probably that's mainly because no installer currently manages those PEP 345 metadata format. We're working on it with distutils2. > - - A very significant number of the packages on PyPI declare > dependencies via setuptools'requires.txt'; "practicality beats > purity." It's the better way to provide metadata by now, IMO. > - - Of the packages which were made with setuptools metadata, the number > for which one distribution of a given release has different > dependencies than another of the same release is likely insignificant. The fact is that for those (tiny) proportion of projects that relies on this feature, the metadata provided by PyPI will be incorrect. I'm not sure it's acceptable. Also, there is no way to know that the metadata are incorrect, or partially correct. I'm not sure the best thing to do is to provide those wrong metadata. Probably this could ease the way to get distribution dependencies, but it's surely *not* something we can rely on for packaging purposes. > Exposing even imperfect dependency data while we await PEP 345 adoption > would have been a useful, pragmatic thing to do. We can go for something like that, but what I'm affraid of is that we propose a wrong source of informations, whereas we are working on a way to provide the same informations the right way. I do think the tradeoff to wait a bit more is right. Afterall, this feature is not vital, am I right ? Alex From ziade.tarek at gmail.com Thu Jan 27 09:16:21 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Thu, 27 Jan 2011 09:16:21 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087C7.3000906@v.loewis.de> <4D408D06.70102@notmyidea.org> Message-ID: On Thu, Jan 27, 2011 at 12:23 AM, Tres Seaver wrote: .. > > I think the SIG's response in September was a good example of "the > perfect is the ene good": > > - - A miniscule fraction of all PyPI releases actually declare PEP 345 > ?metadata. ?I see no evidence that the number is growing[1]. It can't grow if the tool used to make it is not published. So this point is not relevant. > > - - A very significant number of the packages on PyPI declare > ?dependencies via setuptools'requires.txt'; ?"practicality beats > ?purity." > > - - Of the packages which were made with setuptools metadata, the number > ?for which one distribution of a given release has different > ?dependencies than another of the same release is likely insignificant. > > - - Resolving conflicts in favor of source distributions would be the > ?simplest and most useful heuristicc (binary eggs suck as a sharing > ?format!) > > Exposing even imperfect dependency data while we await PEP 345 adoption > would have been a useful, pragmatic thing to do. I doubt it, because it would have pushed us in yet another direction by asking client application to use yet another PyPI "metadata" format that is not the future standard that was PEPed and agreed upon, PyPI should rely on the standard metadata and push them forward, especially since we're talking about a feature that does not exist yet anywhere.. I mean, we already have all the pain in the world to support in distutils2up to 3 different standards in installed projects on a system. Now that we're talking about adding features on a top of a format we want to drop next ? hug.. ISTM that pushing for PEP 345 adoption once d2 is out (It just one extra section in setup.cfg, and compatible w/ setuptools !) is way simpler and will avoid another couple of years of standing behind the "practical beats purity" when it comes to metadata. I mean, we are not removing anything, but adding new features. So let's do them the right way.. > > > [1] Of the forty most recent releases on PyPI as of this writing: > > ? ?- Nnot one* correctly declared a PEP 345 'Requires-Dist' (one > ? ?seemed to want that, but used 'Requires' with a version string). > > ? ?- Twenty-six of the ?forty used setuptools to declare > ? ? ?dependencies; > > ? ?- Four had no package uploaded. > > ? ?- Five used PEP 314-style 'Requires' (no versions, not necessarily > ? ? ?project names > > ? ?- FIve were "bare" distutils with no dependency metadata at all. > > > Tres. > - -- > =================================================================== > Tres Seaver ? ? ? ? ?+1 540-429-0999 ? ? ? ? ?tseaver at palladion.com > Palladion Software ? "Excellence by Design" ? ?http://palladion.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk1ArNoACgkQ+gerLs4ltQ6PowCePYji/AAlT/ORVI3InWIxqko+ > 6rgAnjFJEAtjl8bTbqqEngCz1QwqmNF/ > =lMhZ > -----END PGP SIGNATURE----- > > _______________________________________________ > Catalog-SIG mailing list > Catalog-SIG at python.org > http://mail.python.org/mailman/listinfo/catalog-sig > -- Tarek Ziad? | http://ziade.org From ziade.tarek at gmail.com Thu Jan 27 09:34:02 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Thu, 27 Jan 2011 09:34:02 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087C7.3000906@v.loewis.de> <4D408D06.70102@notmyidea.org> Message-ID: Oh... so what about this: - PyPI publishes setuptools metadata, but in Metadata 1.2 format. The conversion is pretty simple, it's just translating the requires.txt into PEP 345 fields. - We add a marker so we know that those metadata are from setuptools That way, PyPI has an unified interface to get the dependencies, and if there's an issue in project X because the static metadata fails on platform Y, we ask the project to provide real PEP 345 metadata. -- Tarek Ziad? | http://ziade.org From mal at egenix.com Thu Jan 27 10:05:31 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 27 Jan 2011 10:05:31 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087C7.3000906@v.loewis.de> <4D408D06.70102@notmyidea.org> Message-ID: <4D41355B.5090000@egenix.com> Tarek Ziad? wrote: > Oh... so what about this: > > - PyPI publishes setuptools metadata, but in Metadata 1.2 format. The > conversion is pretty simple, it's just translating the requires.txt > into PEP 345 fields. > - We add a marker so we know that those metadata are from setuptools > > That way, PyPI has an unified interface to get the dependencies, and > if there's an issue in project X because the static metadata fails on > platform Y, we ask the project to provide real PEP 345 metadata. +1 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From jannis at leidel.info Thu Jan 27 11:38:38 2011 From: jannis at leidel.info (Jannis Leidel) Date: Thu, 27 Jan 2011 11:38:38 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087C7.3000906@v.loewis.de> <4D408D06.70102@notmyidea.org> Message-ID: <2AF4828C-D697-4940-811A-8BF10683C18D@leidel.info> On 27.01.2011, at 09:34, Tarek Ziad? wrote: > Oh... so what about this: > > - PyPI publishes setuptools metadata, but in Metadata 1.2 format. The > conversion is pretty simple, it's just translating the requires.txt > into PEP 345 fields. > - We add a marker so we know that those metadata are from setuptools > > That way, PyPI has an unified interface to get the dependencies, and > if there's an issue in project X because the static metadata fails on > platform Y, we ask the project to provide real PEP 345 metadata. How would the last bit work? Jannis From alexis at notmyidea.org Thu Jan 27 13:08:08 2011 From: alexis at notmyidea.org (=?ISO-8859-1?Q?Alexis_M=E9taireau?=) Date: Thu, 27 Jan 2011 12:08:08 +0000 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: <4D41355B.5090000@egenix.com> References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087C7.3000906@v.loewis.de> <4D408D06.70102@notmyidea.org> <4D41355B.5090000@egenix.com> Message-ID: <4D416028.2030401@notmyidea.org> Le 27/01/2011 09:05, M.-A. Lemburg a ?crit : > Tarek Ziad? wrote: >> > Oh... so what about this: >> > >> > - PyPI publishes setuptools metadata, but in Metadata 1.2 format. The >> > conversion is pretty simple, it's just translating the requires.txt >> > into PEP 345 fields. >> > - We add a marker so we know that those metadata are from setuptools >> > >> > That way, PyPI has an unified interface to get the dependencies, and >> > if there's an issue in project X because the static metadata fails on >> > platform Y, we ask the project to provide real PEP 345 metadata. > +1 +1 for me too. From ziade.tarek at gmail.com Thu Jan 27 15:07:29 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Thu, 27 Jan 2011 15:07:29 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: <2AF4828C-D697-4940-811A-8BF10683C18D@leidel.info> References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087C7.3000906@v.loewis.de> <4D408D06.70102@notmyidea.org> <2AF4828C-D697-4940-811A-8BF10683C18D@leidel.info> Message-ID: On Thu, Jan 27, 2011 at 11:38 AM, Jannis Leidel wrote: > On 27.01.2011, at 09:34, Tarek Ziad? wrote: > >> Oh... so what about this: >> >> - PyPI publishes setuptools metadata, but in Metadata 1.2 format. The >> conversion is pretty simple, it's just translating the requires.txt >> into PEP 345 fields. >> - We add a marker so we know that those metadata are from setuptools >> >> That way, PyPI has an unified interface to get the dependencies, and >> if there's an issue in project X because the static metadata fails on >> platform Y, we ask the project to provide real PEP 345 metadata. > > How would the last bit work? By providing a [metadata] section in your setup.cfg that contains them. The idea is that a project can provide a compatibility for d2 without removing the one for d1 - so pip and easy_install still work : - d1/setuptools/distribute : setup.py - d2: setup.cfg Then, by using distutils2 register command, you can push the Metadata 1.2 to pypi. This week end we're having a sprint where we will document this process. We're also planning to provide a script to automate the creation of [metadata] by running setup.py to make it easier. > > Jannis -- Tarek Ziad? | http://ziade.org From jannis at leidel.info Thu Jan 27 16:23:42 2011 From: jannis at leidel.info (Jannis Leidel) Date: Thu, 27 Jan 2011 16:23:42 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087C7.3000906@v.loewis.de> <4D408D06.70102@notmyidea.org> <2AF4828C-D697-4940-811A-8BF10683C18D@leidel.info> Message-ID: On 27.01.2011, at 15:07, Tarek Ziad? wrote: > On Thu, Jan 27, 2011 at 11:38 AM, Jannis Leidel wrote: >> On 27.01.2011, at 09:34, Tarek Ziad? wrote: >> >>> Oh... so what about this: >>> >>> - PyPI publishes setuptools metadata, but in Metadata 1.2 format. The >>> conversion is pretty simple, it's just translating the requires.txt >>> into PEP 345 fields. >>> - We add a marker so we know that those metadata are from setuptools >>> >>> That way, PyPI has an unified interface to get the dependencies, and >>> if there's an issue in project X because the static metadata fails on >>> platform Y, we ask the project to provide real PEP 345 metadata. >> >> How would the last bit work? > > By providing a [metadata] section in your setup.cfg that contains them. > > The idea is that a project can provide a compatibility for d2 without > removing the one for d1 - so pip and easy_install still work : > > - d1/setuptools/distribute : setup.py > - d2: setup.cfg > > Then, by using distutils2 register command, you can push the Metadata > 1.2 to pypi. > > This week end we're having a sprint where we will document this > process. We're also planning to provide a script to > automate the creation of [metadata] by running setup.py to make it easier. Sounds great, +1. Jannis From ziade.tarek at gmail.com Thu Jan 27 18:25:16 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Thu, 27 Jan 2011 18:25:16 +0100 Subject: [Catalog-sig] API search by python version (or classifier) In-Reply-To: References: <4D3F5829.4060806@v.loewis.de> <4D3FEA87.30706@egenix.com> <4D402BBD.7040700@notmyidea.org> <4D4087C7.3000906@v.loewis.de> <4D408D06.70102@notmyidea.org> <2AF4828C-D697-4940-811A-8BF10683C18D@leidel.info> Message-ID: Some people worked on this today (I am sprinting myself starting tomorrow) https://bitbucket.org/tarek/distutils2/wiki/Deployments_using_setup.cfg For instance this is a Metadata v1.2 project, pushed by distutils2: http://pypi.python.org/pypi/qGitFilterBranch/0.9 (which is also compatible/installable by pip/easy_install) On Thu, Jan 27, 2011 at 4:23 PM, Jannis Leidel wrote: > On 27.01.2011, at 15:07, Tarek Ziad? wrote: > >> On Thu, Jan 27, 2011 at 11:38 AM, Jannis Leidel wrote: >>> On 27.01.2011, at 09:34, Tarek Ziad? wrote: >>> >>>> Oh... so what about this: >>>> >>>> - PyPI publishes setuptools metadata, but in Metadata 1.2 format. The >>>> conversion is pretty simple, it's just translating the requires.txt >>>> into PEP 345 fields. >>>> - We add a marker so we know that those metadata are from setuptools >>>> >>>> That way, PyPI has an unified interface to get the dependencies, and >>>> if there's an issue in project X because the static metadata fails on >>>> platform Y, we ask the project to provide real PEP 345 metadata. >>> >>> How would the last bit work? >> >> By providing a [metadata] section in your setup.cfg that contains them. >> >> The idea is that a project can provide a compatibility for d2 without >> removing the one for d1 - so pip and easy_install still work : >> >> - d1/setuptools/distribute : setup.py >> - d2: setup.cfg >> >> Then, by using distutils2 register command, you can push the Metadata >> 1.2 to pypi. >> >> This week end we're having a sprint where we will document this >> process. We're also planning to provide a script to >> automate the creation of [metadata] by running setup.py to make it easier. > > Sounds great, +1. > > Jannis > > -- Tarek Ziad? | http://ziade.org From baiju.m.mail at gmail.com Sun Jan 30 18:09:13 2011 From: baiju.m.mail at gmail.com (Baiju M) Date: Sun, 30 Jan 2011 22:39:13 +0530 Subject: [Catalog-sig] Total number of packages in PyPI Message-ID: Hi, The main PyPI page shows more than 13k packages: http://pypi.python.org/pypi But many of the packages are not really existing in PyPI: http://paste.pocoo.org/raw/329292/ Is there any auto-generated list of these packages somewhere ? Is it possible to reduce the total number in the main page by excluding these packages ? Regards, Baiju M From martin at v.loewis.de Sun Jan 30 19:18:19 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 30 Jan 2011 19:18:19 +0100 Subject: [Catalog-sig] Total number of packages in PyPI In-Reply-To: References: Message-ID: <4D45AB6B.6060708@v.loewis.de> > But many of the packages are not really existing in PyPI: > http://paste.pocoo.org/raw/329292/ > Is there any auto-generated list of these packages > somewhere ? I don't know what a "not really existing" package is; however, the answer to your question is most likely "no". > Is it possible to reduce the total number in the main page > by excluding these packages ? It might be possible, but why should this be done? Regards, Martin From baiju.m.mail at gmail.com Sun Jan 30 19:58:57 2011 From: baiju.m.mail at gmail.com (Baiju M) Date: Mon, 31 Jan 2011 00:28:57 +0530 Subject: [Catalog-sig] Total number of packages in PyPI In-Reply-To: <4D45AB6B.6060708@v.loewis.de> References: <4D45AB6B.6060708@v.loewis.de> Message-ID: On Sun, Jan 30, 2011 at 11:48 PM, "Martin v. L?wis" wrote: >> But many of the packages are not really existing in PyPI: >> http://paste.pocoo.org/raw/329292/ >> Is there any auto-generated list of these packages >> somewhere ? > > I don't know what a "not really existing" package is; For those package, there is no page with user visible information in "pypi" index but there is an empty "simple" index. For example, this page give 404: http://pypi.python.org/pypi/slapos.slapmonitor/ Whereas, this page gives an empty page: http://pypi.python.org/simple/slapos.slapmonitor/ > however, the answer to your question is most likely "no". > >> Is it possible to reduce the total number in the main page >> by excluding these packages ? > > It might be possible, but why should this be done? The total number is bit misleading. It's there in "simple" but not in "pypi" index. P.S: I am trying to build a community site for Python 3 to collect feedback about package compatibility with Python 3: http://getpython3.net/ This will be similar to http://isitruby19.com/ For now I have excluded the invisible packages. Regards, Baiju M From mal at egenix.com Sun Jan 30 20:10:30 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Sun, 30 Jan 2011 20:10:30 +0100 Subject: [Catalog-sig] Total number of packages in PyPI In-Reply-To: References: <4D45AB6B.6060708@v.loewis.de> Message-ID: <4D45B7A6.8050409@egenix.com> Baiju M wrote: > On Sun, Jan 30, 2011 at 11:48 PM, "Martin v. L?wis" wrote: >>> But many of the packages are not really existing in PyPI: >>> http://paste.pocoo.org/raw/329292/ >>> Is there any auto-generated list of these packages >>> somewhere ? >> >> I don't know what a "not really existing" package is; > > For those package, there is no page with user visible > information in "pypi" index but there is an empty "simple" index. > > For example, this page give 404: > http://pypi.python.org/pypi/slapos.slapmonitor/ > Whereas, this page gives an empty page: > http://pypi.python.org/simple/slapos.slapmonitor/ Sounds like a bug in PyPI. Perhaps those are deleted packages that, for some reason, still get displayed on the simple/ index ?! E.g. http://pypi.python.org/simple/Webware/: Links for Webware 0.8 home_page 0.8 download_url 0.8.1 home_page 0.8.1 download_url http://pypi.python.org/pypi/Webware/: Not Found () but there is a package: http://pypi.python.org/pypi/Webware for Python/ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 30 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From martin at v.loewis.de Sun Jan 30 20:33:41 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 30 Jan 2011 20:33:41 +0100 Subject: [Catalog-sig] Total number of packages in PyPI In-Reply-To: <4D45B7A6.8050409@egenix.com> References: <4D45AB6B.6060708@v.loewis.de> <4D45B7A6.8050409@egenix.com> Message-ID: <4D45BD15.7090707@v.loewis.de> >> For example, this page give 404: >> http://pypi.python.org/pypi/slapos.slapmonitor/ >> Whereas, this page gives an empty page: >> http://pypi.python.org/simple/slapos.slapmonitor/ > > Sounds like a bug in PyPI. Perhaps those are deleted packages > that, for some reason, still get displayed on the simple/ > index ?! Not at all. slapos.slapmonitor has three releases, all of which are hidden. So it really exists. > http://pypi.python.org/simple/Webware/: > Links for Webware > 0.8 home_page > 0.8 download_url > 0.8.1 home_page > 0.8.1 download_url > > http://pypi.python.org/pypi/Webware/: > Not Found () Webware has two releases (0.8 and 0.8.1), which are both hidden. > but there is a package: > > http://pypi.python.org/pypi/Webware for Python/ This is a different package (though from the same authors). Regards, Martin