From exarkun at divmod.com Thu Jan 11 13:26:23 2007 From: exarkun at divmod.com (Jean-Paul Calderone) Date: Thu, 11 Jan 2007 07:26:23 -0500 Subject: [Catalog-sig] Package removal In-Reply-To: 0 Message-ID: <20070111122623.11447.2003702108.divmod.quotient.13042@ohm> Can the Twisted Flow package, added yesterday to the cheeseshop, be removed or have its owner changed so I can hide it? The project is deprecated, the home page URL is wrong, the latest release doesn't work, and we (Twisted developers) have no desire to publicize this project. Thanks, Jean-Paul From cliff at develix.com Tue Jan 9 00:37:48 2007 From: cliff at develix.com (Cliff Wells) Date: Mon, 08 Jan 2007 15:37:48 -0800 Subject: [Catalog-sig] New category request Message-ID: <1168299469.4367.3.camel@portable-evil> Several of the major Python frameworks now support a template plugin API known as Buffet and utilize the python.templating.engines entry_point in setup.py. As such I think there should be a new category: Environment :: Web Environment :: Buffet This API is currently supported by (at least) TurboGears, CherryPy and Pylons. Regards, Cliff From constant.beta at gmail.com Thu Jan 18 14:50:51 2007 From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=) Date: Thu, 18 Jan 2007 14:50:51 +0100 Subject: [Catalog-sig] How to get a list of package releases Message-ID: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> [CC-ing this to distutils-sig, because it relates to setuptools as well, but please keep discussion on the catalog-sig if possible.] Hi, Maybe this is a stupid question, but how can I list all versions of a package that were registered on PyPI? For example, when I go to http://python.org/pypi/setuptools/ I'm redirected to the page of last version of setuptools. How can I check earlier versions of setuptools from there? I know this functionality is available for project admins, what about users? Another thing, some packages offer a development versions by giving a link to their subversion repository. Is there a way to list these extra install options on PyPI? By "extra options" I mean all non-standard version strings that will work with `easy_install package==version`, like common "dev". Related setuptools question: is there a way to get list of available versions from easy_install? Cheers, mk From pje at telecommunity.com Thu Jan 18 17:54:11 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 18 Jan 2007 11:54:11 -0500 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.co m> Message-ID: <5.1.1.6.0.20070118115051.045cb688@sparrow.telecommunity.com> At 02:50 PM 1/18/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: >Related setuptools question: is there a way to get list of available >versions from easy_install? The setuptools.package_index.PackageIndex class knows about all discoverable versions. However, this doesn't extend to versions that have been hidden by the package author. To have more than one discoverable version at the PyPI level, the author has to have made them visible in the admin interface. But, whichever ones *are* visible can be discovered by the PackageIndex class, along with any that are linked from the Home Page or Download URLs, or are linked on the package's PyPI page. More precisely, PackageIndex doesn't track versions; it tracks available *distributions*, which may include source distributions, SVN checkouts, eggs, .exe's, etc. But each distribution object carries version info determined from its filename. From richardjones at optushome.com.au Fri Jan 19 05:53:11 2007 From: richardjones at optushome.com.au (Richard Jones) Date: Fri, 19 Jan 2007 15:53:11 +1100 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> Message-ID: <200701191553.11648.richardjones@optushome.com.au> On Friday 19 January 2007 00:50, Micha? Kwiatkowski wrote: > Maybe this is a stupid question, but how can I list all versions of a > package that were registered on PyPI? You can get a full list through the XML-RPC interface: http://wiki.python.org/moin/CheeseShopXmlRpc Specifically the package_releases method. > Another thing, some packages offer a development versions by giving a > link to their subversion repository. Is there a way to list these > extra install options on PyPI? By "extra options" I mean all > non-standard version strings that will work with `easy_install > package==version`, like common "dev". The XML-RPC release_data method might tell you this information. I'm not sure how people are coding the repository information into their package meta-data. Richard From richardjones at optushome.com.au Fri Jan 19 06:07:11 2007 From: richardjones at optushome.com.au (Richard Jones) Date: Fri, 19 Jan 2007 16:07:11 +1100 Subject: [Catalog-sig] New category request In-Reply-To: <1168299469.4367.3.camel@portable-evil> References: <1168299469.4367.3.camel@portable-evil> Message-ID: <200701191607.11317.richardjones@optushome.com.au> On Tuesday 09 January 2007 10:37, Cliff Wells wrote: > Several of the major Python frameworks now support a template plugin API > known as Buffet and utilize the python.templating.engines entry_point in > setup.py. As such I think there should be a new category: > > Environment :: Web Environment :: Buffet > > This API is currently supported by (at least) TurboGears, CherryPy and > Pylons. Added. Sorry for the delay. Richard From constant.beta at gmail.com Fri Jan 19 18:06:00 2007 From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=) Date: Fri, 19 Jan 2007 18:06:00 +0100 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <200701191553.11648.richardjones@optushome.com.au> References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> Message-ID: <5e8b0f6b0701190906k46282764nae68f7938afad38e@mail.gmail.com> On 1/19/07, Richard Jones wrote: > On Friday 19 January 2007 00:50, Micha? Kwiatkowski wrote: > > Maybe this is a stupid question, but how can I list all versions of a > > package that were registered on PyPI? > > You can get a full list through the XML-RPC interface: > > http://wiki.python.org/moin/CheeseShopXmlRpc > > Specifically the package_releases method. Would you accept a patch that adds this kind of functionality to the PyPI web interface? Specifically I'm thinking about "show all versions" link that returns a page with full list of package releases. Cheers, mk From pje at telecommunity.com Fri Jan 19 18:46:20 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 19 Jan 2007 12:46:20 -0500 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <200701191553.11648.richardjones@optushome.com.au> References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> Message-ID: <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> At 11:53 PM 1/18/2007, Richard Jones wrote: >Specifically the package_releases method. That method only lists non-hidden versions; the OP wanted to know how to get information on *all* versions. >The XML-RPC release_data method might tell you this information. I'm >not sure how people are coding the repository information into their >package meta-data. You'd need to convert the release_data into HTML, or have some other way to extract the URLs from it. From richardjones at optushome.com.au Fri Jan 19 21:55:08 2007 From: richardjones at optushome.com.au (Richard Jones) Date: Sat, 20 Jan 2007 07:55:08 +1100 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> Message-ID: <200701200755.09303.richardjones@optushome.com.au> On Saturday 20 January 2007 04:46, you wrote: > At 11:53 PM 1/18/2007, Richard Jones wrote: > >Specifically the package_releases method. > > That method only lists non-hidden versions; the OP wanted to know how > to get information on *all* versions. Versions are hidden by the package maintainer for a reason. Why would you want to override that? I'll grant that the current auto-hiding of old releases might hide some releases that some package maintainers might have wanted to keep public, and that the mechanism for keeping older releases visible is a little cumbersome, but there are some package maintainers who do put in the effort to explicitly keep some older versions exposed. > >The XML-RPC release_data method might tell you this information. I'm > >not sure how people are coding the repository information into their > >package meta-data. > > You'd need to convert the release_data into HTML, or have some other > way to extract the URLs from it. Unless I'm missing something, release_data is "converted to HTML" in the web interface already - that's what the release display page is for. Richard From richardjones at optushome.com.au Fri Jan 19 21:56:38 2007 From: richardjones at optushome.com.au (Richard Jones) Date: Sat, 20 Jan 2007 07:56:38 +1100 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <5e8b0f6b0701190906k46282764nae68f7938afad38e@mail.gmail.com> References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <5e8b0f6b0701190906k46282764nae68f7938afad38e@mail.gmail.com> Message-ID: <200701200756.38522.richardjones@optushome.com.au> On Saturday 20 January 2007 04:06, Micha? Kwiatkowski wrote: > On 1/19/07, Richard Jones wrote: > > On Friday 19 January 2007 00:50, Micha? Kwiatkowski wrote: > > > Maybe this is a stupid question, but how can I list all versions of a > > > package that were registered on PyPI? > > > > You can get a full list through the XML-RPC interface: > > > > http://wiki.python.org/moin/CheeseShopXmlRpc > > > > Specifically the package_releases method. > > Would you accept a patch that adds this kind of functionality to the > PyPI web interface? Specifically I'm thinking about "show all > versions" link that returns a page with full list of package releases. Sure. Richard From martin at v.loewis.de Sat Jan 20 00:39:18 2007 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 20 Jan 2007 00:39:18 +0100 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> Message-ID: <45B156A6.8070501@v.loewis.de> Phillip J. Eby schrieb: >> Specifically the package_releases method. > > That method only lists non-hidden versions; the OP wanted to know how > to get information on *all* versions. He might have said that; I doubt he really meant it (of course, only the OP can clarify here). Regards, Martin From constant.beta at gmail.com Sat Jan 20 02:12:09 2007 From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=) Date: Sat, 20 Jan 2007 02:12:09 +0100 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <45B156A6.8070501@v.loewis.de> References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> <45B156A6.8070501@v.loewis.de> Message-ID: <5e8b0f6b0701191712x1f659807wd60f81234f9c6f65@mail.gmail.com> On 1/20/07, "Martin v. L?wis" wrote: > Phillip J. Eby schrieb: > >> Specifically the package_releases method. > > > > That method only lists non-hidden versions; the OP wanted to know how > > to get information on *all* versions. > > He might have said that; I doubt he really meant it (of course, only > the OP can clarify here). I meant listing all releases that can be installed via command "easy_install package==release". If hidden versions can't be installed this way I don't want them listed. The problem as I see it is that although easy_install can find all possible versions they are not listed on PyPI. I think this kind of asymmetry is bad for usability. I would like to work out this problem in two steps. First, port package_releases RPC to WWW interface (which will list all non-hidden versions). Second, use setuptools mechanisms to discover additional versions in package description (as described here: http://peak.telecommunity.com/DevCenter/setuptools#making-your-package-available-for-easyinstall). First is straightforward and second a bit harder, as I don't know setuptools codebase as well as PyPI's. This all can hopefully be worked out. Cheers, mk From rmunn at pobox.com Sun Jan 21 10:46:13 2007 From: rmunn at pobox.com (Robin Munn) Date: Sun, 21 Jan 2007 10:46:13 +0100 Subject: [Catalog-sig] Cheeseshop: How do I find someone's email address? Message-ID: Say I notice that the Cheeseshop entry for the SpamSpamEggsAndSpam module needs to be updated. (Perhaps it points to an out-of-date URL). I can see that the Cheese Shop Owner of that module is HungryViking, and I want to give him an email nudge to update the entry. But how would I find HungryViking's email address? -- Robin Munn rmunn at pobox.com GPG key 0x4543D577 From richardjones at optushome.com.au Sun Jan 21 21:48:34 2007 From: richardjones at optushome.com.au (Richard Jones) Date: Mon, 22 Jan 2007 07:48:34 +1100 Subject: [Catalog-sig] Cheeseshop: How do I find someone's email address? In-Reply-To: References: Message-ID: <200701220748.34609.richardjones@optushome.com.au> On Sunday 21 January 2007 20:46, Robin Munn wrote: > Say I notice that the Cheeseshop entry for the SpamSpamEggsAndSpam > module needs to be updated. (Perhaps it points to an out-of-date URL). > I can see that the Cheese Shop Owner of that module is HungryViking, > and I want to give him an email nudge to update the entry. But how > would I find HungryViking's email address? At the moment you ask for support and I handle the enquiry manually. Given that I get asked for this kind of thing about once a year it seems a reasonable way to handle things. Richard From renesd at gmail.com Mon Jan 22 07:45:34 2007 From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=) Date: Mon, 22 Jan 2007 17:45:34 +1100 Subject: [Catalog-sig] pypi caching. Can I please have apache config to test? Message-ID: <64ddb72c0701212245r17dbc9bbo9e6129133b0d939c@mail.gmail.com> Hi, I would like to help with caching pypi - so that browsing categories is faster. If the site is using apache 2, or 2.2 this can be done with the apache cache module. Could I please get the database dump, the current apache config, as well as everything else needed to test it out? I've read this page on development of pypi: http://wiki.python.org/moin/CheeseShopDev Richard: is this the place to discuss pypi dev? Or should I just email you directly. Cheers, From richardjones at optushome.com.au Mon Jan 22 08:04:41 2007 From: richardjones at optushome.com.au (Richard Jones) Date: Mon, 22 Jan 2007 18:04:41 +1100 Subject: [Catalog-sig] pypi caching. Can I please have apache config to test? In-Reply-To: <64ddb72c0701212245r17dbc9bbo9e6129133b0d939c@mail.gmail.com> References: <64ddb72c0701212245r17dbc9bbo9e6129133b0d939c@mail.gmail.com> Message-ID: <200701221804.41949.richardjones@optushome.com.au> On Monday 22 January 2007 17:45, Ren? Dudfield wrote: > I would like to help with caching pypi - so that browsing categories is > faster. > > If the site is using apache 2, or 2.2 this can be done with the apache > cache module. > > Could I please get the database dump, the current apache config, as > well as everything else needed to test it out? > > I've read this page on development of pypi: > http://wiki.python.org/moin/CheeseShopDev > > > Richard: is this the place to discuss pypi dev? Or should I just > email you directly. This is more of a discussion forum for ideas - and sometimes support requests ;) Direct email is fine for the above stuff. I'll try to get the dump for you tomorrow (I'm just heading out of the house for the night now, sorry). I'm also not certain of the apache version, but IIRC it is 2+ Richard From pje at telecommunity.com Mon Jan 22 16:17:51 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 22 Jan 2007 10:17:51 -0500 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <5e8b0f6b0701191712x1f659807wd60f81234f9c6f65@mail.gmail.co m> References: <45B156A6.8070501@v.loewis.de> <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> <45B156A6.8070501@v.loewis.de> Message-ID: <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com> At 02:12 AM 1/20/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: >The problem as I see it is that >although easy_install can find all possible versions they are not >listed on PyPI. I'm confused. easy_install can only find versions that are listed on PyPI. If there is a download link or homepage link on PyPI that points to a page with lots of downloadable versions, easy_install can discover them from there, but that's not something you're going to get through any PyPI API. From constant.beta at gmail.com Mon Jan 22 17:15:26 2007 From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=) Date: Mon, 22 Jan 2007 17:15:26 +0100 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com> References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> <45B156A6.8070501@v.loewis.de> <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com> Message-ID: <5e8b0f6b0701220815y16bd69d3u41582f30e5ddf126@mail.gmail.com> On 1/22/07, Phillip J. Eby wrote: > At 02:12 AM 1/20/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: > >The problem as I see it is that > >although easy_install can find all possible versions they are not > >listed on PyPI. > > I'm confused. easy_install can only find versions that are listed on > PyPI. If there is a download link or homepage link on PyPI that points > to a page with lots of downloadable versions, easy_install can discover > them from there, but that's not something you're going to get through any > PyPI API. Setuptools is too smart. ;) The question I'm trying to get an answer for is: "what versions of foobar can I install?". Going to http://python.org/pypi/foobar doesn't yield me any useful results - it just shows the latest release. It's not so uncommon for projects to have more than one official release - even as simple as development and stable branches. They can be installed via easy_install and setuptools is great at finding out the download locations, but there's no easy way to see what options are available from a PyPI project page. For starters, there is no "list all releases" page, and that's what my mail is mainly about. But I also have another doubt, related to this discussion. Should PyPI be treated more as a proxy or a repository? If it's a proxy, it's perfectly OK to just point people to relevant sites, when they can learn their installation options on their own. On the other hand, PyPI is a part of setuptools chain, which is a base of Python package distribution, and that means it simply cannot be treated as a plain proxy. Ambiguity may come from the fact that, opposed to its name, PyPI isn't a simple index of packages. It is also an infrastructure that makes distribution of Python packages easy. PyPI isn't only about indexing packages, but also about making them publicly available for vast community of Python developers. I understand that to encourage developers to list their packages on PyPI some compromises had to be made. Smart functionality built in into setuptools make a transition as simple as putting a link to project homepage into PyPI package info. Question is how long this transitional state should be kept? Currently we have a lot more logic in the client (easy_install) than in the server (PyPI). So now we have this strange situation when an installation client knows more about a package than the packages server. Shouldn't we constantly move toward removing magic from setuptools and porting important bits to PyPI? Cheers, mk From pje at telecommunity.com Mon Jan 22 18:54:32 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 22 Jan 2007 12:54:32 -0500 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <5e8b0f6b0701220815y16bd69d3u41582f30e5ddf126@mail.gmail.co m> References: <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com> <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> <45B156A6.8070501@v.loewis.de> <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com> At 05:15 PM 1/22/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: >Currently we have a lot more logic in the client (easy_install) than >in the server (PyPI). So now we have this strange situation when an >installation client knows more about a package than the packages >server. Shouldn't we constantly move toward removing magic from >setuptools and porting important bits to PyPI? I dunno. What actual problem are you trying to solve, or what use case are you trying to support? For example, why do you want to know what versions are available *in an automated way*? From constant.beta at gmail.com Tue Jan 23 03:54:46 2007 From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=) Date: Tue, 23 Jan 2007 03:54:46 +0100 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com> References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> <45B156A6.8070501@v.loewis.de> <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com> <5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com> Message-ID: <5e8b0f6b0701221854j1dc293f2g8652ff080cb4e44@mail.gmail.com> On 1/22/07, Phillip J. Eby wrote: > At 05:15 PM 1/22/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: > >Currently we have a lot more logic in the client (easy_install) than > >in the server (PyPI). So now we have this strange situation when an > >installation client knows more about a package than the packages > >server. Shouldn't we constantly move toward removing magic from > >setuptools and porting important bits to PyPI? > > I dunno. What actual problem are you trying to solve, or what use case > are you trying to support? Cleaner architecture probably. Or is sourceforge magic going to stay? I always thought sourceforge support was temporary, just to ease migration toward setuptools. > For example, why do you want to know what versions are available *in an > automated way*? Why we write programs at all? To automate things we don't want to repeatedly do ourselves. If setuptools is so good at finding available versions of a package, why should we force user to find these information themself? If we can take out pain from PyPI user experience, we should do it. You already done that for finding out download locations with easy_install. Users don't have to click links and find eggs themselves. The same goes for finding out available versions. Since this data is already available to setuptools I really don't understand why we should not port this to PyPI, so that users will be able to check their options even without setuptools installed. Maybe you ask about why on earth someone needs a list of releases? Well, maybe someone finds a bug in current release and want to try earlier version. If the current release is 0.8 how user will know what was the previous? Was it 0.7? 0.7.5? Maybe 0.8rc3? Of course there are more use cases. I don't really understand why this have to be explained - probably each package index out there (freshmeat, CPAN, rubyforge, sourceforge, berlios) have a list of releases available. Of course there is a possibility that this functionality is useless and I'm the only one that needs it, but IMHO chances for that are slim. The thing with PyPI is that it really needs usability improvements. We hear complains from time to time on this list, sometimes in blogosphere, about things like non-functional search or broken links etc. Complains aren't the problem - because we can react to these - problem is with general user experience. If a user won't find what he is looking for on PyPI he probably won't shout about it, but will go somewhere else (like CPAN or Rubygems). "We don't need this because nobody asked for it" is a really bad excuse. Setuptools may do a great job at the low level but the whole system may suck because user is pushed off because of bad PyPI experience. Having said that I'll try to propose few more improvements in oncoming weeks, that will make PyPI experience better, I hope. If you have any suggestions on what is lacking, I will love to hear them. Cheers, mk From pje at telecommunity.com Tue Jan 23 06:15:02 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 23 Jan 2007 00:15:02 -0500 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <5e8b0f6b0701221854j1dc293f2g8652ff080cb4e44@mail.gmail.com > References: <5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com> <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> <45B156A6.8070501@v.loewis.de> <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com> <5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com> At 03:54 AM 1/23/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: >On 1/22/07, Phillip J. Eby wrote: > > At 05:15 PM 1/22/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: > > >Currently we have a lot more logic in the client (easy_install) than > > >in the server (PyPI). So now we have this strange situation when an > > >installation client knows more about a package than the packages > > >server. Shouldn't we constantly move toward removing magic from > > >setuptools and porting important bits to PyPI? > > > > I dunno. What actual problem are you trying to solve, or what use case > > are you trying to support? > >Cleaner architecture probably. To accomplish what goals? "Cleaner" can't be defined without reference to some goal, like reduction of bugs, ease of extension/change, etc. > Or is sourceforge magic going to stay? >I always thought sourceforge support was temporary, just to ease >migration toward setuptools. The SourceForge magic is essentially gone as of 0.6c5; SourceForge fixed their system so that neither screenscraping nor SF URL recognition is required. > > For example, why do you want to know what versions are available *in an > > automated way*? > >Why we write programs at all? To automate things we don't want to >repeatedly do ourselves. If setuptools is so good at finding available >versions of a package, why should we force user to find these >information themself? I still don't understand you. What will they be using that information *for*? > If we can take out pain from PyPI user >experience, we should do it. You haven't shown that the absence of this information is causing anybody any pain, beause I don't know what you are expecting anybody to *do* with this information. I can't say I have ever needed this; I just install the latest version, or I specify a specific version. I can't recall ever wanting to find out "what versions are available", in other words. So I still don't know what problem you're trying to solve. >Maybe you ask about why on earth someone needs a list of releases? Yes. >Well, maybe someone finds a bug in current release and want to try >earlier version. If the current release is 0.8 how user will know what >was the previous? Was it 0.7? 0.7.5? Maybe 0.8rc3? "easy_install 'thepackage<0.8'" will find it and install it. >Of course there are more use cases. Such as? >I don't really understand why this have to be >explained - probably each package index out there (freshmeat, CPAN, >rubyforge, sourceforge, berlios) have a list of releases available. So does PyPI - you just have to manually follow the links right now, unless you want it in *machine-readable* form (e.g. so you can then display it to the user). So, the use case of "I just want to know what releases are available" is handled already, if you assume a human user. It may not be *convenient*, but it is clearly *possible*. >"We don't need this because nobody asked for it" is a really bad excuse You seem to be under the impression that I said the feature isn't needed. In fact, I am *still* merely trying to find out what problem you are trying to solve! This is an essential first step before trying to design a solution, but you appear to be under the impression that people should somehow telepathically know what problem you are trying to solve, perhaps by reverse-engineering your proposed solution (which is underspecified in any event). I think perhaps that you are also under the mistaken impression that I have anything to do with how PyPI is maintained, developed, or operated; I only maintain setuptools, so anything you want done server-side is another issue. setuptools uses PyPI, but the two are conceptually distinct (unlike say, CPAN, where the client and server are more-or-less considered parts of one whole). >Having said that I'll try to propose few more improvements in oncoming >weeks, that will make PyPI experience better, I hope. If you have any >suggestions on what is lacking, I will love to hear them. Certainly there are UI (and other) improvements to PyPI that I would like to see, and I've proposed/requested many of them on this list more than once in the past. However, in the absence of volunteers to *implement* those requested improvements, there is unlikely to be any change in the status quo. From constant.beta at gmail.com Sat Jan 27 18:07:51 2007 From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=) Date: Sat, 27 Jan 2007 18:07:51 +0100 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com> References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> <45B156A6.8070501@v.loewis.de> <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com> <5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com> <5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com> Message-ID: <5e8b0f6b0701270907i5260d512wcf6c4faec1c23268@mail.gmail.com> On 1/23/07, Phillip J. Eby wrote: > At 03:54 AM 1/23/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: > > Or is sourceforge magic going to stay? > >I always thought sourceforge support was temporary, just to ease > >migration toward setuptools. > > The SourceForge magic is essentially gone as of 0.6c5; SourceForge fixed > their system so that neither screenscraping nor SF URL recognition is > required. Still sourceforge is treated in a special way. Users of other systems have to manually put their links/files on PyPI. Is this special support going to stay? And is it working, for example, with BerliOS-hosted projects? > >Well, maybe someone finds a bug in current release and want to try > >earlier version. If the current release is 0.8 how user will know what > >was the previous? Was it 0.7? 0.7.5? Maybe 0.8rc3? > > "easy_install 'thepackage<0.8'" will find it and install it. What if user doesn't have easy_install installed when he is looking for an answer? Maybe he knows where in the code the problem lies, so he want to check earlier versions' code without installing? Maybe he want to skim through changelog? > >Of course there are more use cases. > > Such as? You said sometimes you need a specific release. So you may be told you need 0.7. You may just go and try to do easy_install==0.7. Or you may look at list of releases and check if 0.7.5 is there. 0.8rc2 won't buy it, so doing easy_install<0.8 won't work here. Sometimes you're just looking at available libraries for doing a specific task. You may want to look at a few versions of a package from any computer, even if it doesn't have easy_install installed (or even Python for that matter). PyPI should be usable on itself, it's a web interface after all. We can't assume that every PyPI user have easy_install on his local machine. List of packages is also useful for historical reasons. A library that had few dozens of releases starting from 2003 is probably better tested than a library with three versions released this year. > >I don't really understand why this have to be > >explained - probably each package index out there (freshmeat, CPAN, > >rubyforge, sourceforge, berlios) have a list of releases available. > > So does PyPI - you just have to manually follow the links right now, > unless you want it in *machine-readable* form (e.g. so you can then > display it to the user). What links? Where are the links for all published releases of a given package? Did I miss something? > >"We don't need this because nobody asked for it" is a really bad excuse > > You seem to be under the impression that I said the feature isn't > needed. In fact, I am *still* merely trying to find out what problem you > are trying to solve! Again: "PyPI can't show a list of package releases" (isn't this in a message subject?). Is this a problem? Maybe not. Does other popular package indexes have it? Yes. (I don't even know one which doesn't have it) It may be that everyone is wrong and solved non-existing problem with this functionality, but I goes not. > I think perhaps that you are also under the mistaken impression that I > have anything to do with how PyPI is maintained, developed, or operated; > I only maintain setuptools, so anything you want done server-side is > another issue. setuptools uses PyPI, but the two are conceptually > distinct (unlike say, CPAN, where the client and server are more-or-less > considered parts of one whole). I think who mantains what isn't an issue here. What matters is user experience and this binds PyPI and setuptools very tightly. > >Having said that I'll try to propose few more improvements in oncoming > >weeks, that will make PyPI experience better, I hope. If you have any > >suggestions on what is lacking, I will love to hear them. > > Certainly there are UI (and other) improvements to PyPI that I would like > to see, and I've proposed/requested many of them on this list more than > once in the past. However, in the absence of volunteers to *implement* > those requested improvements, there is unlikely to be any change in the > status quo. Talking about whenever an average PyPI user would need a given functionality won't change it either. So lets just say I'll implement this, it will get merged and we'll look at some PyPI logs after some time. If people use it (for whatever reason) - it will stay. I'm currently during my exam session but it will hopefully end soon, so I'll have some time under my belt to implement some functionality for PyPI. Feel free to post your list of changes you'd like to see in PyPI, so we'd have better understanding of what is needed. Or even better: update TODO on http://wiki.python.org/moin/CheeseShopDev (I don't know if it's up-to-date and represent real needs, so claryfing that would be nice as well). Cheers, mk From pje at telecommunity.com Sat Jan 27 18:40:45 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Sat, 27 Jan 2007 12:40:45 -0500 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <5e8b0f6b0701270907i5260d512wcf6c4faec1c23268@mail.gmail.co m> References: <5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com> <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> <45B156A6.8070501@v.loewis.de> <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com> <5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com> <5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20070127122938.0280c100@sparrow.telecommunity.com> At 06:07 PM 1/27/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: >On 1/23/07, Phillip J. Eby wrote: > > At 03:54 AM 1/23/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: > > > Or is sourceforge magic going to stay? > > >I always thought sourceforge support was temporary, just to ease > > >migration toward setuptools. > > > > The SourceForge magic is essentially gone as of 0.6c5; SourceForge fixed > > their system so that neither screenscraping nor SF URL recognition is > > required. > >Still sourceforge is treated in a special way. Uh, no, it isn't. > Users of other systems >have to manually put their links/files on PyPI. So do users of SourceForge. >Is this special >support going to stay? And is it working, for example, with >BerliOS-hosted projects? If your "Home Page" or "Download URL" on PyPI is a page that contains direct download links, easy_install will recognize them. This means that if your Download URL is a SF files page, the links will get recognized. If BerliOS or whatever has similar pages, and somebody links the right page from their download URL, then it should also work. > > >Well, maybe someone finds a bug in current release and want to try > > >earlier version. If the current release is 0.8 how user will know what > > >was the previous? Was it 0.7? 0.7.5? Maybe 0.8rc3? > > > > "easy_install 'thepackage<0.8'" will find it and install it. > >What if user doesn't have easy_install installed when he is looking >for an answer? Maybe he knows where in the code the problem lies, so >he want to check earlier versions' code without installing? Maybe he >want to skim through changelog? And how is that a requirement for an automated list of versions? All of that is stuff that requires manual searching anyway; the data that easy_install gathers isn't going to help you there. >PyPI should be usable on itself, it's a web interface after all. Yep, and it works just fine. See, it has a "home page" link where people can go to the project's actual home page to find things out about it. >What links? Where are the links for all published releases of a given >package? Did I miss something? PyPI shows the packages the owner has chosen to show. If the owner doesn't show old releases, that's his or her choice. > > >"We don't need this because nobody asked for it" is a really bad excuse > > > > You seem to be under the impression that I said the feature isn't > > needed. In fact, I am *still* merely trying to find out what problem you > > are trying to solve! > >Again: "PyPI can't show a list of package releases" (isn't this in a >message subject?). I still fail to see why this is a problem. It's not PyPI's job to show releases a package owner has chosen to hide. However, you could argue perhaps that the mere act of creating a new release shouldn't cause older releases to become hidden -- in other words, showing releases by default instead of hiding them. You could also argue for changelog-like features, or other features. What is still NOT clear -- because you still haven't explained it -- is why this information needs to be available to automated tools, as opposed to simply being available to humans through the web interface. None of the use cases you've presented seem to call for an automated tool. From renesd at gmail.com Sun Jan 28 00:21:02 2007 From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=) Date: Sun, 28 Jan 2007 10:21:02 +1100 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <5.1.1.6.0.20070127122938.0280c100@sparrow.telecommunity.com> References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> <45B156A6.8070501@v.loewis.de> <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com> <5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com> <5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com> <5.1.1.6.0.20070127122938.0280c100@sparrow.telecommunity.com> Message-ID: <64ddb72c0701271521l39682893x767c017d59c4c068@mail.gmail.com> On 1/28/07, Phillip J. Eby wrote: > > What is still NOT clear -- because you still haven't explained it -- is why > this information needs to be available to automated tools, as opposed to > simply being available to humans through the web interface. None of the > use cases you've presented seem to call for an automated tool. For tools which make interfaces to read pypi. There is at least one application that browses pypi that is not the web based interface. From pje at telecommunity.com Sun Jan 28 02:44:28 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Sat, 27 Jan 2007 20:44:28 -0500 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <64ddb72c0701271521l39682893x767c017d59c4c068@mail.gmail.co m> References: <5.1.1.6.0.20070127122938.0280c100@sparrow.telecommunity.com> <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> <45B156A6.8070501@v.loewis.de> <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com> <5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com> <5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com> <5.1.1.6.0.20070127122938.0280c100@sparrow.telecommunity.com> Message-ID: <5.1.1.6.0.20070127204400.028a8a98@sparrow.telecommunity.com> At 10:21 AM 1/28/2007 +1100, Ren? Dudfield wrote: >On 1/28/07, Phillip J. Eby wrote: > > > > What is still NOT clear -- because you still haven't explained it -- is why > > this information needs to be available to automated tools, as opposed to > > simply being available to humans through the web interface. None of the > > use cases you've presented seem to call for an automated tool. > > >For tools which make interfaces to read pypi. There is at least one >application that browses pypi that is not the web based interface. And all the information available to it is exactly the same as what a human user obtains, no? From renesd at gmail.com Sun Jan 28 03:50:44 2007 From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=) Date: Sun, 28 Jan 2007 13:50:44 +1100 Subject: [Catalog-sig] How to get a list of package releases In-Reply-To: <5.1.1.6.0.20070127204400.028a8a98@sparrow.telecommunity.com> References: <5e8b0f6b0701180550t341939aewd9eadbab3d8f5ccb@mail.gmail.com> <200701191553.11648.richardjones@optushome.com.au> <7.0.1.0.0.20070119124425.021ad550@telecommunity.com> <45B156A6.8070501@v.loewis.de> <5.1.1.6.0.20070122101642.044463d8@sparrow.telecommunity.com> <5.1.1.6.0.20070122125326.028e8e38@sparrow.telecommunity.com> <5.1.1.6.0.20070123000127.02864480@sparrow.telecommunity.com> <5.1.1.6.0.20070127122938.0280c100@sparrow.telecommunity.com> <5.1.1.6.0.20070127204400.028a8a98@sparrow.telecommunity.com> Message-ID: <64ddb72c0701271850q49299fav7465846aa9909853@mail.gmail.com> It uses the xmlrpc interface. Not sure if that answers your question. On 1/28/07, Phillip J. Eby wrote: > At 10:21 AM 1/28/2007 +1100, Ren? Dudfield wrote: > >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. > > > > > >For tools which make interfaces to read pypi. There is at least one > >application that browses pypi that is not the web based interface. > > And all the information available to it is exactly the same as what a human > user obtains, no? > > From ghazel at gmail.com Tue Jan 30 23:54:02 2007 From: ghazel at gmail.com (ghazel at gmail.com) Date: Tue, 30 Jan 2007 14:54:02 -0800 Subject: [Catalog-sig] greenlets Message-ID: <151643b20701301454n561b990ey8bcb78886ae05463@mail.gmail.com> I have noticed the greenlet module http://cheeseshop.python.org/pypi/greenlet is out of date with the library it is copied from http://codespeak.net/py/ I recently submitted a bug fix for this package in py.lib, and it's possible I'm the only developer actively working on greenlets. If Bob would rather, I'd like to be the package maintainer of the cheeseshop greenlet module. -Greg Hazel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/catalog-sig/attachments/20070130/266aee9b/attachment.html From bob at redivi.com Wed Jan 31 00:10:04 2007 From: bob at redivi.com (Bob Ippolito) Date: Tue, 30 Jan 2007 15:10:04 -0800 Subject: [Catalog-sig] greenlets In-Reply-To: <151643b20701301454n561b990ey8bcb78886ae05463@mail.gmail.com> References: <151643b20701301454n561b990ey8bcb78886ae05463@mail.gmail.com> Message-ID: <6a36e7290701301510h30110ec2qcced91779904b5c2@mail.gmail.com> That works for me. What's your CheeseShop user name? -bob On 1/30/07, ghazel at gmail.com wrote: > I have noticed the greenlet module > http://cheeseshop.python.org/pypi/greenlet > > is out of date with the library it is copied from > http://codespeak.net/py/ > > I recently submitted a bug fix for this package in py.lib, and it's possible > I'm the only developer actively working on greenlets. If Bob would rather, > I'd like to be the package maintainer of the cheeseshop greenlet module. > > -Greg Hazel > _______________________________________________ > Catalog-sig mailing list > Catalog-sig at python.org > http://mail.python.org/mailman/listinfo/catalog-sig > > > From ghazel at gmail.com Wed Jan 31 00:28:12 2007 From: ghazel at gmail.com (ghazel at gmail.com) Date: Tue, 30 Jan 2007 15:28:12 -0800 Subject: [Catalog-sig] greenlets In-Reply-To: <6a36e7290701301510h30110ec2qcced91779904b5c2@mail.gmail.com> References: <151643b20701301454n561b990ey8bcb78886ae05463@mail.gmail.com> <6a36e7290701301510h30110ec2qcced91779904b5c2@mail.gmail.com> Message-ID: <151643b20701301528m65d38ff1o60e38249fe1589d6@mail.gmail.com> ghazel -Greg On 1/30/07, Bob Ippolito wrote: > > That works for me. What's your CheeseShop user name? > > -bob > > On 1/30/07, ghazel at gmail.com wrote: > > I have noticed the greenlet module > > http://cheeseshop.python.org/pypi/greenlet > > > > is out of date with the library it is copied from > > http://codespeak.net/py/ > > > > I recently submitted a bug fix for this package in py.lib, and it's > possible > > I'm the only developer actively working on greenlets. If Bob would > rather, > > I'd like to be the package maintainer of the cheeseshop greenlet module. > > > > -Greg Hazel > > _______________________________________________ > > Catalog-sig mailing list > > Catalog-sig at python.org > > http://mail.python.org/mailman/listinfo/catalog-sig > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/catalog-sig/attachments/20070130/d66e03e5/attachment.html From bob at redivi.com Wed Jan 31 00:29:06 2007 From: bob at redivi.com (Bob Ippolito) Date: Tue, 30 Jan 2007 15:29:06 -0800 Subject: [Catalog-sig] greenlets In-Reply-To: <151643b20701301528m65d38ff1o60e38249fe1589d6@mail.gmail.com> References: <151643b20701301454n561b990ey8bcb78886ae05463@mail.gmail.com> <6a36e7290701301510h30110ec2qcced91779904b5c2@mail.gmail.com> <151643b20701301528m65d38ff1o60e38249fe1589d6@mail.gmail.com> Message-ID: <6a36e7290701301529p7a579054v73c7e20843b1a574@mail.gmail.com> Done. -bob On 1/30/07, ghazel at gmail.com wrote: > ghazel > > -Greg > > > On 1/30/07, Bob Ippolito wrote: > > That works for me. What's your CheeseShop user name? > > > > -bob > > > > On 1/30/07, ghazel at gmail.com wrote: > > > I have noticed the greenlet module > > > http://cheeseshop.python.org/pypi/greenlet > > > > > > is out of date with the library it is copied from > > > http://codespeak.net/py/ > > > > > > I recently submitted a bug fix for this package in py.lib, and it's > possible > > > I'm the only developer actively working on greenlets. If Bob would > rather, > > > I'd like to be the package maintainer of the cheeseshop greenlet module. > > > > > > -Greg Hazel > > > _______________________________________________ > > > Catalog-sig mailing list > > > Catalog-sig at python.org > > > http://mail.python.org/mailman/listinfo/catalog-sig > > > > > > > > > > > > >