From chris at simplistix.co.uk Mon Nov 2 23:52:29 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Mon, 02 Nov 2009 22:52:29 +0000 Subject: [Catalog-sig] Package comments In-Reply-To: <4AE758C6.2020201@v.loewis.de> References: <4AE758C6.2020201@v.loewis.de> Message-ID: <4AEF62AD.4000201@simplistix.co.uk> Martin v. L?wis wrote: > Some package maintainers are unhappy with the recent addition > of a rating-and-comment facility in PyPI; they don't want to > see user comments on their package page (the rating itself > is not being challenged, AFAIU). > > As it is difficult to get the community opinion on this particular > issue, I plan to hold a poll. In preparation for that, I started > collecting arguments for both sides on > > http://wiki.python.org/moin/PyPIComments > > Feel free to add arguments that you think are missing in these > lists; please refrain from removing arguments (even if you think > they are flawed). Please make sure this poll is well advertised and not set up in such a way that is only gets the answer you're looking for ;-) I see 3 voting options: - keep the current commenting system - allow package maintainers to choose whether they want to have commenting enabled on their package or not. - remove all commenting completely cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From jannis at leidel.info Tue Nov 3 14:02:39 2009 From: jannis at leidel.info (Jannis Leidel) Date: Tue, 3 Nov 2009 14:02:39 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <4AE758C6.2020201@v.loewis.de> References: <4AE758C6.2020201@v.loewis.de> Message-ID: <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> Am 27.10.2009 um 21:32 schrieb Martin v. L?wis: > Some package maintainers are unhappy with the recent addition > of a rating-and-comment facility in PyPI; they don't want to > see user comments on their package page (the rating itself > is not being challenged, AFAIU). For the record, I *did* question the rating feature on this list and still think it's inappropriate for a package index. As are the comments. > At the same time, I believe that users very much want to see > comments on a package page, telling them whether the package > is useful or not (in particular if it has received low ratings). > > As it is difficult to get the community opinion on this particular > issue, I plan to hold a poll. In preparation for that, I started > collecting arguments for both sides on > > http://wiki.python.org/moin/PyPIComments > > Feel free to add arguments that you think are missing in these > lists; please refrain from removing arguments (even if you think > they are flawed). Since you mentioned on the SourceForge ticket (https://sourceforge.net/tracker/?func=detail&atid=513503&aid=2872293&group_id=66150 ) that one reason why comments were implemented is because many people requested it: I hereby request the feature to be able to selectively disable comments for my PyPI packages. FWIW, I think Jacob's proposal in the ticket above is worth considering: "allow package owners to disable comments, but only if they provide a link to an alternate forum". Jannis From martin at v.loewis.de Tue Nov 3 18:08:16 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 03 Nov 2009 18:08:16 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> Message-ID: <4AF06380.9060503@v.loewis.de> Jannis Leidel wrote: > Am 27.10.2009 um 21:32 schrieb Martin v. L?wis: > >> Some package maintainers are unhappy with the recent addition >> of a rating-and-comment facility in PyPI; they don't want to >> see user comments on their package page (the rating itself >> is not being challenged, AFAIU). > > For the record, I *did* question the rating feature on this list and > still think it's inappropriate for a package index. As are the comments. Ah, ok. So would you also put that on a public poll? > Since you mentioned on the SourceForge ticket > (https://sourceforge.net/tracker/?func=detail&atid=513503&aid=2872293&group_id=66150) > that one reason why comments were implemented is because many people > requested it: > > I hereby request the feature to be able to selectively disable comments > for my PyPI packages. I'll be holding a public poll. > FWIW, I think Jacob's proposal in the ticket above is worth considering: > "allow package owners to disable comments, but only if they provide a > link to an alternate forum". I'd like to propose yet another compromise: let the package author indicate that they dislike seeing comments, but allow them posting of comments if they decide to, anyway. What do you think? Regards, Martin From pje at telecommunity.com Tue Nov 3 19:09:43 2009 From: pje at telecommunity.com (P.J. Eby) Date: Tue, 03 Nov 2009 13:09:43 -0500 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF06380.9060503@v.loewis.de> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> Message-ID: <20091103180943.9243A3A408C@sparrow.telecommunity.com> At 06:08 PM 11/3/2009 +0100, Martin v. L?wis wrote: >I'd like to propose yet another compromise: let the package author >indicate that they dislike seeing comments, but allow them posting >of comments if they decide to, anyway. What do you think? I think this provides an even greater incentive for trolling or "griefing" comments. From jmg3000 at gmail.com Tue Nov 3 19:23:11 2009 From: jmg3000 at gmail.com (John Gabriele) Date: Tue, 3 Nov 2009 13:23:11 -0500 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF06380.9060503@v.loewis.de> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> Message-ID: <65e0bb520911031023q3c48fa6eh453165b7066320d6@mail.gmail.com> On Tue, Nov 3, 2009 at 12:08 PM, "Martin v. L?wis" wrote: > Jannis Leidel wrote: >> Am 27.10.2009 um 21:32 schrieb Martin v. L?wis: >> >>> Some package maintainers are unhappy with the recent addition >>> of a rating-and-comment facility in PyPI; they don't want to >>> see user comments on their package page (the rating itself >>> is not being challenged, AFAIU). >> >> For the record, I *did* question the rating feature on this list and >> still think it's inappropriate for a package index. As are the comments. > > Ah, ok. So would you also put that on a public poll? > [snip] > I'd like to propose yet another compromise: let the package author > indicate that they dislike seeing comments, but allow them posting > of comments if they decide to, anyway. What do you think? I added a "Poll" section to the end of http://wiki.python.org/moin/PyPIComments which lists some choices that might be available in such a poll. Martin, if I understand correctly, you're proposing adding a feature where package maintainers may allow/disallow individual comments (possibly as a spam-prevention measure?), so I listed that also among the possible voting choices. Thanks, ---John From martin at v.loewis.de Tue Nov 3 19:41:30 2009 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Tue, 03 Nov 2009 19:41:30 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <65e0bb520911031023q3c48fa6eh453165b7066320d6@mail.gmail.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <65e0bb520911031023q3c48fa6eh453165b7066320d6@mail.gmail.com> Message-ID: <4AF0795A.2090202@v.loewis.de> > I added a "Poll" section to the end of > http://wiki.python.org/moin/PyPIComments which lists some choices that > might be available in such a poll. > > Martin, if I understand correctly, you're proposing adding a feature > where package maintainers may allow/disallow individual comments > (possibly as a spam-prevention measure?) Not really - I didn't mean to propose something like that. Instead, I would merely add to the comment box a text "the maintainer has asked that comments are made ". , so I listed that also among > the possible voting choices. Thanks for the list. I think the options are fairly difficult to parse, so I would probably formulate them more shortly, e.g. - ratings and comments on all packages - maintainer can opt-out of comments (but not out of ratings) - a) - no comments (but keep ratings) - neither ratings nor comments - b) a) see above; this option can probably go b) this probably is "allow private comments (sent to author only)" it's an option, but it would imply that the commenter's email address is revealed to the package author (which it currently is not) In any case, I think it's good to collect the questions up-front; people who miss options should add them. Regards, Martin From jannis at leidel.info Tue Nov 3 22:32:05 2009 From: jannis at leidel.info (Jannis Leidel) Date: Tue, 3 Nov 2009 22:32:05 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF06380.9060503@v.loewis.de> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> Message-ID: <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> Am 03.11.2009 um 18:08 schrieb Martin v. L?wis: > Jannis Leidel wrote: >> Am 27.10.2009 um 21:32 schrieb Martin v. L?wis: >> >>> Some package maintainers are unhappy with the recent addition >>> of a rating-and-comment facility in PyPI; they don't want to >>> see user comments on their package page (the rating itself >>> is not being challenged, AFAIU). >> >> For the record, I *did* question the rating feature on this list and >> still think it's inappropriate for a package index. As are the >> comments. > > Ah, ok. So would you also put that on a public poll? Yep, already done, thanks to John. >> Since you mentioned on the SourceForge ticket >> (https://sourceforge.net/tracker/?func=detail&atid=513503&aid=2872293&group_id=66150 >> ) >> that one reason why comments were implemented is because many people >> requested it: >> >> I hereby request the feature to be able to selectively disable >> comments >> for my PyPI packages. > > I'll be holding a public poll. Thanks, I hope that will help. >> FWIW, I think Jacob's proposal in the ticket above is worth >> considering: >> "allow package owners to disable comments, but only if they provide a >> link to an alternate forum". > > I'd like to propose yet another compromise: let the package author > indicate that they dislike seeing comments, but allow them posting > of comments if they decide to, anyway. What do you think? -1 That would defeat the purpose of being able to channel feedback to an alternative location, e.g. the dedicated issue trackers for my packages. Jannis From martin at v.loewis.de Tue Nov 3 22:49:19 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 03 Nov 2009 22:49:19 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> Message-ID: <4AF0A55F.8080901@v.loewis.de> > -1 That would defeat the purpose of being able to channel feedback to an > alternative location, e.g. the dedicated issue trackers for my packages. Please understand that the purpose of the commenting system is *not* to report bugs, but to let users voice their genuine opinion about the package. Telling them to use the tracker is, IMO, depriving them of their right to explain their evaluation of the package; a bug tracker is not an adequate means for that. Regards, Martin From jannis at leidel.info Wed Nov 4 00:46:23 2009 From: jannis at leidel.info (Jannis Leidel) Date: Wed, 4 Nov 2009 00:46:23 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF0A55F.8080901@v.loewis.de> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> Message-ID: Am 03.11.2009 um 22:49 schrieb Martin v. L?wis: >> -1 That would defeat the purpose of being able to channel feedback >> to an >> alternative location, e.g. the dedicated issue trackers for my >> packages. > > Please understand that the purpose of the commenting system is *not* > to report bugs, but to let users voice their genuine opinion about the > package. Telling them to use the tracker is, IMO, depriving them of > their right to explain their evaluation of the package; a bug > tracker is > not an adequate means for that. First, I should note that I'm the last person who wants to deprive the users of my packages of their right to tell the world how good or bad the packages are. That's just ridiculous. But - and please don't take this as an offense - I disagree with the idea of a package index which introduces a notion of quality by using rating and comments because they are subjective and occasionally sketchy. I don't really mind PyPI being "just" an index of Python software in contrast to a troll atracting site like download.com, softpedia.com or macupdate.com . I like that it's the infrastructue we rely on in buildout and pip but wonder if user feedback is really required for that. Why not create a separate site with ratings and comments, along the lines of Jacob's cheeserater.com (now defunct) or Plone's software center? Jannis From pje at telecommunity.com Wed Nov 4 01:39:45 2009 From: pje at telecommunity.com (P.J. Eby) Date: Tue, 03 Nov 2009 19:39:45 -0500 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF0A55F.8080901@v.loewis.de> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> Message-ID: <20091104003946.F29AC3A408C@sparrow.telecommunity.com> At 10:49 PM 11/3/2009 +0100, Martin v. L?wis wrote: >Telling them to use the tracker is, IMO, depriving them of >their right to explain their evaluation of the package; a bug tracker is >not an adequate means for that. No, but their personal blog(s) are a wonderfully available and appropriate place for them to do so... assuming that one believes that this "right" exists in the first place. After all, if the general public has a "right" to make such comments, then the download page of Python.org should allow similarly unmoderated comments, and disallow any Python developer from deleting those comments. (That would be "censorship", after all.) Microsoft's Windows Update webpage should likewise be open to comment, as should Apple's iTunes page. That would really help other users! (Not.) Yes, let's all have a right to comment on every web page, just because the creator of that web page has chosen to offer some software for us to use. The idea of a "right" to comment on a software package's download page is a *really* bad idea, and it deserves much worse ridicule than it's currently receiving in this discussion. Cleaning off graffiti is not censorship. If you want to provide a comment process, why not include a link to search Google for backlinks to the package page, and let people write blog posts about the package that way? Then the authors and users alike can search to see what's being said about the package. Then, if you really feel that PyPI must provide free hosting for trolls, put the comments on a web page somewhere with a backlink, and let them compete for relevance with those who care enough about what they have to say to write something more thoughtful and relevant than "this sucks! boo!" or "it's awesome! yay!". IMO, it should be easier to find thoughtful commentary and experience reports about a package, than to read a list of low-quality, 1-or-2 line graffiti scrawls(which is what the current system demonstrably encourages). From lac at openend.se Wed Nov 4 04:33:05 2009 From: lac at openend.se (Laura Creighton) Date: Wed, 04 Nov 2009 04:33:05 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: Message from "P.J. Eby" of "Tue, 03 Nov 2009 19:39:45 EST." <20091104003946.F29AC3A408C@sparrow.telecommunity.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> Message-ID: <200911040333.nA43X59W008762@theraft.openend.se> I think that a rating system -- so many stars -- can only be effective if there are hundreds, perhaps thousands of raters. Otherwise the variation between 'what I think is worth 5 stars' and 'what somebody else does' is too large to make even non-trollish responses meaningful. I am thinking about the rating system that amazon has for its books. I find it useful to read the reviews, sometimes, but never the number of stars. Practically every technical book that I consider excellent has some readers who rank it poorly; while many books I consider rubbish get high marks. Some of this reflects my personal taste in technical books 'give me a concise summary rather than an encyclopedia, please' but mostly this reflects how well or poorly the goals the author of the book had when writing the book fit my goaks in reading the book. The weirder the thing is that I wanted to do, the less useful, in general, I found the book, as is only to be expected. There are two great problems I see with a perfectly working rating system. The first is that people tend to use it instead of developing their own judgment. If there are X packages out there for doing something, one can sympathise with a desire to know 'which one is the best' -- but it is rare that you can get an answer to this question outside of the context of 'and what do you intend to do with it?'. So-and-so is simpler, such-and-such is more complete, this one runs very quickly but eats memory like a pig, while that one is tiny but slow; which one you prefer depends on what you are doing. The second problem is related to the first. If, by some chance, one of the X packages gets great reviews by its first users, it will look better than its alternates to the casual browser, who will then choose it. Thus you can generate momentum rather easily this way, even when the preferred package is arguably one of the weakest of the choices. Conversely, a great package that has been reviewed by some exacting people -- or some people who tried to use it for something for which it was not suited -- may be skipped over in favour of an inferior package. I don't think that anything can substitute for developing one's own judgement, and mechanisms that attempt to do so should be resisted because they damage all of us in the long run. Laura From martin at v.loewis.de Wed Nov 4 07:03:50 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 04 Nov 2009 07:03:50 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> Message-ID: <4AF11946.6010505@v.loewis.de> > Why not create a separate site with ratings and comments, along the > lines of Jacob's cheeserater.com (now defunct) or Plone's software center? So it would all be fine, if I only rendered the comments on ratepypi.org, instead of pypi.python.org? Would it still be ok if a link from pypi.python.org would link to ratepypi.org? Regards, Martin From martin at v.loewis.de Wed Nov 4 07:13:16 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 04 Nov 2009 07:13:16 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <20091104003946.F29AC3A408C@sparrow.telecommunity.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> Message-ID: <4AF11B7C.2040302@v.loewis.de> P.J. Eby wrote: > At 10:49 PM 11/3/2009 +0100, Martin v. L?wis wrote: >> Telling them to use the tracker is, IMO, depriving them of >> their right to explain their evaluation of the package; a bug tracker is >> not an adequate means for that. > > No, but their personal blog(s) are a wonderfully available and > appropriate place for them to do so... assuming that one believes that > this "right" exists in the first place. Hmm. Then why do we need PyPI in the first place, if all people could learn about the Python packages from the blogs of the package authors? > After all, if the general public has a "right" to make such comments, > then the download page of Python.org should allow similarly unmoderated > comments, and disallow any Python developer from deleting those > comments. (That would be "censorship", after all.) And indeed, we have that: wiki.python.org. Except for deletion of spam, no censorship is applied. > Microsoft's > Windows Update webpage should likewise be open to comment, as should > Apple's iTunes page. That would really help other users! (Not.) I'm in no position to control what Microsoft does. As for Apple, the appstore does (I hear) have such a feature. I'm not an iTunes user, so I can't comment whether it is similar to a software repository or not. > Cleaning off graffiti is not censorship. And I'm in favor of deleting spam (i.e. comments that are clearly unrelated to the package - as graffiti is clearly unrelated to the place where it gets attached). Regards, Martin From ubernostrum at gmail.com Wed Nov 4 07:56:13 2009 From: ubernostrum at gmail.com (James Bennett) Date: Wed, 4 Nov 2009 00:56:13 -0600 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF11B7C.2040302@v.loewis.de> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> Message-ID: <21787a9f0911032256x2cbe631er1423dc25d4eb34bc@mail.gmail.com> I think there are issues with both ratings and comments, and that at the very least the decision to enable/disable them should be left to the package's administrator. First up, ratings and comments in general: Ratings face the well-documented issue of clustering -- the YouTube data is one useful point, and there are plenty of others which indicate that, on anything more complex than an up/down rating, the observed ratings will cluster on one or both extremes of the rating scale. Comments face a related issue which exposes the psychology a bit more clearly: there's a barrier to commenting (you have to register), and so only people who feel strongly that their comment should be seen will put in the effort to get it posted. In my experience, this results in the opposite of the YouTube phenomenon: comments will tend to cluster strongly around the negative extreme of the spectrum (people who are very upset about something are generally willing to go to more effort to express their feeling than people who are very happy about it). Next, the problems with PyPI's implementation in particular: Ratings, while less useful than they could otherwise be, don't really seem to be the issue. Rather, comments are. Specifically... * Since package maintainers are typically already pressed for time, it's unlikely they'll participate much even if granted the ability to do so, preferring instead the discussion and support channels they've already set up. * But since package maintainers cannot currently respond to comments, they're useless as a means of communicating with package authors or meaningfully discussing packages. * Since package maintainers also cannot remove abusive comments, PyPI presents an "attractive nuisance" of sorts; people who wish to troll or bash on a package/author will be able to do so with no particular consequences. * Since package maintainers have no way -- short of ad-hoc attempts to abuse package descriptions -- to point users toward more useful discussion forums, it's likely that at least some users will never discover such forums. * Corollary: since PyPI has pretty decent Google juice, it's likely that at least some users will confuse it with an official support channel (see, for example, the infamous Maury Povich incident[1]). The fact that PyPI displays official Python branding exacerbates this problem (see also: the controversy over GetSatisfaction using company logos[1]). Where I stand, personally: I'd like very much for both ratings and comments to just go away. If someone wants to provide a third-party service which *does not* have official Python branding, that'd be fine, because it's unlikely anyone would confuse such a service for an official support channel. At the very least, the ability to disable comments should be in the hands of the package maintainer(s), and PyPI should offer a mechanism for connecting users to official support channels for packages. If the implementation stays as-is, well, looks like the only option I'll have left is to pull my packages off the index. Fortunately, the standard tools all seem to work well with package URLs instead of PyPI package names... [1] http://www.metafilter.com/33213/Tuesdays-with-Maury [2] http://37signals.com/svn/posts/1650-get-satisfaction-or-else -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." From mal at egenix.com Wed Nov 4 10:55:08 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 04 Nov 2009 10:55:08 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF11B7C.2040302@v.loewis.de> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> Message-ID: <4AF14F7C.3050807@egenix.com> "Martin v. L?wis" wrote: > And I'm in favor of deleting spam (i.e. comments that are clearly > unrelated to the package - as graffiti is clearly unrelated to > the place where it gets attached). I think we have to differentiate a bit more: PyPI is the central place where users go to find packages. As such, it's much higher ranked than some blog, newsgroup, wiki, mailing list or even a site dedicated to just rating and commenting on Python packages. Messages posted on PyPI receive a lot more visibility than other places - mostly because it provides the download links to many packages, so care has to be taken when allowing public comments in this particular spot. Package authors will love good comments and probably also appreciate criticism, but mainly negative comments would likely not go down too well, esp. if these comments are not really based on good intentions or just rants. So the main question becomes: What to do with negative comments ? Or taken to a higher level: Does PyPI really want to get into the business of dealing with these problems ? If PyPI is meant to go social rather than being purely a search engine, then the ones who put their content up on PyPI should at the very least be allowed to reply to comments and to be fair, ratings should be visible to all and only be possible together with a comment. Regarding the usefulness of such a feature, take the PIL package as example: http://pypi.python.org/pypi/PIL/1.1.6 """ Package rating (3 votes): 4.66666666667 * 4 points: 1 vote * 5 points: 2 votes Ratings range from 0 to 5 (best). Package Comments: * Hugely stable, been around forever, and works. Unfortunate distribution naming causes problems with setuptools. (chrisw, 2009-10-05, points) * super cool lib - #1 pick! just sad to see the packaging difficulties. (jensens, 2009-10-05, points) """ Those comments are not really all that useful for a user, since they put too much emphasis on a non-package related issue. This is like saying: "Great bag, but doesn't come in pink, so only 4 points.". An educated user will notice, a casual user will just see the negative vibes and not bother with PIL, since it "causes problems" - now *that* is sad. Personally, I think that PyPI should not be in the social business. We have plenty of sites, wikis, blogs, mailing lists, etc. that already serve those needs quite well (and which are self-maintaining) and provide more context than a two line comment. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 04 2009) >>> 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 renesd at gmail.com Wed Nov 4 11:41:41 2009 From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=) Date: Wed, 4 Nov 2009 10:41:41 +0000 Subject: [Catalog-sig] Package comments In-Reply-To: References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> Message-ID: <64ddb72c0911040241i5ff6199fs2bde68c796b15476@mail.gmail.com> Hi, here's some ideas and observations from other places rating python projects. Depending on the community(and particular packages), I'm not sure if it will attract trolls or not. As an example, the comments on the pygame website I can't remember negative comments on there. I'm sure there have been some though. Hopefully pypi comments will be just as friendly :) Feedback is good under any circumstance... even bug reports :) Some people don't have bug trackers, or forums... and never get any feedback for their packages or programs. Ratings like used in pyweek are also useful... but that has various different aspects for ratings, not just one number. The games are rated under different categories: * Fun * Innovation * Production (graphics, sound, polish) * Overall In the past there were other categories (like 7 of them). Things like sound/music, comedy etc. An important rating was 'Did not work for me', or 'Not Applicable' (NA). This allows people to quickly tell the author something did not work for them. A few suggestions for rating categories... - documentation - tests - portability - packaging - fun - innovation - production - overall As you can see, which categories you use for ratings can be important for different types of software, and will also move some people towards improving their packages in those areas. A package may have a rating of 10 for tests, but 0 for documentation. In a 0-5 rating system, this information is not available to the person. This is why some really awesome things in 0-5 rating systems get rated 2.5... if 50% of people think it's a 5, and 50% of people think it is a 0. Even with a wider range of categories, a project could still be Awesome(tm) but only get ratings of 0 in all the categories. Some people just want to upload code, and do not want to be critised(constructively or not), or reviewed. Should we be caring about what these people want? I think so. Critisism does take a long time to get used to... and for some it is a way of life, but others do not take it very well. Perhaps this is just a thing they need to get used to. Really, people should just be able to share their code without having negative things happen to them. We want people to have fun with coding python right? This is why I not-at-all-strongly-agree that authors should be able to opt out/in of ratings, and reviews if they want to - even though I personally like them. Ohloh is another website which rates open source(including python) projects... http://www.ohloh.net/p/compare?metric=Contributors&project_0=Python+programming+language&project_1=PyPy&project_2=Parrot Ohloh only has a 1-5 rating, and also offers a way to review projects. Rather than just comments, they have specific 'reviews'... so it tends to mostly get reviews, not free form comments. Reviews also have a well understood form and have an academic history. You can tell a good review from bad easily if you have the academic background. Also reviews take the form of 'wow, this is awesome... I wish it could do X though...', which are just as valid and useful as other types of reviews. Even short reviews like 'I tried this package, but I like X package better' are useful. Ohloh also provides a number of other project metrics which they (try) to cover. You can look at things like activity, code size, number of contributors, and things like that. Much like the previous code 'kwalitee' project which used various automated metrics on pypi packages. Where ohloh tries to rate packages against other ones, I don't think that is necessary. It's done to create competition, and controversy... which aren't necessarily things people want. Having top 10 rating lists, and such are not needed really... ratings can be done on a per project basis and still be useful. They use other things which are not really fair... like number of commits, number of lines changed and other such things to rate contributors to a project. These can be useful, but they do not give credit to many other people who contribute to projects (eg, people applying patches, people writing docs and tutorials, and the list goes on). Free-form comments can be good to allow the community to use them as they wish. Allowing users and authors to communicate with each other. Communication is a multiple way process... if authors can not reply back, it is not communication. However it is still communication between the different users of packages. In conclusion, my rating is... Comments: (X) Good ( ) Bad cu, From renesd at gmail.com Wed Nov 4 12:01:11 2009 From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=) Date: Wed, 4 Nov 2009 11:01:11 +0000 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF14F7C.3050807@egenix.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> Message-ID: <64ddb72c0911040301y40e5dc6fy6a70c8e75841a35b@mail.gmail.com> On Wed, Nov 4, 2009 at 9:55 AM, M.-A. Lemburg wrote: > > Regarding the usefulness of such a feature, take the PIL package > as example: > > http://pypi.python.org/pypi/PIL/1.1.6 > > """ > ?Package rating (3 votes): 4.66666666667 > > ? ?* 4 points: 1 vote > ? ?* 5 points: 2 votes > > Ratings range from 0 to 5 (best). > Package Comments: > > ? ?* Hugely stable, been around forever, and works. Unfortunate distribution naming causes problems > with setuptools. (chrisw, 2009-10-05, points) > ? ?* super cool lib - #1 pick! just sad to see the packaging difficulties. (jensens, 2009-10-05, > points) > """ > > Those comments are not really all that useful for a user, > since they put too much emphasis on a non-package related issue. > This is like saying: "Great bag, but doesn't come in pink, so > only 4 points.". An educated user will notice, a casual user > will just see the negative vibes and not bother with PIL, > since it "causes problems" - now *that* is sad. > hello, I do see how they could be perceived as not being good comments. However I see them differently, as being useful... Those comments are both positive, and friendly... but are also offering constructive critisism. They give an overall good impression of PIL(that it deserves). They both mention a common problem people have with PIL/Image/python imaging. I've had this problem myself, and I've helped people with this problem over the years. It's great feedback for the authors of PIL in my opinion, and is a win for the comments on pypi. If the authors decide to fix the problems mentioned, then it's a win for users of PIL too. People with commercial packages on there would be right to not like comments in some respects. Since commercial organisations often like to control their PR as much as possible. So in this way, the comments are not such a good thing for PIL. However also, commercial organisations pay a lot for feedback, QA and market research... so in a way it is also good for commercial packages too. The python community likes openness I would say, and comments go towards more openness. Comments move the communication on pypi from entirely author based, towards letting users speak as well. Should openness be valued more than valuing an authors wishes? Packages can already remove themselves from pypi if they don't like it. However, as someone said before, being able to disable certain features would still let them use the features they want. cu, From mal at egenix.com Wed Nov 4 12:42:01 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 04 Nov 2009 12:42:01 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <64ddb72c0911040301y40e5dc6fy6a70c8e75841a35b@mail.gmail.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> <64ddb72c0911040301y40e5dc6fy6a70c8e75841a35b@mail.gmail.com> Message-ID: <4AF16889.3070706@egenix.com> Ren? Dudfield wrote: > On Wed, Nov 4, 2009 at 9:55 AM, M.-A. Lemburg wrote: >> >> Regarding the usefulness of such a feature, take the PIL package >> as example: >> >> http://pypi.python.org/pypi/PIL/1.1.6 >> >> """ >> Package rating (3 votes): 4.66666666667 >> >> * 4 points: 1 vote >> * 5 points: 2 votes >> >> Ratings range from 0 to 5 (best). >> Package Comments: >> >> * Hugely stable, been around forever, and works. Unfortunate distribution naming causes problems >> with setuptools. (chrisw, 2009-10-05, points) >> * super cool lib - #1 pick! just sad to see the packaging difficulties. (jensens, 2009-10-05, >> points) >> """ >> >> Those comments are not really all that useful for a user, >> since they put too much emphasis on a non-package related issue. >> This is like saying: "Great bag, but doesn't come in pink, so >> only 4 points.". An educated user will notice, a casual user >> will just see the negative vibes and not bother with PIL, >> since it "causes problems" - now *that* is sad. >> > > > hello, > > I do see how they could be perceived as not being good comments. > However I see them differently, as being useful... Those comments are > both positive, and friendly... but are also offering constructive > critisism. They give an overall good impression of PIL(that it > deserves). > > They both mention a common problem people have with PIL/Image/python > imaging. I've had this problem myself, and I've helped people with > this problem over the years. It's great feedback for the authors of > PIL in my opinion, and is a win for the comments on pypi. If the > authors decide to fix the problems mentioned, then it's a win for > users of PIL too. > > People with commercial packages on there would be right to not like > comments in some respects. Since commercial organisations often like > to control their PR as much as possible. So in this way, the comments > are not such a good thing for PIL. However also, commercial > organisations pay a lot for feedback, QA and market research... so in > a way it is also good for commercial packages too. > > The python community likes openness I would say, and comments go > towards more openness. Comments move the communication on pypi from > entirely author based, towards letting users speak as well. Should > openness be valued more than valuing an authors wishes? There are enough ways available already to contact the author, provide constructive criticism, feedback, etc. Users can do so both in public and private ways. The problem with making PyPI a social platform is that you are removing the neutral view on things from the index - something I think encourages people to upload their stuff to PyPI in the first place. By not having comments on PyPI you don't limit the openness we have in the Python community in any way. Users can still search for user comments (and will readily find them), if they care to do so, or just ask on c.l.p for first-hand experience with a particular package or recommendation on which to choose. > Packages can already remove themselves from pypi if they don't like > it. However, as someone said before, being able to disable certain > features would still let them use the features they want. Making ratings and comments optional would certainly help. Only leaving the option to remove the complete package in order to opt-out of these features is not a very Pythonic way to go about these things (and indeed does limit the openness). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 04 2009) >>> 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 ubernostrum at gmail.com Wed Nov 4 12:42:16 2009 From: ubernostrum at gmail.com (James Bennett) Date: Wed, 4 Nov 2009 05:42:16 -0600 Subject: [Catalog-sig] Package comments In-Reply-To: <64ddb72c0911040301y40e5dc6fy6a70c8e75841a35b@mail.gmail.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> <64ddb72c0911040301y40e5dc6fy6a70c8e75841a35b@mail.gmail.com> Message-ID: <21787a9f0911040342pf068050r93755b5f527a2710@mail.gmail.com> On Wed, Nov 4, 2009 at 5:01 AM, Ren? Dudfield wrote: > People with commercial packages on there would be right to not like > comments in some respects. ?Since commercial organisations often like > to control their PR as much as possible. ?So in this way, the comments > are not such a good thing for PIL. ?However also, commercial > organisations pay a lot for feedback, QA and market research... so in > a way it is also good for commercial packages too. > > The python community likes openness I would say, and comments go > towards more openness. ?Comments move the communication on pypi from > entirely author based, towards letting users speak as well. ?Should > openness be valued more than valuing an authors wishes? Except this isn't "openness", not by a long shot. The current implementation gives package maintainers *no voice whatsoever* -- openness, discussion, communication, etc. must be able to go both ways. More important, though, is the question of what PyPI is really supposed to be, and what features are part of its scope. Personally I lean toward keeping the scope narrow and letting other services fill in additional features as desired, but it's instructive to note that the only times I've ever seen the broader approach work well are in communities where it's assumed and understood from the outset that you're buying into a pretty large stack of development and project-management technologies (e.g., Debian's packaging system, Perl's CPAN, etc.). PyPI is not and never has been such a thing. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." From pje at telecommunity.com Wed Nov 4 16:25:34 2009 From: pje at telecommunity.com (P.J. Eby) Date: Wed, 04 Nov 2009 10:25:34 -0500 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF11B7C.2040302@v.loewis.de> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> Message-ID: <20091104152540.260333A4105@sparrow.telecommunity.com> At 07:13 AM 11/4/2009 +0100, Martin v. L?wis wrote: >And I'm in favor of deleting spam (i.e. comments that are clearly >unrelated to the package - as graffiti is clearly unrelated to >the place where it gets attached). Not so - if I spraypaint "your service sucks" on a restaurant's window, it is still graffiti, no matter how truthful, accurate, or relevant the comment may be. (FWIW, I don't object to making a ratings site and providing a link, although I think that using a solid off-the-shelf discussion system would be better than a roll-your-own. Reddit, for example, is written in Python, and has some reasonable protections against trolling and spamming.) From martin at v.loewis.de Wed Nov 4 19:16:21 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 04 Nov 2009 19:16:21 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <21787a9f0911032256x2cbe631er1423dc25d4eb34bc@mail.gmail.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <21787a9f0911032256x2cbe631er1423dc25d4eb34bc@mail.gmail.com> Message-ID: <4AF1C4F5.5040603@v.loewis.de> > Comments face a related issue which exposes the psychology a bit more > clearly: there's a barrier to commenting (you have to register) In the current implementation on PyPI, you also have to register to participate in the rating. > In my experience, this > results in the opposite of the YouTube phenomenon: comments will tend > to cluster strongly around the negative extreme of the spectrum > (people who are very upset about something are generally willing to go > to more effort to express their feeling than people who are very happy > about it). In the case of PyPI, experience so far shows the opposite: comments are, in general, supportive of the package. > * Since package maintainers are typically already pressed for time, > it's unlikely they'll participate much even if granted the ability > to do so, preferring instead the discussion and support channels > they've already set up. But this misses totally the point of the feature. If I have to research the support channels first, and filter out technical discussions to actually get to opinions, I might as well evaluate the package myself directly. > * But since package maintainers cannot currently respond to comments, That's not true - they can. > * Since package maintainers also cannot remove abusive comments That's not true - they can issue a support request to remove a comment. > * Since package maintainers have no way -- short of ad-hoc attempts to > abuse package descriptions -- to point users toward more useful > discussion forums, it's likely that at least some users will never > discover such forums. So you mean, the users have no way of finding out what the support channels are? How are they then supposed to use them? Regards, Martin From martin at v.loewis.de Wed Nov 4 19:26:12 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 04 Nov 2009 19:26:12 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF14F7C.3050807@egenix.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> Message-ID: <4AF1C744.7020100@v.loewis.de> > If PyPI is meant to go social rather than being purely a search > engine, then the ones who put their content up on PyPI should at > the very least be allowed to reply to comments That's already the case - package authors can respond to comments. > and to be fair, > ratings should be visible to all and only be possible together with > a comment. I don't think that would work - if people *have* to leave a comment, they surely leave nonsense. Regards, Martin From martin at v.loewis.de Wed Nov 4 19:36:23 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 04 Nov 2009 19:36:23 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <21787a9f0911040342pf068050r93755b5f527a2710@mail.gmail.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> <64ddb72c0911040301y40e5dc6fy6a70c8e75841a35b@mail.gmail.com> <21787a9f0911040342pf068050r93755b5f527a2710@mail.gmail.com> Message-ID: <4AF1C9A7.8020306@v.loewis.de> > Except this isn't "openness", not by a long shot. The current > implementation gives package maintainers *no voice whatsoever* -- > openness, discussion, communication, etc. must be able to go both > ways. That's just not true. Package owners can respond to comments they get. > PyPI is not and never has been such a thing. On the other hand, PyPI has grown from its initial scope for many years, with nobody complaining. First, it got support to host also files (rather than being a mere index), and it grew support for being machine-accessible (when it initially was targeted at human users). More recently, it got support for hosting documentation as well. For quite some time, an automated rating feature was part of the installation - the cheesecake index. Users complained that this was confusing and unusable, and requested to replace it with a rating+comment machinery. So the "new" feature is really more a replacement of a feature that had been around for years. Regards, Martin From jannis at leidel.info Wed Nov 4 20:09:31 2009 From: jannis at leidel.info (Jannis Leidel) Date: Wed, 4 Nov 2009 20:09:31 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF11946.6010505@v.loewis.de> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <4AF11946.6010505@v.loewis.de> Message-ID: <90459231-41DB-472E-A871-1BFE3EF83020@leidel.info> Am 04.11.2009 um 07:03 schrieb Martin v. L?wis: >> Why not create a separate site with ratings and comments, along the >> lines of Jacob's cheeserater.com (now defunct) or Plone's software >> center? > > So it would all be fine, if I only rendered the comments on > ratepypi.org, instead of pypi.python.org? Sure, there is nothing wrong with having a 3rd party site where users can leave comments and rate packages. > Would it still be ok if a link from pypi.python.org would link to > ratepypi.org? IMO, it would be ok if the link is optional, if I -- as the package author or maintainer -- can decide if a link to an external site shows up on the PyPI page of my packages, similar to the homepage and the download URL. Without such control over my packages I would seriously reconsider putting them on PyPI and rather put the files on S3, Bitbucket or Github. Maby I would even ask around to create a separate index and use one of the alternative implementations. Jannis From mal at egenix.com Wed Nov 4 20:13:45 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 04 Nov 2009 20:13:45 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF1C744.7020100@v.loewis.de> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> <4AF1C744.7020100@v.loewis.de> Message-ID: <4AF1D269.7000109@egenix.com> "Martin v. L?wis" wrote: >> If PyPI is meant to go social rather than being purely a search >> engine, then the ones who put their content up on PyPI should at >> the very least be allowed to reply to comments > > That's already the case - package authors can respond to comments. Thanks, I wasn't aware of that. >> and to be fair, >> ratings should be visible to all and only be possible together with >> a comment. > > I don't think that would work - if people *have* to leave a comment, > they surely leave nonsense. I don't believe so... their comments will carry their login name and show the rating and all this will be visible to the public. Even if the comment just says "Great work" or "Doesn't work for me", that's already a lot better than casting an anonymous vote. By requiring a public comment, there's more incentive for people to think twice before pressing the submit button. That said, I don't think it's a good idea to try to reinvent a wheel that has already been invented many times over. Just look at the successful systems running on e.g. Amazon and eBay. We don't really need to go through all the pain they've gone through to build successful systems again. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 04 2009) >>> 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 ianb at colorstudy.com Wed Nov 4 20:14:04 2009 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 4 Nov 2009 13:14:04 -0600 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF14F7C.3050807@egenix.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> Message-ID: On Wed, Nov 4, 2009 at 3:55 AM, M.-A. Lemburg wrote: > If PyPI is meant to go social rather than being purely a search > engine, then the ones who put their content up on PyPI should at > the very least be allowed to reply to comments and to be fair, > ratings should be visible to all and only be possible together with > a comment. For low ratings (e.g., 1 or 2) forcing a comment might be interesting. Higher ratings (4-5) are usually not that interesting ("it works as documented"). > Regarding the usefulness of such a feature, take the PIL package > as example: > > http://pypi.python.org/pypi/PIL/1.1.6 > > """ > ?Package rating (3 votes): 4.66666666667 > > ? ?* 4 points: 1 vote > ? ?* 5 points: 2 votes > > Ratings range from 0 to 5 (best). > Package Comments: > > ? ?* Hugely stable, been around forever, and works. Unfortunate distribution naming causes problems > with setuptools. (chrisw, 2009-10-05, points) > ? ?* super cool lib - #1 pick! just sad to see the packaging difficulties. (jensens, 2009-10-05, > points) > """ > > Those comments are not really all that useful for a user, > since they put too much emphasis on a non-package related issue. > This is like saying: "Great bag, but doesn't come in pink, so > only 4 points.". An educated user will notice, a casual user > will just see the negative vibes and not bother with PIL, > since it "causes problems" - now *that* is sad. To make it more useful I just added a comment to point to a easy_installable version of PIL. In my mind this basically resolves the packaging issue, through sideways communication among users of PIL. This sideways communication is useful. It just occurred to me that virtualenv-distribute (a fork of my virtualenv package) had functionality now duplicated by the latest virtualenv release, so I left a comment to that effect on that package (I also had to rate, which was annoying -- I just wanted to add information). I could have contacted the author, and I guess I did by leaving a comment, but this way I can contact the author and everyone else at the same time (like emailing a mailing list instead of personal email). So... I guess after thinking about it, I'm seeing more potential for comments. That said, I also think it is entirely reasonable to give package authors dictatorial control over comments, allowing them to delete anything. I don't believe that power is any more likely to be abused than comments themselves will be abused. If deletion keeps the comments in the database (but hidden) and is required to be accompanied with a justification (just free text, with maybe a shortcut for spam) then if there really are problems then they can be talked out. I also think we can try to resolve some problems through the use of human-readable text (on the site and in the emails the site generates) rather than through code. (Oops, looking back I was supposed to provide some text for the comments, but I haven't...) That is: if we agree some things are inappropriate for comments, and some things are particularly useful for comments, then we say that explicitly on the site. I expect commenters will pay attention to those guidelines. Same thing for comment deletion. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker From lac at openend.se Wed Nov 4 20:47:33 2009 From: lac at openend.se (Laura Creighton) Date: Wed, 04 Nov 2009 20:47:33 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: Message from "M.-A. Lemburg" of "Wed, 04 Nov 2009 20:13:45 +0100." <4AF1D269.7000109@egenix.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> <4AF1C744.7020100@v.loewis.de> <4AF1D269.7000109@egenix.com> Message-ID: <200911041947.nA4JlXPm019071@theraft.openend.se> In a message of Wed, 04 Nov 2009 20:13:45 +0100, "M.-A. Lemburg" writes: >That said, I don't think it's a good idea to try to reinvent a >wheel that has already been invented many times over. Just look at >the successful systems running on e.g. Amazon and eBay. We don't >really need to go through all the pain they've gone through to >build successful systems again. > >-- >Marc-Andre Lemburg >eGenix.com I don't think that the Amazon system is successful. I think that you are confusing two things -- 'people like to rate things' with 'the rating is meaningful'. I think that the Amazon rating system satifices people's desire to rate things, but is a detriment to actually finding a technical book that will help you do what you want to do. Only fairly detailed reviews can help with that, and only to the extent that they exclude certain works, leaving you to review the remainder on your own. Why should software be any different? Also, remember, amazon makes money no matter whose books are purchased, But we would rather help people find the best packages for their purposes, no? I think that a rating system harms this goal, and therefore we should not do it. Laura From mal at egenix.com Wed Nov 4 21:50:41 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 04 Nov 2009 21:50:41 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <200911041947.nA4JlXPm019071@theraft.openend.se> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> <4AF1C744.7020100@v.loewis.de> <4AF1D269.7000109@egenix.com> <200911041947.nA4JlXPm019071@theraft.openend.se> Message-ID: <4AF1E921.5030103@egenix.com> Laura Creighton wrote: > In a message of Wed, 04 Nov 2009 20:13:45 +0100, "M.-A. Lemburg" writes: > > > >> That said, I don't think it's a good idea to try to reinvent a >> wheel that has already been invented many times over. Just look at >> the successful systems running on e.g. Amazon and eBay. We don't >> really need to go through all the pain they've gone through to >> build successful systems again. >> >> -- >> Marc-Andre Lemburg >> eGenix.com > > I don't think that the Amazon system is successful. I think that > you are confusing two things -- 'people like to rate things' with > 'the rating is meaningful'. I think that the Amazon rating system > satifices people's desire to rate things, but is a detriment to > actually finding a technical book that will help you do what you > want to do. I wouldn't generalize that. I've often found information in those reviews that was otherwise hard to find. My overall experience with the Amazon system is more on the positive side. However, perhaps Amazon is the wrong comparison: their review system focuses on longer comments, whereas the eBay system has a focus on very terse comments. Most users will probably only look at two things: the overall rating figure and the negative comments. The PyPI approach appears to follow the eBay example, or at least the comments I found so far (not that many) go in this direction. > Only fairly detailed reviews can help with that, and > only to the extent that they exclude certain works, leaving you > to review the remainder on your own. > > Why should software be any different? > > Also, remember, amazon makes money no matter whose books are > purchased, But we would rather help people find the best packages > for their purposes, no? I think that a rating system harms this > goal, and therefore we should not do it. I tend to agree. Discussions on newsgroups, user reports in blogs, etc. are far more informative than an eBay style rating system. Perhaps requiring at least 50 words for the comment would help ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 04 2009) >>> 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 lac at openend.se Wed Nov 4 23:27:05 2009 From: lac at openend.se (Laura Creighton) Date: Wed, 04 Nov 2009 23:27:05 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: Message from "M.-A. Lemburg" of "Wed, 04 Nov 2009 21:50:41 +0100." <4AF1E921.5030103@egenix.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> <4AF1C744.7020100@v.loewis.de> <4AF1D269.7000109@egenix.com> <200911041947.nA4JlXPm019071@theraft.openend.se> <4AF1E921.5030103@egenix.com> Message-ID: <200911042227.nA4MR5nS029195@theraft.openend.se> In a message of Wed, 04 Nov 2009 21:50:41 +0100, "M.-A. Lemburg" writes: >Laura Creighton wrote: >I wouldn't generalize that. I've often found information >in those reviews that was otherwise hard to find. >My overall experience with the Amazon system is more on >the positive side. I think that the reviews are worthwhile. It is the *rating* that I think distorts things. >Discussions on newsgroups, user reports in blogs, etc. are >far more informative than an eBay style rating system. > >Perhaps requiring at least 50 words for the comment would >help ;-) Maybe. The thing about an eBay rating is that there are thousands, maybe tens of thousands of people making the rating, and the rating is just about one thing 'this person is trustworthy, i.e. reliably ships things that arrive undamaged and are more or less what I thought I was bidding on'. The people who had a bad experience because they didn't understand what they were buying can be overwhelmed by those who had a good experience -- assuming you do a lot of business you can cancel those bad reports out fairly quickly. This is rather different from 'I wanted to parse some XML and I tried this parser and it didn't work for me'. Why not? Maybe you got a SAX parser and you were looking for a DOM parser, but are still ignorant enough to not know what you ought to be looking for. I think that only detailed descriptions about what you wanted to do and how it did or didn't work for you can be useful for the next potential user of the package. A rating system will only mislead people. And they make it inevitable that people will make comparisons between packages where they ought not to be made. Laura > >-- >Marc-Andre Lemburg >eGenix.com From mal at egenix.com Thu Nov 5 11:32:28 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 05 Nov 2009 11:32:28 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <200911042227.nA4MR5nS029195@theraft.openend.se> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> <4AF1C744.7020100@v.loewis.de> <4AF1D269.7000109@egenix.com> <200911041947.nA4JlXPm019071@theraft.openend.se> <4AF1E921.5030103@egenix.com> <200911042227.nA4MR5nS029195@theraft.openend.se> Message-ID: <4AF2A9BC.4000907@egenix.com> Laura Creighton wrote: > In a message of Wed, 04 Nov 2009 21:50:41 +0100, "M.-A. Lemburg" writes: >> Laura Creighton wrote: > >> I wouldn't generalize that. I've often found information >> in those reviews that was otherwise hard to find. >> My overall experience with the Amazon system is more on >> the positive side. > > I think that the reviews are worthwhile. It is the *rating* that > I think distorts things. > > > >> Discussions on newsgroups, user reports in blogs, etc. are >> far more informative than an eBay style rating system. >> >> Perhaps requiring at least 50 words for the comment would >> help ;-) > > Maybe. The thing about an eBay rating is that there are thousands, > maybe tens of thousands of people making the rating, and the rating is > just about one thing 'this person is trustworthy, i.e. reliably ships > things that arrive undamaged and are more or less what I thought I was > bidding on'. The people who had a bad experience because they didn't > understand what they were buying can be overwhelmed by those who had a > good experience -- assuming you do a lot of business you can cancel > those bad reports out fairly quickly. > > This is rather different from 'I wanted to parse some XML and > I tried this parser and it didn't work for me'. Why not? Maybe > you got a SAX parser and you were looking for a DOM parser, but > are still ignorant enough to not know what you ought to be looking > for. > > I think that only detailed descriptions about what you wanted to > do and how it did or didn't work for you can be useful for the > next potential user of the package. A rating system will only > mislead people. And they make it inevitable that people will > make comparisons between packages where they ought not to be > made. So you are suggesting to keep the comments and remove the rating system ? Wouldn't that lead to the usual tail of comments you see on blog entries instead of encouraging reviews ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 05 2009) >>> 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 lac at openend.se Thu Nov 5 12:33:39 2009 From: lac at openend.se (Laura Creighton) Date: Thu, 05 Nov 2009 12:33:39 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: Message from "M.-A. Lemburg" of "Thu, 05 Nov 2009 11:32:28 +0100." <4AF2A9BC.4000907@egenix.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> <4AF1C744.7020100@v.loewis.de> <4AF1D269.7000109@egenix.com> <200911041947.nA4JlXPm019071@theraft.openend.se> <4AF1E921.5030103@egenix.com> <200911042227.nA4MR5nS029195@theraft.openend.se> <4AF2A9BC.4000907@egenix.com> Message-ID: <200911051133.nA5BXeht017430@theraft.openend.se> In a message of Thu, 05 Nov 2009 11:32:28 +0100, "M.-A. Lemburg" writes: >So you are suggesting to keep the comments and remove the rating >system ? > >Wouldn't that lead to the usual tail of comments you see on >blog entries instead of encouraging reviews ? > >-- >Marc-Andre Lemburg >eGenix.com I think that a rating system is a bad idea, period. I think that the comments feature _could_ be a good idea, if used well, though I think that the design should be reworked if what we want to have is a way to centrally find long reviews of software packages. The thing is, I now believe that this is not Martin van L?wis goal. I think that he wants to make things easier for software downloaders to evaluate software, no matter how unpopular these ideas are with the package creators. I think that this is a bad decision; it is the software creators one should be most concerned with. I don't think that a rating system actually serves the downloaders, and to the extent that it drives away package creators, it actively harms them. There are things we could do -- add more tags for 'how easy is this to install' and 'where do you want discussion of this package to occur' and 'how well maintained is this package'. But I think there is a great need for packages that were written as a one-shot for somebody who needed to solve some particular problem, aren't being maintained, and are very much 'I am releasing this in case somebody else finds it useful'. I often find stuff like this useful, and I fear my supply of such things will dry up if people have to face comments and criticism that they do not want. Laura From mal at egenix.com Fri Nov 6 10:49:09 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 06 Nov 2009 10:49:09 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: <200911051133.nA5BXeht017430@theraft.openend.se> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> <4AF1C744.7020100@v.loewis.de> <4AF1D269.7000109@egenix.com> <200911041947.nA4JlXPm019071@theraft.openend.se> <4AF1E921.5030103@egenix.com> <200911042227.nA4MR5nS029195@theraft.openend.se> <4AF2A9BC.4000907@egenix.com> <200911051133.nA5BXeht017430@theraft.openend.se> Message-ID: <4AF3F115.6080109@egenix.com> Laura Creighton wrote: > In a message of Thu, 05 Nov 2009 11:32:28 +0100, "M.-A. Lemburg" writes: > > >> So you are suggesting to keep the comments and remove the rating >> system ? >> >> Wouldn't that lead to the usual tail of comments you see on >> blog entries instead of encouraging reviews ? >> >> -- >> Marc-Andre Lemburg >> eGenix.com > > I think that a rating system is a bad idea, period. I think that > the comments feature _could_ be a good idea, if used well, though I > think that the design should be reworked if what we want to have > is a way to centrally find long reviews of software packages. > > The thing is, I now believe that this is not Martin van L?wis goal. > I think that he wants to make things easier for software downloaders > to evaluate software, no matter how unpopular these ideas are with > the package creators. While I can't speak for Martin, I don't think he has had any such intentions. The feature was requested on the PyPI tracker and he implemented it. That's all. > I think that this is a bad decision; it is > the software creators one should be most concerned with. I don't > think that a rating system actually serves the downloaders, and to > the extent that it drives away package creators, it actively harms > them. There will certainly be some developers that don't like being rated for things they put on PyPI as a service to the community. Others will probably take it as challenge to get a high rating. Yet others will just not really care. And then you have people who download and install packages via e.g. pip or easy_install and don't get to see all this in the first place. > There are things we could do -- add more tags for 'how easy is this > to install' and 'where do you want discussion of this package to > occur' and 'how well maintained is this package'. But I think there > is a great need for packages that were written as a one-shot for > somebody who needed to solve some particular problem, aren't being > maintained, and are very much 'I am releasing this in case somebody > else finds it useful'. I often find stuff like this useful, and I > fear my supply of such things will dry up if people have to face > comments and criticism that they do not want. I'm not sure. Most of these discussions sound like FUD to me. The only point I'd like to make is that PyPI should not force any such decision on the developers with no way for them to opt-in or opt-out. IMHO, PyPI should offer comments and rating as opt-in possibility for developers who want to use these features. Unless it's possible to reach out to all PyPI developers via email to inform them of enabling the feature by default, it should be disabled per default - it's unfair to enable a controversial feature without their consent. Regarding the rating system itself, my only request is to publicly show the per-user comment ratings (they are currently hidden) in order to get more transparency. For uncommented ratings, an empty entry would be needed in order to achieve the same level of transparency. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 06 2009) >>> 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 lac at openend.se Fri Nov 6 11:58:49 2009 From: lac at openend.se (Laura Creighton) Date: Fri, 06 Nov 2009 11:58:49 +0100 Subject: [Catalog-sig] Package comments In-Reply-To: Message from "M.-A. Lemburg" of "Fri, 06 Nov 2009 10:49:09 +0100." <4AF3F115.6080109@egenix.com> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> <4AF1C744.7020100@v.loewis.de> <4AF1D269.7000109@egenix.com> <200911041947.nA4JlXPm019071@theraft.openend.se> <4AF1E921.5030103@egenix.com> <200911042227.nA4MR5nS029195@theraft.openend.se> <4AF2A9BC.4000907@egenix.com> <200911051133.nA5BXeht017430@theraft.openend.se> <4AF3F115.6080109@egenix.com> Message-ID: <200911061058.nA6Awn9A019472@theraft.openend.se> In a message of Fri, 06 Nov 2009 10:49:09 +0100, "M.-A. Lemburg" writes: >There will certainly be some developers that don't like being >rated for things they put on PyPI as a service to the community. > >Others will probably take it as challenge to get a high rating. Yes, but I consider this to be a _very_ _bad_ _thing_. Competition is only useful if the contests can be made fair. And this is precisely what we cannot guarantee with a rating system. Thus we can expect that many of the packages with higher ratings are quite arguably worse than those with poorer ones. What is worse is that it sets up a way to compare packages when they, themselves, need to be evaluated on their own merits. We could expand the rating system along the lines that Ren? Dudfield outlined as is used in pygame -- we could rank software for ease of install, and completeness of documentation and the like -- establishing categories with strict rules so that we can make sure the competition is fair, but there comes a point where what you want to know is 'how good is this software' -- and the answer is very much one of 'depends on your personal taste' and 'depends on what you want to do'. There isn't any way to get around this. But one of the reasons that these multiple ways to do things can peacefully coexist is that we don't encourage people to go around saying 'my package is better than your package' or 'I have more fans than you do' or even 'the packages I use are better than the other ones'. People in comp.lang.python who want to write glowing recommendations of why you should use X instead of Y have to substantiate why they prefer X to Y, which makes for more informative reading. I think that a rating system will encourage the sort of uncivil behaviour I have seen other places, places where there is too much competition, unfair contests, not enough acceptance of multiple ways to approach a given problem, and where people expect to be spoon-fed simpler answers than their problem admits. By having a rating system, we are saying that a rating system is useful. And I think it is at best useless, and more often very harmful. Laura From pje at telecommunity.com Fri Nov 6 17:11:09 2009 From: pje at telecommunity.com (P.J. Eby) Date: Fri, 06 Nov 2009 11:11:09 -0500 Subject: [Catalog-sig] Package comments In-Reply-To: <200911061058.nA6Awn9A019472@theraft.openend.se> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> <4AF14F7C.3050807@egenix.com> <4AF1C744.7020100@v.loewis.de> <4AF1D269.7000109@egenix.com> <200911041947.nA4JlXPm019071@theraft.openend.se> <4AF1E921.5030103@egenix.com> <200911042227.nA4MR5nS029195@theraft.openend.se> <4AF2A9BC.4000907@egenix.com> <200911051133.nA5BXeht017430@theraft.openend.se> <4AF3F115.6080109@egenix.com> <200911061058.nA6Awn9A019472@theraft.openend.se> Message-ID: <20091106161134.EE13C3A407A@sparrow.telecommunity.com> At 11:58 AM 11/6/2009 +0100, Laura Creighton wrote: >People in comp.lang.python who want to write glowing >recommendations of why you should use X instead of Y have to >substantiate why they prefer X to Y, which makes for more informative >reading. I think that a rating system will encourage the sort of >uncivil behaviour I have seen other places, places where there is too >much competition, unfair contests, not enough acceptance of multiple >ways to approach a given problem, and where people expect to be >spoon-fed simpler answers than their problem admits. > >By having a rating system, we are saying that a rating system is >useful. And I think it is at best useless, and more often very harmful. +1000. (Oops, that's a rating, isn't it? ;-) How's this: I like what you said because you said what I've been wanting to say, better than I've managed to myself.) From chris at simplistix.co.uk Sat Nov 7 02:52:42 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Sat, 07 Nov 2009 01:52:42 +0000 Subject: [Catalog-sig] [Distutils] People want CPAN :-) In-Reply-To: References: Message-ID: <4AF4D2EA.4000102@simplistix.co.uk> This feels like a post relative to the catalog-sig too, or maybe even moreso than distutils-sig... Chris Guido van Rossum wrote: > I just found this comment on my blog. People have told me this in > person too, so I believe it is real pain (even if the solution may be > elusive and the suggested solutions may not work). But I don't know > how to improve the world. Is the work on distutils-sig going to be > enough? Or do we need some other kind of work in addition? Do we need > more than PyPI? > > --Guido > > ---------- Forwarded message ---------- > From: dalloliogm > Date: Fri, Nov 6, 2009 at 8:01 AM > Subject: [Neopythonic] New comment on Python in the Scientific World. > To: gvanrossum at gmail.com > > > dalloliogm has left a new comment on your post "Python in the Scientific World": > > Python is suffering a lot in the scientific word, because it has not a > CPAN-like repository. > > PyPI is fine, but it is still far from the level of CPAN, CRAN, > Bioconductor, etc.. > > Scientists who use programming usually have a lot of different > interests and approaches, therefore it is really difficult to write a > package that can be useful to everyone. > Other programming language like Perl and R have repository-like > structure which enable people to download packages easily, and to > upload new ones and organize them withouth having to worry about > having to integrate them into existing packages. > > This is what is happening to biopython now: it is a monolitic package > that it is supposed to work for any bioinformatic problem; but this is > so general that to accomplish that you would need to add a lot of > dependencies, to numpy, networkx, suds, any kind of library. > However, since easy_install is not as ready yet as the counterparts in > other languages, if the biopython developers add too many > dependencies, nobody will be able to install it properly, and nobody > will use it. > > > > Posted by dalloliogm to Neopythonic at November 6, 2009 8:01 AM > > -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Sat Nov 7 03:00:27 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Sat, 07 Nov 2009 02:00:27 +0000 Subject: [Catalog-sig] Package comments In-Reply-To: <4AF11B7C.2040302@v.loewis.de> References: <4AE758C6.2020201@v.loewis.de> <28D997A6-BD64-4FA9-89CE-1E2D4A572C7D@leidel.info> <4AF06380.9060503@v.loewis.de> <751E7CFF-5A03-40A6-A8E3-8492F4294921@leidel.info> <4AF0A55F.8080901@v.loewis.de> <20091104003946.F29AC3A408C@sparrow.telecommunity.com> <4AF11B7C.2040302@v.loewis.de> Message-ID: <4AF4D4BB.6060909@simplistix.co.uk> Martin v. L?wis wrote: > Hmm. Then why do we need PyPI in the first place, if all people could > learn about the Python packages from the blogs of the package authors? Because, like it or not, PyPI is not the defacto package distribution point for Python. This doesn't really have a lot to do with learning about packages or discovering new packages, but is the most important aspect of PyPI now, from my point of view. cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Sat Nov 7 11:00:17 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Sat, 07 Nov 2009 10:00:17 +0000 Subject: [Catalog-sig] Unsubscribing from comments. Message-ID: <4AF54531.5070202@simplistix.co.uk> Hi, This notification contains no instructions as to how to unsubscribe from receiving notifications. My guess would be that you currently have to delete your comment before you'll stop getting mail, but really, all that should happen is there should be a link in the email to say "stop spamming me", without having to go delete your comment. What do other people think? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -------------- next part -------------- An embedded message was scrubbed... From: PyPI operators Subject: New comment on PIL Date: Wed, 4 Nov 2009 18:45:05 +0000 (GMT) Size: 3162 URL: From exarkun at twistedmatrix.com Sat Nov 7 14:48:33 2009 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Sat, 07 Nov 2009 13:48:33 -0000 Subject: [Catalog-sig] Unsubscribing from comments. In-Reply-To: <4AF54531.5070202@simplistix.co.uk> References: <4AF54531.5070202@simplistix.co.uk> Message-ID: <20091107134833.3229.1835788795.divmod.xquotient.287@localhost.localdomain> On 10:00 am, chris at simplistix.co.uk wrote: >Hi, > >This notification contains no instructions as to how to unsubscribe >from receiving notifications. > >My guess would be that you currently have to delete your comment before >you'll stop getting mail, but really, all that should happen is there >should be a link in the email to say "stop spamming me", without having >to go delete your comment. > >What do other people think? There should definitely be some way to tell PyPI you don't want to be mailed. I'm surprised that it mails comments at all, I don't see any indication of that on the comment form. Perhaps adding a sentence there will help set peoples' expectations (and you could have a checkbox there as well asking whether people want to be emailed followups). Jean-Paul From chrism at plope.com Thu Nov 12 18:04:40 2009 From: chrism at plope.com (Chris McDonough) Date: Thu, 12 Nov 2009 12:04:40 -0500 Subject: [Catalog-sig] adding a trove classifier? Message-ID: <4AFC4028.5080006@plope.com> I hope this is the right place to ask the question, but whom does one petition to add new Trove classifiers? I'd love to be able to have the classifiers "Framework :: BFG" classifier and a "License :: Repoze Public License" added to the PyPI list. Rationale for "Framework :: BFG" repoze.bfg (http://bfg.repoze.org) (shorthand "BFG") is a web framework that has been around about a year and a half now and plugins are being uploaded to PyPI for it: http://pypi.python.org/pypi?%3Aaction=search&term=repoze.bfg&submit=search Rationale for "License :: Repoze Public License" All packages that are in the "repoze.*" namespace are released under this license. There are lots of them now: http://pypi.python.org/pypi?%3Aaction=search&term=repoze&submit=search - C From martin at v.loewis.de Thu Nov 12 23:21:23 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 12 Nov 2009 23:21:23 +0100 Subject: [Catalog-sig] Poll started Message-ID: <4AFC8A63.7080900@v.loewis.de> I just started a poll on the PyPI rating system, at http://pypi.python.org/pypi I'll announce it more widely tomorrow. Regards, Martin From mal at egenix.com Thu Nov 12 23:40:38 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 12 Nov 2009 23:40:38 +0100 Subject: [Catalog-sig] Poll started In-Reply-To: <4AFC8A63.7080900@v.loewis.de> References: <4AFC8A63.7080900@v.loewis.de> Message-ID: <4AFC8EE6.2000507@egenix.com> "Martin v. L?wis" wrote: > I just started a poll on the PyPI rating system, at > > http://pypi.python.org/pypi > > I'll announce it more widely tomorrow. I think the poll is missing an important option: [ ] Allow package owners to disallow comments and/or ratings. But more importantly: how does that voting system work ? I don't see any buttons or checkboxes on the wiki page to which the "public poll" link redirects. I also tried logging in to the wiki. No change... Ah, after logging in to PyPI, I now get to see some choices. Suggested reqording: """ If you want to vote, you need to login to PyPI (on the right). """ Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 12 2009) >>> 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 Thu Nov 12 23:54:24 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 12 Nov 2009 23:54:24 +0100 Subject: [Catalog-sig] Poll started In-Reply-To: <4AFC8EE6.2000507@egenix.com> References: <4AFC8A63.7080900@v.loewis.de> <4AFC8EE6.2000507@egenix.com> Message-ID: <4AFC9220.7050404@v.loewis.de> >> I'll announce it more widely tomorrow. > > I think the poll is missing an important option: > > [ ] Allow package owners to disallow comments and/or ratings. :-( Why didn't you add this to the wiki page in the past days? I actually don't understand the option: what is and/or? > """ > If you want to vote, you need to login to PyPI (on the right). > """ Done! Regards, Martin From mal at egenix.com Fri Nov 13 00:08:01 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 13 Nov 2009 00:08:01 +0100 Subject: [Catalog-sig] Poll started In-Reply-To: <4AFC9220.7050404@v.loewis.de> References: <4AFC8A63.7080900@v.loewis.de> <4AFC8EE6.2000507@egenix.com> <4AFC9220.7050404@v.loewis.de> Message-ID: <4AFC9551.1010909@egenix.com> "Martin v. L?wis" wrote: >>> I'll announce it more widely tomorrow. >> >> I think the poll is missing an important option: >> >> [ ] Allow package owners to disallow comments and/or ratings. > > :-( Why didn't you add this to the wiki page in the past days? Sorry about that: Last time I looked on that page the voting section wasn't there yet. > I actually don't understand the option: what is and/or? Package owners should get two checkboxes: [ ] Allow comments [ ] Allow ratings That's about as open as it can get. The only question left then is what to use as default. >> """ >> If you want to vote, you need to login to PyPI (on the right). >> """ > > Done! Thanks. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 13 2009) >>> 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 Fri Nov 13 00:14:04 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 13 Nov 2009 00:14:04 +0100 Subject: [Catalog-sig] Poll started In-Reply-To: <4AFC9551.1010909@egenix.com> References: <4AFC8A63.7080900@v.loewis.de> <4AFC8EE6.2000507@egenix.com> <4AFC9220.7050404@v.loewis.de> <4AFC9551.1010909@egenix.com> Message-ID: <4AFC96BC.7080305@v.loewis.de> M.-A. Lemburg wrote: > "Martin v. L?wis" wrote: >>>> I'll announce it more widely tomorrow. >>> I think the poll is missing an important option: >>> >>> [ ] Allow package owners to disallow comments and/or ratings. >> :-( Why didn't you add this to the wiki page in the past days? > > Sorry about that: Last time I looked on that page the voting section > wasn't there yet. > >> I actually don't understand the option: what is and/or? > > Package owners should get two checkboxes: > > [ ] Allow comments > [ ] Allow ratings > > That's about as open as it can get. The only question left then > is what to use as default. I think it's too late now, now that the poll has started. Also, I didn't hear anybody say that they wanted to opt out of ratings - people opposed to ratings always wanted to turn ratings off entirely, as they felt it was a useless way of communicating, or not appropriate for PyPI, etc. Regards, Martin From lac at openend.se Fri Nov 13 00:29:56 2009 From: lac at openend.se (Laura Creighton) Date: Fri, 13 Nov 2009 00:29:56 +0100 Subject: [Catalog-sig] Poll started In-Reply-To: Message from =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= of "Thu, 12 Nov 2009 23:21:23 +0100." <4AFC8A63.7080900@v.loewis.de> References: <4AFC8A63.7080900@v.loewis.de> Message-ID: <200911122329.nACNTuSt029762@theraft.openend.se> In a message of Thu, 12 Nov 2009 23:21:23 +0100, "Martin v. L?wis" writes: >I just started a poll on the PyPI rating system, at > >http://pypi.python.org/pypi > >I'll announce it more widely tomorrow. > >Regards, >Martin Your poll shouldn't have been made with radio buttons. What one feels about ratings is independent of what you feel about comments. It skips the choice that I have been arguing for all along: Allow package owners to disallow comments and Disallow ratings Laura From martin at v.loewis.de Fri Nov 13 00:39:10 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 13 Nov 2009 00:39:10 +0100 Subject: [Catalog-sig] Poll started In-Reply-To: <200911122329.nACNTuSt029762@theraft.openend.se> References: <4AFC8A63.7080900@v.loewis.de> <200911122329.nACNTuSt029762@theraft.openend.se> Message-ID: <4AFC9C9E.5050700@v.loewis.de> > Your poll shouldn't have been made with radio buttons. What one feels > about ratings is independent of what you feel about comments. It skips > the choice that I have been arguing for all along: > > Allow package owners to disallow comments > and > Disallow ratings I can only say that this comes a little late, when the set of choices had already been discussed. Regards, Martin From ianb at colorstudy.com Fri Nov 13 02:33:27 2009 From: ianb at colorstudy.com (Ian Bicking) Date: Thu, 12 Nov 2009 20:33:27 -0500 Subject: [Catalog-sig] [Python-Dev] PyPI front page In-Reply-To: References: <4AFC9064.20700@v.loewis.de> <4222a8490911121511s40eba937n2c7b1fde6f695c6c@mail.gmail.com> <4AFC9975.7040204@v.loewis.de> <4222a8490911121534h30572eabv73ae58649c77155c@mail.gmail.com> <4AFC9D0C.5030500@v.loewis.de> <87y6mbuubp.fsf@benfinney.id.au> Message-ID: On Thu, Nov 12, 2009 at 7:52 PM, Antoine Pitrou wrote: > Ben Finney benfinney.id.au> writes: > > > > There's a problem with the poll's placement: on the front page of the > > PyPI website. > > Speaking of which, why is it that http://pypi.python.org/pypi and > http://pypi.python.org/pypi/ (note the ending slash) return different > contents > (the latter being very voluminous)? I always mistake one for the other when > entering the URL directly. > easy_install replied on the behavior of /pypi/ (it uses the long list to do case-insensitive searches). Someone changed it, easy_install broke, and a compromise was to keep /pypi/ the way it was (but not /pypi). Probably this could be removed, as the /simple/ index is already case-insensitive, so easy_install shouldn't have to hit /pypi/ at all. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker -------------- next part -------------- An HTML attachment was scrubbed... URL: From ubernostrum at gmail.com Fri Nov 13 08:49:00 2009 From: ubernostrum at gmail.com (James Bennett) Date: Fri, 13 Nov 2009 01:49:00 -0600 Subject: [Catalog-sig] adding a trove classifier? In-Reply-To: <4AFC4028.5080006@plope.com> References: <4AFC4028.5080006@plope.com> Message-ID: <21787a9f0911122349u693cc5c7l898342d53a46549e@mail.gmail.com> On Thu, Nov 12, 2009 at 11:04 AM, Chris McDonough wrote: > I'd love to be able to have the classifiers "Framework :: BFG" classifier > and a "License :: Repoze Public License" added to the PyPI list. (+1 to both) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." From ubernostrum at gmail.com Fri Nov 13 08:52:59 2009 From: ubernostrum at gmail.com (James Bennett) Date: Fri, 13 Nov 2009 01:52:59 -0600 Subject: [Catalog-sig] [Distutils] People want CPAN :-) In-Reply-To: <4AF4D2EA.4000102@simplistix.co.uk> References: <4AF4D2EA.4000102@simplistix.co.uk> Message-ID: <21787a9f0911122352n65a2ee26q917f5297def58110@mail.gmail.com> On Fri, Nov 6, 2009 at 7:52 PM, Chris Withers wrote: > This feels like a post relative to the catalog-sig too, or maybe even moreso > than distutils-sig... The question that's on my mind here, and which I haven't really seen a solid answer to in the various threads, is which parts of CPAN people seem to want. The original post mainly seemed to be concerned with saying "install this" and having it automagically work, dependencies and all, which is much less a PyPI issue and much more a "sort out the packaging and installation tools" issue than a PyPI issue. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." From lac at openend.se Fri Nov 13 15:07:18 2009 From: lac at openend.se (Laura Creighton) Date: Fri, 13 Nov 2009 15:07:18 +0100 Subject: [Catalog-sig] [Distutils] People want CPAN :-) In-Reply-To: Message from James Bennett of "Fri, 13 Nov 2009 01:52:59 CST." <21787a9f0911122352n65a2ee26q917f5297def58110@mail.gmail.com> References: <4AF4D2EA.4000102@simplistix.co.uk> <21787a9f0911122352n65a2ee26q917f5297def58110@mail.gmail.com> Message-ID: <200911131407.nADE7IPi010054@theraft.openend.se> In a message of Fri, 13 Nov 2009 01:52:59 CST, James Bennett writes: >On Fri, Nov 6, 2009 at 7:52 PM, Chris Withers wr >ote: >> This feels like a post relative to the catalog-sig too, or maybe even m >oreso >> than distutils-sig... > >The question that's on my mind here, and which I haven't really seen a >solid answer to in the various threads, is which parts of CPAN people >seem to want. The original post mainly seemed to be concerned with >saying "install this" and having it automagically work, dependencies >and all, which is much less a PyPI issue and much more a "sort out the >packaging and installation tools" issue than a PyPI issue. My impression is that he wants for BioPython a distribution such as enthought makes for NumPy. Laura From chris at simplistix.co.uk Fri Nov 13 17:20:23 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Fri, 13 Nov 2009 16:20:23 +0000 Subject: [Catalog-sig] Poll started In-Reply-To: <4AFC8A63.7080900@v.loewis.de> References: <4AFC8A63.7080900@v.loewis.de> Message-ID: <4AFD8747.6010002@simplistix.co.uk> Martin v. L?wis wrote: > I just started a poll on the PyPI rating system, at > > http://pypi.python.org/pypi > > I'll announce it more widely tomorrow. I do have a slight problem with the wording of this... "Allow ratings and comments on all packages (status quo)" ...isn't exactly what you mean. This option should really be labelled: "Force package authors to accept ratings and comments on all packages (status quo)" Likewise, the second option could be more neutrally worded as: "Allow package authors to choose whether or not their packages accept comments" ...rather than phrasing it as a negative. I could also niggle that the options effectively split the group of people who don't want mandatory comments and ratings in two by giving them two different options which meet their needs, but I hope those two groups will be taken into account afterwards. Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From mal at egenix.com Fri Nov 13 19:28:33 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 13 Nov 2009 19:28:33 +0100 Subject: [Catalog-sig] Poll started In-Reply-To: <4AFC96BC.7080305@v.loewis.de> References: <4AFC8A63.7080900@v.loewis.de> <4AFC8EE6.2000507@egenix.com> <4AFC9220.7050404@v.loewis.de> <4AFC9551.1010909@egenix.com> <4AFC96BC.7080305@v.loewis.de> Message-ID: <4AFDA551.4030100@egenix.com> "Martin v. L?wis" wrote: > M.-A. Lemburg wrote: >> "Martin v. L?wis" wrote: >>>>> I'll announce it more widely tomorrow. >>>> I think the poll is missing an important option: >>>> >>>> [ ] Allow package owners to disallow comments and/or ratings. >>> :-( Why didn't you add this to the wiki page in the past days? >> >> Sorry about that: Last time I looked on that page the voting section >> wasn't there yet. >> >>> I actually don't understand the option: what is and/or? >> >> Package owners should get two checkboxes: >> >> [ ] Allow comments >> [ ] Allow ratings >> >> That's about as open as it can get. The only question left then >> is what to use as default. > > I think it's too late now, now that the poll has started. It's just a poll to get a feeling for user sentiments, not a vote of any kind. Even as poll it will be difficult to interpret the responses to guide the development. These are the current figures: """ Allow ratings and comments on all packages (status quo) 76 Allow package owners to disallow comments (ratings unmodified). 67 Allow comments, but only send them to package owners (ratings unmodified). 18 Disallow comments (ratings unmodified). 15 Disallow ratings and comments (status three months ago). 68 """ Now let's say you leave the current implementation in place. This would mean that you satisfy the user feelings of 76 users, but also means that you don't respect the answers of 168 users - even though the poll makes it look like keeping the status quo is getting a slight majority. > Also, I didn't hear anybody say that they wanted to opt out of > ratings - people opposed to ratings always wanted to turn ratings > off entirely, as they felt it was a useless way of communicating, > or not appropriate for PyPI, etc. I think the best way to handle all this is by giving the package authors the choice of whether to accept ratings or comments as two separate check-boxes. If you then use the status of three months ago as default (ie. rating and comments are turned off by default), you'd avoid all the controversy these features have caused. It's also a good idea to provide a check-box to disable sending out emails to the authors for comments. And if you want to make the users who answered "Allow comments, but only send them to package owners" happy, also add an option to keep comments private. That said, I still believe that PyPI should stay the neutral place for uploading packages. We already have enough controversy trying to sort out the whole package installation story. IMHO, it's not really useful to open up another can of worms right now. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 13 2009) >>> 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 chris at simplistix.co.uk Sat Nov 14 01:34:22 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Sat, 14 Nov 2009 00:34:22 +0000 Subject: [Catalog-sig] Poll Problem In-Reply-To: <4AFC8A63.7080900@v.loewis.de> References: <4AFC8A63.7080900@v.loewis.de> Message-ID: <4AFDFB0E.1090309@simplistix.co.uk> Martin v. L?wis wrote: > I just started a poll on the PyPI rating system, at > > http://pypi.python.org/pypi > > I'll announce it more widely tomorrow. Just so you're aware, there's some opportunity for ballot stuffing given that each OpenID provider a user has access allows them one vote, as well as the vote they have if they actually create a username/password on PyPI. So, each person can, in theory, vote up to 4 times. As a corollary of that, I an also tell you that the myopenid provider is currently broken. On the bounce back from the MyOpenID site, you get the following from PyPI: "OpenID provider did not provide your email address" MyOpenID certainly do have an email address for me ;-) There's also the issue that, of course, people can register with multiple email addresses and stuff the ballot that way even more successfully too... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From martin at v.loewis.de Sat Nov 14 10:47:35 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 14 Nov 2009 10:47:35 +0100 Subject: [Catalog-sig] Poll Problem In-Reply-To: <4AFDFB0E.1090309@simplistix.co.uk> References: <4AFC8A63.7080900@v.loewis.de> <4AFDFB0E.1090309@simplistix.co.uk> Message-ID: <4AFE7CB7.7050804@v.loewis.de> Chris Withers wrote: > Martin v. L?wis wrote: >> I just started a poll on the PyPI rating system, at >> >> http://pypi.python.org/pypi >> >> I'll announce it more widely tomorrow. > > Just so you're aware, there's some opportunity for ballot stuffing given > that each OpenID provider a user has access allows them one vote, as > well as the vote they have if they actually create a username/password > on PyPI. So, each person can, in theory, vote up to 4 times. Thanks, I was aware of that (and have additional measures in place to detect it, which can in turn be subverted if you try enough). Please don't advertise that too widely. Regards, Martin From martin at v.loewis.de Sat Nov 14 11:16:27 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 14 Nov 2009 11:16:27 +0100 Subject: [Catalog-sig] Poll Problem In-Reply-To: <4AFDFB0E.1090309@simplistix.co.uk> References: <4AFC8A63.7080900@v.loewis.de> <4AFDFB0E.1090309@simplistix.co.uk> Message-ID: <4AFE837B.3090606@v.loewis.de> > Just so you're aware, there's some opportunity for ballot stuffing given > that each OpenID provider a user has access allows them one vote, as > well as the vote they have if they actually create a username/password > on PyPI. So, each person can, in theory, vote up to 4 times. Re-checking this: what I really find disturbing is that you participate yourself in ballot stuffing, with at least four accounts. Please let me know (in private) which of these accounts I should delete. Thanks, Martin From chris at simplistix.co.uk Sat Nov 14 13:19:24 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Sat, 14 Nov 2009 12:19:24 +0000 Subject: [Catalog-sig] Poll Problem In-Reply-To: <4AFE837B.3090606@v.loewis.de> References: <4AFC8A63.7080900@v.loewis.de> <4AFDFB0E.1090309@simplistix.co.uk> <4AFE837B.3090606@v.loewis.de> Message-ID: <4AFEA04C.905@simplistix.co.uk> Martin v. L?wis wrote: >> Just so you're aware, there's some opportunity for ballot stuffing given >> that each OpenID provider a user has access allows them one vote, as >> well as the vote they have if they actually create a username/password >> on PyPI. So, each person can, in theory, vote up to 4 times. > > Re-checking this: what I really find disturbing is that you participate > yourself in ballot stuffing, with at least four accounts. Please let me > know (in private) which of these accounts I should delete. I was just testing them, I could find no way to undo the votes. I use all of the accounts, so please don't delete them (I guess you'd actually have to block them, since you certainly can't delete my accounts elsewhere). But yes, if you have a way, please reduce my votes to one ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From martin at v.loewis.de Sat Nov 14 13:37:42 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 14 Nov 2009 13:37:42 +0100 Subject: [Catalog-sig] Poll Problem In-Reply-To: <4AFEA04C.905@simplistix.co.uk> References: <4AFC8A63.7080900@v.loewis.de> <4AFDFB0E.1090309@simplistix.co.uk> <4AFE837B.3090606@v.loewis.de> <4AFEA04C.905@simplistix.co.uk> Message-ID: <4AFEA496.902@v.loewis.de> >> Re-checking this: what I really find disturbing is that you participate >> yourself in ballot stuffing, with at least four accounts. Please let me >> know (in private) which of these accounts I should delete. > > I was just testing them, I could find no way to undo the votes. Hmm. And you needed to cast four votes to perform this testing? > I use all of the accounts, so please don't delete them (I guess you'd > actually have to block them, since you certainly can't delete my > accounts elsewhere). > > But yes, if you have a way, please reduce my votes to one ;-) Done! Let me know if whether I missed any accounts, and revote if I indeed found them all. Martin From martin at v.loewis.de Sat Nov 14 14:22:22 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 14 Nov 2009 14:22:22 +0100 Subject: [Catalog-sig] [Python-Dev] PyPI comments and ratings, *really*? In-Reply-To: <20091114131813.GA3798@kinakuta.local> References: <200911130038.05516.steve@pearwood.info> <7EAD464A-45AC-41EF-9E11-A9BAA3461DB9@lericson.se> <200911131722.38598.steve@pearwood.info> <87aayqvrif.fsf@benfinney.id.au> <20091113101906.GA3246@kinakuta.local> <4AFE6DC6.60308@v.loewis.de> <20091114131813.GA3798@kinakuta.local> Message-ID: <4AFEAF0E.1040808@v.loewis.de> > >> That is an (apparently widespread) myth. The Cheesecake rating is not >> considered in ranking search results; it's just the relevance of the >> search term that is. > > Thanks for clarifying this! > > What about the other points? They are really off-topic for python-dev; PyPI discussion should take place on catalog-sig. I personally had problems following your message, as it seemed to mix too many aspects into one message. Regards, Martin From chris at simplistix.co.uk Sat Nov 14 14:37:31 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Sat, 14 Nov 2009 13:37:31 +0000 Subject: [Catalog-sig] Poll Problem In-Reply-To: <4AFEA496.902@v.loewis.de> References: <4AFC8A63.7080900@v.loewis.de> <4AFDFB0E.1090309@simplistix.co.uk> <4AFE837B.3090606@v.loewis.de> <4AFEA04C.905@simplistix.co.uk> <4AFEA496.902@v.loewis.de> Message-ID: <4AFEB29B.3020402@simplistix.co.uk> Martin v. L?wis wrote: >>> Re-checking this: what I really find disturbing is that you participate >>> yourself in ballot stuffing, with at least four accounts. Please let me >>> know (in private) which of these accounts I should delete. >> I was just testing them, I could find no way to undo the votes. > > Hmm. And you needed to cast four votes to perform this testing? Be careful, your implication is close to being pretty offensive. Had I wanted to game the system, I wouldn't have reported the problem, I would have just let everyone who's likely to vote the same way as me know and kept quiet. >> But yes, if you have a way, please reduce my votes to one ;-) > > Done! Let me know if whether I missed any accounts, and revote if I > indeed found them all. Can you please document here what you've done to ensure there are no duplicate votes from other people who really are trying to stuff the ballot? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From wentland at cl.uni-heidelberg.de Sat Nov 14 14:18:13 2009 From: wentland at cl.uni-heidelberg.de (Wolodja Wentland) Date: Sat, 14 Nov 2009 14:18:13 +0100 Subject: [Catalog-sig] [Python-Dev] PyPI comments and ratings, *really*? In-Reply-To: <4AFE6DC6.60308@v.loewis.de> References: <200911130038.05516.steve@pearwood.info> <7EAD464A-45AC-41EF-9E11-A9BAA3461DB9@lericson.se> <200911131722.38598.steve@pearwood.info> <87aayqvrif.fsf@benfinney.id.au> <20091113101906.GA3246@kinakuta.local> <4AFE6DC6.60308@v.loewis.de> Message-ID: <20091114131813.GA3798@kinakuta.local> On Sat, Nov 14, 2009 at 09:43 +0100, "Martin v. L?wis" wrote: > > What I really like on PyPi is that my packages are tested automatically > > with Cheesecake and the order of packages when searching is determined > > by this rating. > That is an (apparently widespread) myth. The Cheesecake rating is not > considered in ranking search results; it's just the relevance of the > search term that is. Thanks for clarifying this! What about the other points? Crossposted to catalog-sig to move the discussion there. -- .''`. Wolodja Wentland : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From pje at telecommunity.com Sat Nov 14 15:39:24 2009 From: pje at telecommunity.com (P.J. Eby) Date: Sat, 14 Nov 2009 09:39:24 -0500 Subject: [Catalog-sig] [Python-Dev] PyPI front page In-Reply-To: References: <4AFC9064.20700@v.loewis.de> <4222a8490911121511s40eba937n2c7b1fde6f695c6c@mail.gmail.com> <4AFC9975.7040204@v.loewis.de> <4222a8490911121534h30572eabv73ae58649c77155c@mail.gmail.com> <4AFC9D0C.5030500@v.loewis.de> <87y6mbuubp.fsf@benfinney.id.au> Message-ID: <20091114143931.507E33A411A@sparrow.telecommunity.com> At 08:33 PM 11/12/2009 -0500, Ian Bicking wrote: >On Thu, Nov 12, 2009 at 7:52 PM, Antoine Pitrou ><solipsis at pitrou.net> wrote: >Ben Finney benfinney.id.au> writes: > > > > There's a problem with the poll's placement: on the front page of the > > PyPI website. > >Speaking of which, why is it that >http://pypi.python.org/pypi and >http://pypi.python.org/pypi/ (note the >ending slash) return different contents >(the latter being very voluminous)? I always mistake one for the other when >entering the URL directly. > > >easy_install replied on the behavior of /pypi/ (it uses the long >list to do case-insensitive searches).? Someone changed it, >easy_install broke, and a compromise was to keep /pypi/ the way it >was (but not /pypi). > >Probably this could be removed, as the /simple/ index is already >case-insensitive, so easy_install shouldn't have to hit /pypi/ at all. This was changed over a year ago; easy_install *does* use /simple by default. I would guess enough people are upgraded by now that PyPI need no longer continue to support it. From martin at v.loewis.de Sat Nov 14 16:16:39 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 14 Nov 2009 16:16:39 +0100 Subject: [Catalog-sig] [Python-Dev] PyPI front page In-Reply-To: <20091114143931.507E33A411A@sparrow.telecommunity.com> References: <4AFC9064.20700@v.loewis.de> <4222a8490911121511s40eba937n2c7b1fde6f695c6c@mail.gmail.com> <4AFC9975.7040204@v.loewis.de> <4222a8490911121534h30572eabv73ae58649c77155c@mail.gmail.com> <4AFC9D0C.5030500@v.loewis.de> <87y6mbuubp.fsf@benfinney.id.au> <20091114143931.507E33A411A@sparrow.telecommunity.com> Message-ID: <4AFEC9D7.7060009@v.loewis.de> > > This was changed over a year ago; easy_install *does* use /simple by > default. I would guess enough people are upgraded by now that PyPI need > no longer continue to support it. What was the first version that defaulted to /simple? I still see many users using 0.6c5. The oldest version that still had more than 100 accesses in November was 0.6c2 (used together with Python 2.1, 2.4, and 2.6). Do you have a feeling what "enough people" would be? Regards, Martin From chris at simplistix.co.uk Sat Nov 14 16:34:28 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Sat, 14 Nov 2009 15:34:28 +0000 Subject: [Catalog-sig] Gaming the PyPI vote In-Reply-To: <200911150225.55412.steve@pearwood.info> References: <4AFE6E10.3050307@v.loewis.de> <20091114145222.084583A411A@sparrow.telecommunity.com> <200911150225.55412.steve@pearwood.info> Message-ID: <4AFECE04.9010603@simplistix.co.uk> Steven D'Aprano wrote: > Not bizarre at all, practical. Without authenticated votes, gaming the > system goes from technically challenging to simple enough anyone can do > it. Yes, registering multiple email email addresses at gmail/hotmail/yahoo/etc and knowing how to clear cookies on your browser is very technically challenging ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Sat Nov 14 16:37:51 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Sat, 14 Nov 2009 15:37:51 +0000 Subject: [Catalog-sig] PyPI comments and ratings, *really*? In-Reply-To: <4AFC9C2C.9090408@v.loewis.de> References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> Message-ID: <4AFECECF.6080301@simplistix.co.uk> Martin v. L?wis wrote: >> Users (which includes e.g. language users) tend to be lazy, rather than stupid. > > Then they likely won't comment on PyPI. To do so, they have to setup an > account (which most don't have). They can't post comments without an > account. You're forgetting the two working single sign on methods. I'd be surprised if a developer didn't have at least one google account or a launchpad account. Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From pje at telecommunity.com Sat Nov 14 16:52:55 2009 From: pje at telecommunity.com (P.J. Eby) Date: Sat, 14 Nov 2009 10:52:55 -0500 Subject: [Catalog-sig] [Python-Dev] PyPI front page In-Reply-To: <4AFEC9D7.7060009@v.loewis.de> References: <4AFC9064.20700@v.loewis.de> <4222a8490911121511s40eba937n2c7b1fde6f695c6c@mail.gmail.com> <4AFC9975.7040204@v.loewis.de> <4222a8490911121534h30572eabv73ae58649c77155c@mail.gmail.com> <4AFC9D0C.5030500@v.loewis.de> <87y6mbuubp.fsf@benfinney.id.au> <20091114143931.507E33A411A@sparrow.telecommunity.com> <4AFEC9D7.7060009@v.loewis.de> Message-ID: <20091114155257.2CB0F3A411A@sparrow.telecommunity.com> At 04:16 PM 11/14/2009 +0100, Martin v. L?wis wrote: > > > > This was changed over a year ago; easy_install *does* use /simple by > > default. I would guess enough people are upgraded by now that PyPI need > > no longer continue to support it. > >What was the first version that defaulted to /simple? I still see many >users using 0.6c5. The oldest version that still had more than 100 >accesses in November was 0.6c2 (used together with Python 2.1, 2.4, and >2.6). Do you have a feeling what "enough people" would be? Ouch. 0.6c9 is over a year old, so 0.6c5 is quite ancient. Checking the revision history, 0.6c7 changed the default URL to use the /simple index, and 0.6b4 added support for 'rel' link handling. That means that any requests from a "setuptools" user-agent (that string was added in 0.6c1) should be safe to rewrite (not redirect, alas) as /simple/ when they request /pypi/. Any agents older than 0.6c1, however, can't even be detected. Do you have any stats on hits by "python urllib" user agents to the /pypi/ page? My guess is that these will all actually be pre-0.6c1 setuptools instances. From martin at v.loewis.de Sat Nov 14 17:43:59 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 14 Nov 2009 17:43:59 +0100 Subject: [Catalog-sig] [Python-Dev] PyPI front page In-Reply-To: <20091114155257.2CB0F3A411A@sparrow.telecommunity.com> References: <4AFC9064.20700@v.loewis.de> <4222a8490911121511s40eba937n2c7b1fde6f695c6c@mail.gmail.com> <4AFC9975.7040204@v.loewis.de> <4222a8490911121534h30572eabv73ae58649c77155c@mail.gmail.com> <4AFC9D0C.5030500@v.loewis.de> <87y6mbuubp.fsf@benfinney.id.au> <20091114143931.507E33A411A@sparrow.telecommunity.com> <4AFEC9D7.7060009@v.loewis.de> <20091114155257.2CB0F3A411A@sparrow.telecommunity.com> Message-ID: <4AFEDE4F.1070203@v.loewis.de> > Do you have any stats on hits by "python urllib" user agents to the > /pypi/ page? My guess is that these will all actually be pre-0.6c1 > setuptools instances. You can browse the stats at http://pypi.python.org/webstats/ October's user agents are at http://pypi.python.org/webstats/agent_200910.html Wrt. pypi/: rather than doing UA-based rewrites, I'd prefer to wait more time for people to upgrade their software. Regards, Martin From mal at egenix.com Sat Nov 14 20:15:33 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Sat, 14 Nov 2009 20:15:33 +0100 Subject: [Catalog-sig] Poll Problem In-Reply-To: <4AFEB29B.3020402@simplistix.co.uk> References: <4AFC8A63.7080900@v.loewis.de> <4AFDFB0E.1090309@simplistix.co.uk> <4AFE837B.3090606@v.loewis.de> <4AFEA04C.905@simplistix.co.uk> <4AFEA496.902@v.loewis.de> <4AFEB29B.3020402@simplistix.co.uk> Message-ID: <4AFF01D5.4000009@egenix.com> Chris Withers wrote: > Martin v. L?wis wrote: >>> But yes, if you have a way, please reduce my votes to one ;-) >> >> Done! Let me know if whether I missed any accounts, and revote if I >> indeed found them all. > > Can you please document here what you've done to ensure there are no > duplicate votes from other people who really are trying to stuff the > ballot? I think there's a misunderstanding here: the poll is not an official vote on the future of the PyPI comment and rating system, it's just a market research method to get at least some rough idea of what users (with PyPI accounts) want. Nothing more. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 14 2009) >>> 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 pje at telecommunity.com Sat Nov 14 21:50:11 2009 From: pje at telecommunity.com (P.J. Eby) Date: Sat, 14 Nov 2009 15:50:11 -0500 Subject: [Catalog-sig] Poll Problem In-Reply-To: <4AFF01D5.4000009@egenix.com> References: <4AFC8A63.7080900@v.loewis.de> <4AFDFB0E.1090309@simplistix.co.uk> <4AFE837B.3090606@v.loewis.de> <4AFEA04C.905@simplistix.co.uk> <4AFEA496.902@v.loewis.de> <4AFEB29B.3020402@simplistix.co.uk> <4AFF01D5.4000009@egenix.com> Message-ID: <20091114205013.C12043A4092@sparrow.telecommunity.com> At 08:15 PM 11/14/2009 +0100, M.-A. Lemburg wrote: >Chris Withers wrote: > > Martin v. L?wis wrote: > >>> But yes, if you have a way, please reduce my votes to one ;-) > >> > >> Done! Let me know if whether I missed any accounts, and revote if I > >> indeed found them all. > > > > Can you please document here what you've done to ensure there are no > > duplicate votes from other people who really are trying to stuff the > > ballot? > >I think there's a misunderstanding here: the poll is not an official >vote on the future of the PyPI comment and rating system, it's >just a market research method to get at least some rough idea of >what users (with PyPI accounts) want. Nothing more. Then why does the poll page itself say that "The option that receives most votes will be implemented"? From mal at egenix.com Sun Nov 15 00:04:01 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Sun, 15 Nov 2009 00:04:01 +0100 Subject: [Catalog-sig] Poll Problem In-Reply-To: <20091114205013.C12043A4092@sparrow.telecommunity.com> References: <4AFC8A63.7080900@v.loewis.de> <4AFDFB0E.1090309@simplistix.co.uk> <4AFE837B.3090606@v.loewis.de> <4AFEA04C.905@simplistix.co.uk> <4AFEA496.902@v.loewis.de> <4AFEB29B.3020402@simplistix.co.uk> <4AFF01D5.4000009@egenix.com> <20091114205013.C12043A4092@sparrow.telecommunity.com> Message-ID: <4AFF3761.1090303@egenix.com> P.J. Eby wrote: > At 08:15 PM 11/14/2009 +0100, M.-A. Lemburg wrote: >> Chris Withers wrote: >> > Martin v. L?wis wrote: >> >>> But yes, if you have a way, please reduce my votes to one ;-) >> >> >> >> Done! Let me know if whether I missed any accounts, and revote if I >> >> indeed found them all. >> > >> > Can you please document here what you've done to ensure there are no >> > duplicate votes from other people who really are trying to stuff the >> > ballot? >> >> I think there's a misunderstanding here: the poll is not an official >> vote on the future of the PyPI comment and rating system, it's >> just a market research method to get at least some rough idea of >> what users (with PyPI accounts) want. Nothing more. > > Then why does the poll page itself say that "The option that receives > most votes will be implemented"? Good question. I think that's a documentation bug :-) The wiki page uses a much better description (http://wiki.python.org/moin/PyPIComments): """ There is a public poll running to determine what users think of the rating and commenting features. """ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 14 2009) >>> 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 tjreedy at udel.edu Sun Nov 15 20:27:11 2009 From: tjreedy at udel.edu (Terry Reedy) Date: Sun, 15 Nov 2009 14:27:11 -0500 Subject: [Catalog-sig] Rating feature In-Reply-To: References: <4AB145CD.900@v.loewis.de> <4AB15780.7070309@simplistix.co.uk> <4AB158BB.9000302@simplistix.co.uk> Message-ID: Sridhar Ratnakumar wrote: > > Yes. If PyPI is going to have release-specific ratings, I suggest that > each PyPI page (distname-version) show two rating bars: > > a) release rating (logged-in user editable) > b) overall rating (averaged from all release ratings) I would make the second an average over all past releases I would also suggest making it a so-called exponentially weighted average. Assume that past ratings are frozen and the individual votes tossed, the update when a new release arrives would be something like past = .8 * past + .2 * current # adjust weights to taste current = This way, a blunder release, once corrected, would have limited effect on the overall average and its effect would disappear with time. From ben+python at benfinney.id.au Sun Nov 15 22:46:21 2009 From: ben+python at benfinney.id.au (Ben Finney) Date: Mon, 16 Nov 2009 08:46:21 +1100 Subject: [Catalog-sig] OpenID login to PyPI (was: PyPI comments and ratings, *really*?) References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> Message-ID: <87zl6npiky.fsf_-_@benfinney.id.au> Chris Withers writes: > You're forgetting the two working single sign on methods. I'd be > surprised if a developer didn't have at least one google account or a > launchpad account. I'm happy to surprise you: I am a Python developer, a PyPI user, and I have neither a Google account nor a Launchpad account. There's been a rather fragmented discussion (with some messages in ?python-dev?, some in private email) that I'd like to summarise here: PyPI currently uses OpenID, but defeats much of the point of that system by skipping important parts of the authentication protocol and disallowing all but a small subset of identifiers (those that are within a small set of domains). Some of us, who have OpenIDs that *aren't* in any big-name domain but want to use them to authenticate, are discussing this with PyPI administration (Martin von L?wis) and making great strides in clearing up misunderstandings. I have confidence that this is leading in a good direction, but it's clear this should be happening here on the ?catalog-sig? forum. I'll post some representative messages in this thread, and encourage further discussion of the issue here. But first, I need to take this opportunity to publically thank Martin for being very patient over many messages and honestly working to understand our requests. It's Martin's demonstrated desire to figure out how to meet PyPI users's needs that is the basis of my confidence that this will have a happy ending. -- \ ?Pinky, are you pondering what I'm pondering?? ?I think so, | `\ Brain, but shouldn't the bat boy be wearing a cape?? ?_Pinky | _o__) and The Brain_ | Ben Finney From ben+python at benfinney.id.au Sun Nov 15 23:06:48 2009 From: ben+python at benfinney.id.au (Ben Finney) Date: Mon, 16 Nov 2009 09:06:48 +1100 Subject: [Catalog-sig] OpenID login to PyPI References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> Message-ID: <87r5rzphmv.fsf@benfinney.id.au> Ben Finney writes: > PyPI currently uses OpenID, but defeats much of the point of that > system by skipping important parts of the authentication protocol and > disallowing all but a small subset of identifiers (those that are > within a small set of domains). Here's a blow-by-blow. If you're just an OpenID user, you don't need to know *any* of this; it's targeted at Martin, as someone *implementing* OpenID (on PyPI, as an OpenID Relying Party). But it will likely be of interest to those who want to know the details of what we're asking PyPI to do. On 15-Nov-2009, "Martin v. L?wis" wrote: > > Well, when I login my registered ID is www.voidspace.org.uk and > > *not* fuzzyman.myopenid.com - so I believe you are incorrect (and > > in fact this very point was touted as one of the advantages of > > openid - that your account is independent of your provider and > > that you *can* change provider whilst retaining the same id). > > On the wire (between relying party and provider), > voidspace.org.co.uk does never appear. That's because ?between relying party and provider? is already in the middle of the procedure: you've glossed over several steps. The first step, Initiation, is when the relying party asks the user ?what is your OpenID?? with a form field named ?openid_identifier? . Michael's browser can recognise the field by that name and populate it automatically, or he can type in ?voidspace.org.uk? himself and submit the form. The provider is unknown at this point. Then, the relying party performs Normalisation on Michael's input in the ?openid_identifier? field to turn it into a full Identifier , which (because the relying party must follow HTTP redirects, etc.) results in ?http://www.voidspace.co.uk/? as the Claimed Identifier. The provider is still unknown at this point. The relying party only gets to the provider after performing Discovery on the Claimed Identifier the user presents. For the Claimed Identifier in this case, the path that succeeds is HTML discovery , and at *that* point the relying party has the OP-Local Identifier to be used for this authentication session. > So all I (as a relying party) get verifyied is > fuzzyman.myopenid.com. That (or rather, ?http://fuzzyman.myopenid.com/?) is the OP-Local Identifier. It is what the relying party presents to the OpenID Provider during authentication. But the OP-Local Identifier is transitory; it can change at any time in the future if Michael chooses to modify the information at . The relying party should not persistently associate the OP-Local Identifier with Michael's account; only the Claimed Identifier is persistent. The rest of the information is discovered each time Michael uses that identifier. > Why should I trust that voidspace.org.uk is actually a valid ID? It's valid if you can use it in the OpenID system. The relying party needs to authenticate it each time Michael presents it for authentication; the provider gets to say whether it's owned by the user presenting it at the time. > Can't you then produce hundreds of IDs, all delegating to the same > identity? Yes, that's part of the point of delegated identity. Of course, Michael will only do that if he wants to go to the effort of maintaining many separate identities (e.g. one for work, one for play, one for his persona as a subversive garden gnome painter), because they'll all be treated separately. Any time Michael wants to be using the *same* identity again, he'll present the same OpenID. > IOW, why should I (as a relying party) pay any attention to the ID > that you entered, rather than to what I get actually validated? Because that's what the user has *told you* is the OpenID they want to use. It is his ?Claimed Identifier?, and is the identity token. It would help if you'd ignore what's going on when you go to StackOverflow and click on the Google icon. That's apparently confusing you in this case, because it's glossing over precisely the step that Michael, Glyph, and I want you to take note of: the Initiation step, where someone deliberately says to the relying party ?this is my OpenID?. Think of the OpenID as a token, presented by the person as their identity, like a combination of username and password. They get to decide what it is (which is, again, part of the point of OpenID), and they get to decide which provider is in charge of authenticating their ownership of that token. The relying party uses the OpenID Authentication protocol each time to verify whether the provider agrees the person presenting that identity actually owns it. When Michael goes to StackOverflow and logs in, he will (if he chooses) log in with the OpenID ?voidspace.co.uk?, and that is what StackOverflow will store as the OpenID for his account. He can also, in the future, add extra OpenIDs to the same account; this tells StackOverflow that those identities are actually the same person. Next time Michael goes to StackOverflow, he'll present an OpenID, StackOverflow will perform the whole OpenID Authentication protocol on it, and *any* of the information used with that OpenID last time could have changed. If verification of Michael's OpenID succeeds again, he'll get access to his StackOverflow account. I hope that helps you in implementing standard OpenID for PyPI. Thanks again for working through this. -- \ ?Odious ideas are not entitled to hide from criticism behind | `\ the human shield of their believers' feelings.? ?Richard | _o__) Stallman | Ben Finney From pje at telecommunity.com Sun Nov 15 23:16:43 2009 From: pje at telecommunity.com (P.J. Eby) Date: Sun, 15 Nov 2009 17:16:43 -0500 Subject: [Catalog-sig] Rating feature In-Reply-To: References: <4AB145CD.900@v.loewis.de> <4AB15780.7070309@simplistix.co.uk> <4AB158BB.9000302@simplistix.co.uk> Message-ID: <20091115221645.BFE4C3A40A2@sparrow.telecommunity.com> At 02:27 PM 11/15/2009 -0500, Terry Reedy wrote: >Sridhar Ratnakumar wrote: > >>Yes. If PyPI is going to have release-specific ratings, I suggest >>that each PyPI page (distname-version) show two rating bars: >>a) release rating (logged-in user editable) >>b) overall rating (averaged from all release ratings) > >I would make the second an average over all past releases >I would also suggest making it a so-called exponentially weighted >average. Assume that past ratings are frozen and the individual >votes tossed, the update when a new release arrives would be something like > >past = .8 * past + .2 * current # adjust weights to taste >current = > >This way, a blunder release, once corrected, would have limited >effect on the overall average and its effect would disappear with time. You need to weight also for the number of ratings, not just the overall rating. >_______________________________________________ >Catalog-SIG mailing list >Catalog-SIG at python.org >http://mail.python.org/mailman/listinfo/catalog-sig From ben+python at benfinney.id.au Mon Nov 16 00:06:32 2009 From: ben+python at benfinney.id.au (Ben Finney) Date: Mon, 16 Nov 2009 10:06:32 +1100 Subject: [Catalog-sig] OpenID login to PyPI References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> Message-ID: <87my2npevb.fsf@benfinney.id.au> Martin von L?wis writes: > Glyph Lefkowitz wrote: > > Why do you want [PyPI] to support OpenID only for a very small set > > of providers? > There are two reasons, one more technical than the other: > 1. I read that there are numerous complaints about interoperability: > [?] In particular, I would prefer to restrict attention to OpenID 2, > which I understand now. I think that would be quite reasonable; OpenID 2.0 is stable and fixes several small (and not-so-small) glitches that 1.1 had. The specification requires ?OpenID Authentication 1.1 Compatibility? , which is all you need to care about for OpenID 1.1. > 2. I also want the provider to provide me with a verified email > address, You can get the user's chosen email address during registration, *after* authentication. The OpenID Simple Registration Extension (SReg) is designed for exactly that: getting details from the user at account registration time, after verifying that they own the OpenID they presented. > But you *can* get the so that a) users can start using the account > right away, rather than having to perform an address verification > first The verification, though, should be done by PyPI. You shouldn't be trusting the OpenID provider to verify an email address, that's not its job (and, as you rightly point out, you can't trust an arbitrary OpenID provider to do so). Of course, if during registration it happens that you *do* trust the provider to verify the user's email address, then that's up to you. But this should not limit the providers from which you accept *authentication* of an OpenID. > and b) to simplify the control flow - it's called a "provider" because > it provides something to *me* also, as a relying party, something that > I want to rely on (rather than having to verify it myself). What is provided to you is the process of verifying the user's ownership of their chosen identifier. > If I can't rely on the data that the provider provides, I gain nothing > by accepting OpenID. Instead, I likely open up the service to spammers > (which will recognize the openid login, and automatically create > accounts). That's exactly the reason why you shouldn't *trust* the data, beyond ?this is what the user wants me to know about them?. User-generated data is still only as trustworthy as it ever was; using OpenID doesn't change that, since all that data *about* the user from the OpenID provider is generated by the user at some previous time. > What I do rely on is a verified email address. I need to be able to > contact package owners in case there is a problem with the package > (which happens fairly often, given the large number of packages that > are now indexed). This is such a common requirement that most OpenID providers will store common registration fields input once by the user, and present them (with the user's permission) to the relying party using OpenID Simple Registration. It's ?Simple Registration? because the user doesn't have to keep typing it in every time he registers at a new site, but merely give permission for it to be handed out to that new site. > Your specific complaint ("I want to use a trusted provider, but still > want to type my openid, because that's what I always do") is actually > new, so I'm trying to understand it better. I hope this is all starting to make it clearer: the OpenID *identifier* (?what is my OpenID?) is intentionally decoupled from the OpenID *provider*. You don't have to trust the provider to do anything but verify that identifier is controlled by the person presenting it. Just as you trust the email verification procedure to verify that the user controls the email address they specify. > See above. If there was a legitimate use case for this UI (other than > tradition), I could reluctantly add it to some place where it does no > harm. I would then need to elaborate the reasoning as to why I > consider verified email address as an important property. With OpenID, registration should happen *after* authentication: Since the user needs to submit their OpenID before you can check whether it corresponds to an existing account, you might as well authenticate them *before* bothering with checking if there's an existing account. Here it is in detail: * Initiation: user is asked for their OpenID, Michael types in ?voidspace.org.uk?. * Normalisation, then Discovery: after which PyPI knows the Claimed Identifier is ?http://www.voidspace.org.uk/? and where to go *this time* to verify that claim. * Authentication: the provider verifies Michael's claim; it then sends the result directly to PyPI. * Assuming Michael is authenticated, PyPI now knows Michael controls that identifier, and will use it to find his account. If there's no account associated with ?http://www.voidspace.org.uk/?, *then* PyPI should begin Registration for a new account: * OpenID SReg is used to request the common parts (?nickname?, ?fullname?, ?email?, ?language?, ?timezone?, etc.). I don't believe PyPI needs other information from the user than what is available with SReg, but in case it's needed, OpenID Attribute Exchange can be used to request other arbitrary information about the user. * Any information thus provided can be used at PyPI to pre-populate the registration form, or (if all the information is successfully gathered) to skip the form altogether and automatically set up the user's new account. So, none of this replaces the need to gather and keep information about the user's account on PyPI, nor to do verification of any user-provided information that PyPI needs to use in a trusted manner. What it does do is ensure that the user can re-use their *existing* answers to the common questions, answered a zillion times before ever coming to PyPI. -- \ ?A thorough reading and understanding of the Bible is the | `\ surest path to atheism.? ?Donald Morgan | _o__) | Ben Finney From paul at boddie.org.uk Mon Nov 16 01:07:20 2009 From: paul at boddie.org.uk (Paul Boddie) Date: Mon, 16 Nov 2009 01:07:20 +0100 Subject: [Catalog-sig] [Distutils] People want CPAN :-) Message-ID: <200911160107.20682.paul@boddie.org.uk> James Bennett wrote: > On Fri, Nov 6, 2009 at 7:52 PM, Chris Withers wrote: > > This feels like a post relative to the catalog-sig too, or maybe even > > moreso than distutils-sig... > > The question that's on my mind here, and which I haven't really seen a > solid answer to in the various threads, is which parts of CPAN people > seem to want. The original post mainly seemed to be concerned with > saying "install this" and having it automagically work, dependencies > and all, which is much less a PyPI issue and much more a "sort out the > packaging and installation tools" issue than a PyPI issue. There are tens of messages on the distutils-sig about this now, most of them presumably discussing the innards of distutils and conflating distribution and installation as usual. The comment mentioned R packages and CPAN. My colleague who uses R has demonstrated the mechanism for R, and it didn't seem completely automatic - you had to load the package from a particular address - although maybe it did pull in dependencies as well, and maybe you can configure the addresses and not think about them too hard. It reminded me of work done by various people (including my brother) to import Python packages over HTTP. As for CPAN, my last experience with it was a multi-hour nightmare involving a new installation of Bugzilla and trying to persuade CPAN not to... 1) upgrade the date/time package beyond the version that actually works with Bugzilla to precisely the one which explicitly doesn't work with Bugzilla (where in the end I dug around on the CPAN site until I found the precise, unpublished URL yielding archived versions), and 2) render itself incapable of obtaining and installing packages. Previous experiences also included tracking down package build failures in the overly verbose output. Maybe CPAN packages are tested upon upload or something, but it's somewhat short of what stuff like Debian manages to provide. If CPAN is the goal for Python packaging then we are aspiring to fail our users. I work in a scientific/academic environment - in bioinformatics, in fact - and the biggest obstacle to just using proper package management is the typical institution-wide mentality of locking down Unix-like machines, and yet giving everyone on Windows machines administrator-like privileges and "free rein" [1] to mess up their computers with all sorts of stuff. Meanwhile, packages like this would help solve the problem of the commenter: http://packages.debian.org/lenny/python-biopython Paul [1] http://www.dailywritingtips.com/free-rein-or-free-reign/ From ben+python at benfinney.id.au Mon Nov 16 01:13:40 2009 From: ben+python at benfinney.id.au (Ben Finney) Date: Mon, 16 Nov 2009 11:13:40 +1100 Subject: [Catalog-sig] OpenID login to PyPI References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> Message-ID: <87d43jpbrf.fsf@benfinney.id.au> Message-ID: <4B00683B.6090902 at v.loewis.de> Martin van L?wis writes: > But then, users can easily create as many fake accounts as they want > to. What is a ?fake account?? I have three OpenIDs that I use for different purposes. On some sites, I will associate them together; on others, I only use one. Are any of those ?fake accounts?? If on the other hand you mean ?fake PyPI account?, there's nothing about OpenID that circumvents a proper registration process. You just do it after asking the user their OpenID, when you find out the OpenID isn't yet associated with a PyPI account. An OpenID provider can provide data on the user's behalf during the PyPI account registration process (using ?Simple Registration extension?), but there's nothing requiring you to treat that data any differently from whatever else the user might put into a form. Does that address the ?fake account? concern, or have I misunderstood? -- \ ?I'm beginning to think that life is just one long Yoko Ono | `\ album; no rhyme or reason, just a lot of incoherent shrieks and | _o__) then it's over.? ?Ian Wolff | Ben Finney From david.lyon at preisshare.net Mon Nov 16 01:08:52 2009 From: david.lyon at preisshare.net (David Lyon) Date: Sun, 15 Nov 2009 19:08:52 -0500 Subject: [Catalog-sig] [Distutils] People want CPAN :-) In-Reply-To: <200911160107.20682.paul@boddie.org.uk> References: <200911160107.20682.paul@boddie.org.uk> Message-ID: Paul, On Mon, 16 Nov 2009 01:07:20 +0100, Paul Boddie wrote: >> >> The question that's on my mind here, and which I haven't really seen a >> solid answer to in the various threads, is which parts of CPAN people >> seem to want. The original post mainly seemed to be concerned with >> saying "install this" and having it automagically work, dependencies >> and all, which is much less a PyPI issue and much more a "sort out the >> packaging and installation tools" issue than a PyPI issue. I think the general jist of the original "People want CPAN" post by Guido was just a request for a smoother user experience for users. Of course, CPAN isn't perfect. And dependencies are just one issue. I agree with your points on windows users having admin access. It is a little strange. David From martin at v.loewis.de Mon Nov 16 07:45:17 2009 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Mon, 16 Nov 2009 07:45:17 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <87my2npevb.fsf@benfinney.id.au> References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> Message-ID: <4B00F4FD.1060108@v.loewis.de> >> 2. I also want the provider to provide me with a verified email >> address, > > You can get the user's chosen email address during registration, *after* > authentication. The OpenID Simple Registration Extension (SReg) > > is designed for exactly that: getting details from the user at account > registration time, after verifying that they own the OpenID they > presented. It's not really *after*, but simultaneously. I request the email address when I direct the user the OP, and when she returns, I get the email address. >> But you *can* get the so that a) users can start using the account >> right away, rather than having to perform an address verification >> first > > The verification, though, should be done by PyPI. You shouldn't be > trusting the OpenID provider to verify an email address, that's not its > job (and, as you rightly point out, you can't trust an arbitrary OpenID > provider to do so). No no no. It's called "provider" because it provides me with authenticated information, and it's called "relying party" because I rely on the provider to do so reliably. That's the whole point. If I had to verify the user's real name afterwards anyway, and if I need a verified real name (for some reason), I have no way other than relying that the real name is really reliably provided. As a relying party, I have to trust the provider. Some providers I trust, others I don't (it seems that myOpendID.com is less trustworthy than I was originally told, in that respect). > Of course, if during registration it happens that you *do* trust the > provider to verify the user's email address, then that's up to you. But > this should not limit the providers from which you accept > *authentication* of an OpenID. Hmm. Then integrating OpenID only complicates matters. I don't gain anything. >> and b) to simplify the control flow - it's called a "provider" because >> it provides something to *me* also, as a relying party, something that >> I want to rely on (rather than having to verify it myself). > > What is provided to you is the process of verifying the user's ownership > of their chosen identifier. I think it's irresponsible that the SREG spec says "Security considerations: None." when clearly there are many issues to consider wrt. trustworthiness of the provided information. > That's exactly the reason why you shouldn't *trust* the data, beyond > ?this is what the user wants me to know about them?. User-generated data > is still only as trustworthy as it ever was; using OpenID doesn't change > that, since all that data *about* the user from the OpenID provider is > generated by the user at some previous time. But not all of the information in SREG is user-generated. Thinks like full name, email address, date of birth, gender, postcode, country of residence are administratively not user-*generated*. It may be that most providers don't verify this information, and let the user put in arbitrary junk. Such providers I will not trust. Of course, I don't much of this information, so I don't care whether the user lies about the gender; I can accept that the user lies about the full name. For the email address, I really need to rely on it being valid. > You don't have to trust the provider to do anything but verify that > identifier is controlled by the person presenting it. But I *want* to trust the provider. I hope this message makes that clear. > With OpenID, registration should happen *after* authentication: Since > the user needs to submit their OpenID before you can check whether it > corresponds to an existing account, you might as well authenticate them > *before* bothering with checking if there's an existing account. No, it happens simultaneously. That's how the protocol is defined. > > Here it is in detail: > > * Initiation: user is asked for their OpenID, Michael types in > ?voidspace.org.uk?. > > * Normalisation, then Discovery: after which PyPI knows the Claimed > Identifier is ?http://www.voidspace.org.uk/? and where to go *this > time* to verify that claim. > > * Authentication: the provider verifies Michael's claim; it then sends > the result directly to PyPI. > > * Assuming Michael is authenticated, PyPI now knows Michael controls > that identifier, and will use it to find his account. > > If there's no account associated with ?http://www.voidspace.org.uk/?, > *then* PyPI should begin Registration for a new account: > > * OpenID SReg is used to request the common parts (?nickname?, > ?fullname?, ?email?, ?language?, ?timezone?, etc.). I don't believe > PyPI needs other information from the user than what is available > with SReg, but in case it's needed, OpenID Attribute Exchange > can > be used to request other arbitrary information about the user. You misunderstand. It happens during authentication. From the SREG specification, section 3: "The request parameters detailed here SHOULD be sent with OpenID Authentication checkid_immediate or checkid_setup requests." where the "SHOULD" refers to the fact that sending them is optional - but if you don't send them, you won't get SREG information. As for AX: PyPI currently requests both AX and SREG. Some providers provide SREG, others AX - and not SREG (e.g. Google). > So, none of this replaces the need to gather and keep information about > the user's account on PyPI, nor to do verification of any user-provided > information that PyPI needs to use in a trusted manner. OpenID is certainly designed to replace traditional registration. I think you'll agree that the password setup and the "lost password" procedures can be eliminated; I also *want* to eliminate the email verification at registration time. Ideally, I would also learn about changes to the email address from the provider. Regards, Martin From martin at v.loewis.de Mon Nov 16 07:51:17 2009 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Mon, 16 Nov 2009 07:51:17 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <87d43jpbrf.fsf@benfinney.id.au> References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87d43jpbrf.fsf@benfinney.id.au> Message-ID: <4B00F665.8080006@v.loewis.de> > Martin van L?wis writes: >> But then, users can easily create as many fake accounts as they want >> to. > > What is a ?fake account?? It's one setup with malicious intent, such as spamming. > I have three OpenIDs that I use for different > purposes. On some sites, I will associate them together; on others, I > only use one. Are any of those ?fake accounts?? No - since you don't have any malicious intent (I presume). > If on the other hand you mean ?fake PyPI account?, there's nothing about > OpenID that circumvents a proper registration process. Well, from my view (as a relying party), THAT'S THE WHOLE POINT OF OPENID (sorry for shouting). I don't understand what's so difficult about that. Sure, it is convenient to the user to not need to remember their passwords and account names in these various sites - but OpenID also can (if done properly) simplify the life for the service operator. > An OpenID provider can provide data on the user's behalf during the PyPI > account registration process (using ?Simple Registration extension?), > but there's nothing requiring you to treat that data any differently > from whatever else the user might put into a form. > > Does that address the ?fake account? concern, or have I misunderstood? No. It fails to address the opportunity for a simplified registration process. Regards, Martin From ubernostrum at gmail.com Mon Nov 16 09:40:50 2009 From: ubernostrum at gmail.com (James Bennett) Date: Mon, 16 Nov 2009 02:40:50 -0600 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B00F4FD.1060108@v.loewis.de> References: <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> Message-ID: <21787a9f0911160040w2cc09047t31832adf55a9b267@mail.gmail.com> On Mon, Nov 16, 2009 at 12:45 AM, "Martin v. L?wis" wrote: > No no no. It's called "provider" because it provides me with > authenticated information, and it's called "relying party" because > I rely on the provider to do so reliably. That's the whole point. > If I had to verify the user's real name afterwards anyway, and if > I need a verified real name (for some reason), I have no way other > than relying that the real name is really reliably provided. The problem here, I think, is that you're expecting more from OpenID than it really provides. OpenID lets me make an assertion about a URL (namely, that I "am" that URL) and lets you verify the truth (or falsity) of that assertion. It doesn't let me make assertions about my real name, email address or other information, and it doesn't let you verify the truth (or falsity) of such assertions. > As a relying party, I have to trust the provider. Some providers I > trust, others I don't (it seems that myOpendID.com is less trustworthy > than I was originally told, in that respect). Somewhat sad to note: I cannot use my OpenID with PyPI. I delegate to myopenid.com, but my OpenID is and always has been "http://www.b-list.org/". If PyPI would let me use that and follow the delegation chain, it would be able to verify that I "am" that URL, and then could use, e.g., whois info or email to standard addresses on the domain to strongly verify further claims. But unless/until PyPI supports using my actual OpenID, and not just the transient provider I happen to be delegating to at the moment, the OpenID features on PyPI are basically useless to me. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." From exarkun at twistedmatrix.com Mon Nov 16 14:48:06 2009 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Mon, 16 Nov 2009 13:48:06 -0000 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B00F665.8080006@v.loewis.de> References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87d43jpbrf.fsf@benfinney.id.au> <4B00F665.8080006@v.loewis.de> Message-ID: <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> On 06:51 am, martin at v.loewis.de wrote: >>Martin van L?wis writes: >>>But then, users can easily create as many fake accounts as they want >>>to. >> >>What is a 1Cfake account 1D? > >It's one setup with malicious intent, such as spamming. >>I have three OpenIDs that I use for different >>purposes. On some sites, I will associate them together; on others, I >>only use one. Are any of those 1Cfake accounts 1D? > >No - since you don't have any malicious intent (I presume). >>If on the other hand you mean 1Cfake PyPI account 1D, there's nothing >>about >>OpenID that circumvents a proper registration process. > >Well, from my view (as a relying party), THAT'S THE WHOLE POINT OF >OPENID (sorry for shouting). I don't understand what's so difficult >about that. Sure, it is convenient to the user to not need to remember >their passwords and account names in these various sites - but OpenID >also can (if done properly) simplify the life for the service operator. Since I can create as many gmail accounts as I want and use them to register as many separate PyPI accounts as I want, what's the point of trying to enforce this restriction on OpenID-based accounts? It seems that it only causes problems for people who want to use OpenID, while not really preventing any opportunities for spammers (who can always just use non-OpenID authentication). Is the plan to eventually disable non-OpenID authentication? Jean-Paul From g.brandl at gmx.net Mon Nov 16 16:22:22 2009 From: g.brandl at gmx.net (Georg Brandl) Date: Mon, 16 Nov 2009 16:22:22 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87d43jpbrf.fsf@benfinney.id.au> <4B00F665.8080006@v.loewis.de> <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> Message-ID: exarkun at twistedmatrix.com schrieb: > On 06:51 am, martin at v.loewis.de wrote: >>>Martin van L?wis writes: >>>>But then, users can easily create as many fake accounts as they want >>>>to. >>> >>>What is a 1Cfake account 1D? >> >>It's one setup with malicious intent, such as spamming. >>>I have three OpenIDs that I use for different >>>purposes. On some sites, I will associate them together; on others, I >>>only use one. Are any of those 1Cfake accounts 1D? >> >>No - since you don't have any malicious intent (I presume). >>>If on the other hand you mean 1Cfake PyPI account 1D, there's nothing >>>about >>>OpenID that circumvents a proper registration process. >> >>Well, from my view (as a relying party), THAT'S THE WHOLE POINT OF >>OPENID (sorry for shouting). I don't understand what's so difficult >>about that. Sure, it is convenient to the user to not need to remember >>their passwords and account names in these various sites - but OpenID >>also can (if done properly) simplify the life for the service operator. > > Since I can create as many gmail accounts as I want and use them to > register as many separate PyPI accounts as I want, what's the point of > trying to enforce this restriction on OpenID-based accounts? > > It seems that it only causes problems for people who want to use OpenID, > while not really preventing any opportunities for spammers (who can > always just use non-OpenID authentication). > > Is the plan to eventually disable non-OpenID authentication? I hope not. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. From martin at v.loewis.de Mon Nov 16 19:40:32 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 16 Nov 2009 19:40:32 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <21787a9f0911160040w2cc09047t31832adf55a9b267@mail.gmail.com> References: <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> <21787a9f0911160040w2cc09047t31832adf55a9b267@mail.gmail.com> Message-ID: <4B019CA0.4070104@v.loewis.de> > The problem here, I think, is that you're expecting more from OpenID > than it really provides. OpenID lets me make an assertion about a URL > (namely, that I "am" that URL) That's not true. The Attribute Exchange extension, and the Simple Registration extension allow precisely that. See http://openid.net/specs/openid-attribute-exchange-1_0.html http://openid.net/specs/openid-simple-registration-extension-1_0.html > and lets you verify the truth (or > falsity) of that assertion. It doesn't let me make assertions about my > real name, email address or other information, and it doesn't let you > verify the truth (or falsity) of such assertions. The PAPE extension is designed to talk about policies that a provider follows. Of course, the provider may follow additional policies, making one more trustworthy than another. > >> As a relying party, I have to trust the provider. Some providers I >> trust, others I don't (it seems that myOpendID.com is less trustworthy >> than I was originally told, in that respect). > > Somewhat sad to note: I cannot use my OpenID with PyPI. I delegate to > myopenid.com, but my OpenID is and always has been > "http://www.b-list.org/" Did you try that out? I can't see a reason why you shouldn't be able to use that with PyPI - just follow the myOpenID link on the front page (or, if you have already a PyPI account, login, go to your user information, and *then* follow the myOpenID link). > But unless/until PyPI supports using my actual OpenID, and not just > the transient provider I happen to be delegating to at the moment, the > OpenID features on PyPI are basically useless to me. I fail to see why that is the case. Does it not work, or are you simply refusing to use even though it would work? Regards, Martin From martin at v.loewis.de Mon Nov 16 19:53:17 2009 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Mon, 16 Nov 2009 19:53:17 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87d43jpbrf.fsf@benfinney.id.au> <4B00F665.8080006@v.loewis.de> <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> Message-ID: <4B019F9D.9040300@v.loewis.de> > Since I can create as many gmail accounts as I want and use them to > register as many separate PyPI accounts as I want, what's the point of > trying to enforce this restriction on OpenID-based accounts? > > It seems that it only causes problems for people who want to use OpenID, > while not really preventing any opportunities for spammers (who can > always just use non-OpenID authentication). > > Is the plan to eventually disable non-OpenID authentication? To keep the code maintainable, I would indeed like to reduce the number of authentication options. The number of cases to consider already begins to explode. So if OpenID would be successful, it would be good if username/password authentication could go away some day. So: yes. From my point of view, that would be the primary use of OpenID for me, as a relying party. I don't care too much that users can login the same way in other services as well, as I'm not in charge of these other services. It's the promise of simplified procedures that makes me work on this. Unfortunately, at the same time, I'm skeptical that OpenID can really deliver here. For example, I see little chance that distutils could provide reasonable access to PyPI using OpenID, as OpenID is fairly bound to be run in a web browser only. So ISTM that package owners will have to set (and remember) a password, anyway, unless they always add new releases through the web interface. Regards, Martin From ubernostrum at gmail.com Mon Nov 16 21:01:05 2009 From: ubernostrum at gmail.com (James Bennett) Date: Mon, 16 Nov 2009 14:01:05 -0600 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B019CA0.4070104@v.loewis.de> References: <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> <21787a9f0911160040w2cc09047t31832adf55a9b267@mail.gmail.com> <4B019CA0.4070104@v.loewis.de> Message-ID: <21787a9f0911161201y51779279jad3db233848084c@mail.gmail.com> On Mon, Nov 16, 2009 at 12:40 PM, "Martin v. L?wis" wrote: > Did you try that out? I can't see a reason why you shouldn't be able > to use that with PyPI - just follow the myOpenID link on the front > page (or, if you have already a PyPI account, login, go to your user > information, and *then* follow the myOpenID link). PyPI always kicks me directly to myopenid.com, which means it will always identify me as ubernostrum.myopenid.com. Without a text box into which I can enter my *actual* OpenID, there's no way I can use it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." From martin at v.loewis.de Mon Nov 16 21:08:54 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 16 Nov 2009 21:08:54 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <21787a9f0911161201y51779279jad3db233848084c@mail.gmail.com> References: <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> <21787a9f0911160040w2cc09047t31832adf55a9b267@mail.gmail.com> <4B019CA0.4070104@v.loewis.de> <21787a9f0911161201y51779279jad3db233848084c@mail.gmail.com> Message-ID: <4B01B156.50102@v.loewis.de> James Bennett wrote: > On Mon, Nov 16, 2009 at 12:40 PM, "Martin v. L?wis" wrote: >> Did you try that out? I can't see a reason why you shouldn't be able >> to use that with PyPI - just follow the myOpenID link on the front >> page (or, if you have already a PyPI account, login, go to your user >> information, and *then* follow the myOpenID link). > > PyPI always kicks me directly to myopenid.com, which means it will > always identify me as ubernostrum.myopenid.com. Without a text box > into which I can enter my *actual* OpenID, there's no way I can use > it. This I don't understand. You'll be identified by myopenid.com as ubernostrum.myopenid.com *anyway*, even if you first enter something else. So why can't you just go ahead and associate ubernostrum.myopenid.com with your PyPI account, and then use that to login? AFAICT, it's straight-forward to use. Regards, Martin From ubernostrum at gmail.com Mon Nov 16 21:15:53 2009 From: ubernostrum at gmail.com (James Bennett) Date: Mon, 16 Nov 2009 14:15:53 -0600 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B01B156.50102@v.loewis.de> References: <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> <21787a9f0911160040w2cc09047t31832adf55a9b267@mail.gmail.com> <4B019CA0.4070104@v.loewis.de> <21787a9f0911161201y51779279jad3db233848084c@mail.gmail.com> <4B01B156.50102@v.loewis.de> Message-ID: <21787a9f0911161215y4618e85ct4d4c144944bbea3a@mail.gmail.com> On Mon, Nov 16, 2009 at 2:08 PM, "Martin v. L?wis" wrote: > This I don't understand. You'll be identified by myopenid.com as > ubernostrum.myopenid.com *anyway*, even if you first enter something > else. So why can't you just go ahead and associate > ubernostrum.myopenid.com with your PyPI account, and then use that > to login? My OpenID is "www.b-list.org". "ubernostrum.myopenid.com" is simply a local name my provider uses to refer to me, and may change in the future if I change providers. I'd like PyPI to let me use my *real* OpenID, and not force me to use something tied to a particular provider; this is kinda the whole point of OpenID delegation. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." From ben+python at benfinney.id.au Mon Nov 16 21:33:10 2009 From: ben+python at benfinney.id.au (Ben Finney) Date: Tue, 17 Nov 2009 07:33:10 +1100 Subject: [Catalog-sig] OpenID login to PyPI References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> Message-ID: <878we6p5vd.fsf@benfinney.id.au> "Martin v. L?wis" writes: > > The verification, though, should be done by PyPI. You shouldn't be > > trusting the OpenID provider to verify an email address, that's not > > its job (and, as you rightly point out, you can't trust an arbitrary > > OpenID provider to do so). > > No no no. It's called "provider" because it provides me with > authenticated information, and it's called "relying party" because > I rely on the provider to do so reliably. That's the whole point. That's not a promise ever made by the protocol, so I don't know why you're expecting that. The relying party gets information from the provider, but there is no guarantee that the email address is verified to anything but the *user's own* standards. If you (the relying party) trust the user (via their provider) to provide you an email address that you then trust, that's great. But nothing about OpenID makes any such promise. If you have a particular standard of verification for an email address, it's *not* the job of the OpenID provider to do that for you. > If I had to verify the user's real name afterwards anyway, and if I > need a verified real name (for some reason), I have no way other than > relying that the real name is really reliably provided. Yes. Which is no worse than what you have in the absence of OpenID. > As a relying party, I have to trust the provider. Some providers I > trust, others I don't (it seems that myOpendID.com is less trustworthy > than I was originally told, in that respect). Right. So continue vetting the user-supplied data as you would normally, whether that user-supplied data comes from an OpenID provider or from the user putting data into a form on your web site. > > Of course, if during registration it happens that you *do* trust the > > provider to verify the user's email address, then that's up to you. > > But this should not limit the providers from which you accept > > *authentication* of an OpenID. > > Hmm. Then integrating OpenID only complicates matters. I don't gain > anything. What you gain is more users: the barrier to their entry is lowered. That's the primary gain. I know that there are countless *thousands* of sites that I don't bother creating an account with, because they don't support OpenID. You also get to offload the task of authentication of *identity* to another party, chosen by the user. That is, you don't need to manage their password; someone else is responsible for that. > But not all of the information in SREG is user-generated. Thinks like > full name, email address, date of birth, gender, postcode, country of > residence are administratively not user-*generated*. The user generated all those at some point. > It may be that most providers don't verify this information, and let > the user put in arbitrary junk. Such providers I will not trust. How will you know? My point is that you should treat such information as though the user generated it at some arbitrary point in the near or distant past, and don't expect that it has gone through any particular verification. > Of course, I don't much of this information, so I don't care whether > the user lies about the gender; I can accept that the user lies about > the full name. For the email address, I really need to rely on it > being valid. Right. So you do what just about every site I've been to that needs to use this information (including PyPI) does: verify it to your own standard before using it. This, again, is no worse than what you already have to do in the absence of OpenID. So while OpenID doesn't make this go away (nor could it), it also doesn't change it. > But I *want* to trust the provider. I hope this message makes that > clear. Yes, thank you. That's not its job though. By nature of being a *distributed* identity protocol, where the user is in control of their own identity information, you must therefore treat the information provided as you would treat any user-provided information. > > With OpenID, registration should happen *after* authentication [?] > No, it happens simultaneously. That's how the protocol is defined. I stand corrected; so much the better, then. > > So, none of this replaces the need to gather and keep information > > about the user's account on PyPI, nor to do verification of any > > user-provided information that PyPI needs to use in a trusted > > manner. > > OpenID is certainly designed to replace traditional registration. Only in the sense of the web form, not the data validation or verification. > I think you'll agree that the password setup and the "lost password" > procedures can be eliminated; Yes, but that's not by dint of the registration process; only the authentication process (which is the primary benefit to most OpenID users). > I also *want* to eliminate the email verification at registration > time. Ideally, I would also learn about changes to the email address > from the provider. You can't have that and allow users their choice of provider, since you can't trust an arbitrary provider to verify email addresses to your own standard. Since PyPI already knows how to verify email addresses, I hope you can arrange that it continue doing that while supporting OpenID fully. -- \ ?Facts are meaningless. You could use facts to prove anything | `\ that's even remotely true!? ?Homer, _The Simpsons_ | _o__) | Ben Finney From martin at v.loewis.de Mon Nov 16 21:37:34 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 16 Nov 2009 21:37:34 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <21787a9f0911161215y4618e85ct4d4c144944bbea3a@mail.gmail.com> References: <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> <21787a9f0911160040w2cc09047t31832adf55a9b267@mail.gmail.com> <4B019CA0.4070104@v.loewis.de> <21787a9f0911161201y51779279jad3db233848084c@mail.gmail.com> <4B01B156.50102@v.loewis.de> <21787a9f0911161215y4618e85ct4d4c144944bbea3a@mail.gmail.com> Message-ID: <4B01B80E.5050704@v.loewis.de> >> This I don't understand. You'll be identified by myopenid.com as >> ubernostrum.myopenid.com *anyway*, even if you first enter something >> else. So why can't you just go ahead and associate >> ubernostrum.myopenid.com with your PyPI account, and then use that >> to login? > > My OpenID is "www.b-list.org". "ubernostrum.myopenid.com" is simply a > local name my provider uses to refer to me, and may change in the > future if I change providers. I'd like PyPI to let me use my *real* > OpenID, and not force me to use something tied to a particular > provider; this is kinda the whole point of OpenID delegation. That's right: you can't use the delegation feature of PyPI right now. But you could certainly use your OpenID with PyPI, as myopenid.com is one of the accepted providers. I can understand that you may not *want* to use that - but it would be certainly possible and easy for you to do so. Even if PyPI would support entering "www.b-list.org", it would still notice and remember that you are "ubernostrum.myopenid.com", because it's part of the protocol that it does. I don't know what the point of OpenID delegation is; to me, it appears as a work-around to not have people remember long and complicated IDs, but rather have them type something they can remember. With PyPI, you don't have to remember your ID at all - it never ever becomes relevant for anything. Regards, Martin From jcea at jcea.es Mon Nov 16 21:37:23 2009 From: jcea at jcea.es (Jesus Cea) Date: Mon, 16 Nov 2009 21:37:23 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <21787a9f0911161215y4618e85ct4d4c144944bbea3a@mail.gmail.com> References: <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> <21787a9f0911160040w2cc09047t31832adf55a9b267@mail.gmail.com> <4B019CA0.4070104@v.loewis.de> <21787a9f0911161201y51779279jad3db233848084c@mail.gmail.com> <4B01B156.50102@v.loewis.de> <21787a9f0911161215y4618e85ct4d4c144944bbea3a@mail.gmail.com> Message-ID: <4B01B803.4080102@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Bennett wrote: > My OpenID is "www.b-list.org". "ubernostrum.myopenid.com" is simply a > local name my provider uses to refer to me, and may change in the > future if I change providers. I'd like PyPI to let me use my *real* > OpenID, and not force me to use something tied to a particular > provider; this is kinda the whole point of OpenID delegation. +1. I use OpenID delegation too. But since curently PYPI uses a "whitelist" approach to OpenID, we are out of luck. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBSwG3/5lgi5GaxT1NAQIlLgQAoTIOiVJx+Un7gg+ni1RWpVO9jGDMUluW T4iUpVvHbMi2MYC4FBHeNbRNQ1P6z4aLBmsvpXqENcw3xEyxNfRuA95ubDAaXWru r77XC760iHqhbcWHdE13feXM3AF7Bv1bb5Dd8/7pDtnF27v6jFOSdoPqwHvKMpWW vQ2+WweFm98= =vxq2 -----END PGP SIGNATURE----- From ubernostrum at gmail.com Mon Nov 16 21:48:05 2009 From: ubernostrum at gmail.com (James Bennett) Date: Mon, 16 Nov 2009 14:48:05 -0600 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B01B80E.5050704@v.loewis.de> References: <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> <21787a9f0911160040w2cc09047t31832adf55a9b267@mail.gmail.com> <4B019CA0.4070104@v.loewis.de> <21787a9f0911161201y51779279jad3db233848084c@mail.gmail.com> <4B01B156.50102@v.loewis.de> <21787a9f0911161215y4618e85ct4d4c144944bbea3a@mail.gmail.com> <4B01B80E.5050704@v.loewis.de> Message-ID: <21787a9f0911161248l390ae4efxf0370998c6234f10@mail.gmail.com> On Mon, Nov 16, 2009 at 2:37 PM, "Martin v. L?wis" wrote: > That's right: you can't use the delegation feature of PyPI right > now. But you could certainly use your OpenID with PyPI, as myopenid.com > is one of the accepted providers. I can understand that you may > not *want* to use that - but it would be certainly possible and > easy for you to do so. It is possible, but it is far from easy. > Even if PyPI would support entering "www.b-list.org", it would > still notice and remember that you are "ubernostrum.myopenid.com", > because it's part of the protocol that it does. No. It's part of the protocol that you see the OP-local identifier. When I'm doing delegation, that identifier *IS NOT* the OpenID, and you shouldn't be assuming that it is. > I don't know what the point of OpenID delegation is; to me, it > appears as a work-around to not have people remember long and > complicated IDs, but rather have them type something they can > remember. With PyPI, you don't have to remember your ID at all - > it never ever becomes relevant for anything. The point is this: Right now I use myopenid as my provider. It's not the only place where I can get an OpenID provider, though, and in the future it may go out of business or I may decide I no longer want to use myopenid, preferring instead some other provider. Delegation lets *me* keep control of my identity by maintaining a consistent OpenID in that case -- before the switch, my OpenID is "www.b-list.org", delegated to myopenid, and after the switch my OpenID is "www.b-list.org", delegated to some other provider. This puts my identity in my hands and not my provider's, and is a huge win for me being able to manage and control my identity. But since PyPI doesn't properly support delegation (since, it seems, you're quite attached to the idea of incorrectly using the OP-local identifier instead of my actual OpenID), I can't do any of this and so OpenID on PyPI is useless to me and to anyone else who makes use of delegation. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." From ben+python at benfinney.id.au Mon Nov 16 21:47:49 2009 From: ben+python at benfinney.id.au (Ben Finney) Date: Tue, 17 Nov 2009 07:47:49 +1100 Subject: [Catalog-sig] OpenID login to PyPI References: <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> <21787a9f0911160040w2cc09047t31832adf55a9b267@mail.gmail.com> Message-ID: <874ooup56y.fsf@benfinney.id.au> James Bennett writes: > The problem here, I think, is that you're expecting more from OpenID > than it really provides. OpenID lets me make an assertion about a URL > (namely, that I "am" that URL) and lets you verify the truth (or > falsity) of that assertion. More precisely, it lets you make the assertion ?I control this URL as an identity?. "Martin v. L?wis" writes: > That's not true. The Attribute Exchange extension, and the Simple > Registration extension allow precisely that. See > > http://openid.net/specs/openid-attribute-exchange-1_0.html > http://openid.net/specs/openid-simple-registration-extension-1_0.html The strongest assertion you can make about that information, though, is ?this is what the user has provided in answer to these questions?. This is different from the authentication information in that it is *not* an assertion of the verity of any of that information, nor is it meant to be. > The PAPE extension is designed to talk about policies that a provider > follows. Of course, the provider may follow additional policies, > making one more trustworthy than another. But again, the *only* authentication that is asserted by those policies is ?the user controls the Claimed Identity?. No assertion can be implied about the other attributes. > > Somewhat sad to note: I cannot use my OpenID with PyPI. I delegate > > to myopenid.com, but my OpenID is and always has been > > "http://www.b-list.org/" > > Did you try that out? I can't see a reason why you shouldn't be able > to use that with PyPI - just follow the myOpenID link on the front > page (or, if you have already a PyPI account, login, go to your user > information, and *then* follow the myOpenID link). This is a persistent misapprehension you're making, but I suppose it could come from your focus on the relying party side of this transaction. You are mistakenly taking the transitory ?OP-Local Identity? and treating it as something that it's not. The OP-Local Identity is transitory, only to be used during a given authentication session. It changes whenever James wants it to, at any future point in time, and the *real* identity ? the Claimed Identity in OpenID protocol-speak ? does not change as a result. Thus, their Claimed Identity is the one that they identify with, and they can delegate authentication of that identity to someone else (the provider du jour) at their option and whenever they choose. That is indeed one of the primary *reasons* for people using OpenID. To make it clear: when an OpenID user speaks of ?my OpenID?, they are speaking of what the OpenID Authentication protocol calls the Claimed Identity. That identity is the one that must be persistent with their account, since that's what they will provide next time they want to log in. -- \ ?If nature has made any one thing less susceptible than all | `\ others of exclusive property, it is the action of the thinking | _o__) power called an idea? ?Thomas Jefferson | Ben Finney From jcea at jcea.es Mon Nov 16 21:51:06 2009 From: jcea at jcea.es (Jesus Cea) Date: Mon, 16 Nov 2009 21:51:06 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B01B80E.5050704@v.loewis.de> References: <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> <21787a9f0911160040w2cc09047t31832adf55a9b267@mail.gmail.com> <4B019CA0.4070104@v.loewis.de> <21787a9f0911161201y51779279jad3db233848084c@mail.gmail.com> <4B01B156.50102@v.loewis.de> <21787a9f0911161215y4618e85ct4d4c144944bbea3a@mail.gmail.com> <4B01B80E.5050704@v.loewis.de> Message-ID: <4B01BB3A.3000705@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin v. L?wis wrote: > I don't know what the point of OpenID delegation is; to me, it > appears as a work-around to not have people remember long and > complicated IDs, but rather have them type something they can > remember. With PyPI, you don't have to remember your ID at all - > it never ever becomes relevant for anything. My openid is "http://www.jcea.es/". Pretty obvious and pretty personal. But I "delegate" to "myopenid" to avoid to run my own OpenID provider. The interesting thing is that if tomorrow I have my own provider, or I don't trust "myopenid" anymore, I can change my delegation to something else. And every site that accepts "http://www.jcea.es/" as my OpenID, would keep working perfectly. So delegation is actually a very crucial feature of OpenID. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBSwG7Mplgi5GaxT1NAQKIQAP/c+x+pjLhXOzERY41h2AF1WKoc7tec3JF tUbFmLm3dA8oVHFEdRkkWxPINjzghNRxIpon7mTuWlYGf+QAWRKfjxQv6c3WSMhB tOEAtSQ8xKtulONafuj/wpykV9Grmpvi8HtnvXGqCtIaJujx5pBm8v7PkyKhew4q cB0OM/kvtI8= =1862 -----END PGP SIGNATURE----- From martin at v.loewis.de Mon Nov 16 21:56:17 2009 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Mon, 16 Nov 2009 21:56:17 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <878we6p5vd.fsf@benfinney.id.au> References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> <878we6p5vd.fsf@benfinney.id.au> Message-ID: <4B01BC71.4000904@v.loewis.de> >> No no no. It's called "provider" because it provides me with >> authenticated information, and it's called "relying party" because >> I rely on the provider to do so reliably. That's the whole point. > > That's not a promise ever made by the protocol, so I don't know why > you're expecting that. The relying party gets information from the > provider, but there is no guarantee that the email address is verified > to anything but the *user's own* standards. That depends on the provider. Some providers (e.g. Google and Launchpad) do provide additional guarantees. Clearly, the protocol cannot make any guarantees - not even that the OpenID of the user is validated in form. > If you have a particular > standard of verification for an email address, it's *not* the job of the > OpenID provider to do that for you. Some providers (e.g. Verisign) have *exactly* that job. >> If I had to verify the user's real name afterwards anyway, and if I >> need a verified real name (for some reason), I have no way other than >> relying that the real name is really reliably provided. > > Yes. Which is no worse than what you have in the absence of OpenID. If I had a need for a verified legal name, I would need to require people to show some kind of legal ID. If I then find a provider to provide that to me instead, I could drop that verification. > Right. So continue vetting the user-supplied data as you would normally, > whether that user-supplied data comes from an OpenID provider or from > the user putting data into a form on your web site. Hmm. That makes the data flow even more complicated. I'm also skeptical that OpenID users would accept such email verification, as presumably other sites using OpenID don't do that. Then I would have to bow to the pressure again "nobody else does it, so you have to change your procedure". > What you gain is more users: the barrier to their entry is lowered. > That's the primary gain. I know that there are countless *thousands* of > sites that I don't bother creating an account with, because they don't > support OpenID. That sounds fairly fanatic. If I want to use some service, and I have to setup an account for that, I just go ahead and do it. > You also get to offload the task of authentication of *identity* to > another party, chosen by the user. That is, you don't need to manage > their password; someone else is responsible for that. That would only work if there was a chance that I could ever drop username/password authentication. Unfortunately, that is fairly unrealistic. So I don't gain that particular advantage. >> But not all of the information in SREG is user-generated. Thinks like >> full name, email address, date of birth, gender, postcode, country of >> residence are administratively not user-*generated*. > > The user generated all those at some point. Not really. At least the gender was generated by the parents, at least for most of us (and parents likely didn't control the gender, either). Likewise for day-of-birth. >> It may be that most providers don't verify this information, and let >> the user put in arbitrary junk. Such providers I will not trust. > > How will you know? By studying their documentation, exchanging email with them, etc. Initially by recommendation (that's how I got the current list). It's the standard way trust is established in our society. > My point is that you should treat such information as > though the user generated it at some arbitrary point in the near or > distant past, and don't expect that it has gone through any particular > verification. If that was true, OpenID would be useless to a relying party. Fortunately, it's not true. > This, again, is no worse than what you already have to do in the absence > of OpenID. So while OpenID doesn't make this go away (nor could it), it > also doesn't change it. It could, and in my current installation, it actually does. >> But I *want* to trust the provider. I hope this message makes that >> clear. > > Yes, thank you. That's not its job though. By nature of being a > *distributed* identity protocol, where the user is in control of their > own identity information, you must therefore treat the information > provided as you would treat any user-provided information. We are going in circles here. I don't *have* to treat the information as unreliable once I chose to trust a provider that it *is* reliable. >> I think you'll agree that the password setup and the "lost password" >> procedures can be eliminated; > > Yes, but that's not by dint of the registration process; only the > authentication process (which is the primary benefit to most OpenID > users). Well, the AX protocol is, in principle, able to completely replace the registration process. >> I also *want* to eliminate the email verification at registration >> time. Ideally, I would also learn about changes to the email address >> from the provider. > > You can't have that and allow users their choice of provider, since you > can't trust an arbitrary provider to verify email addresses to your own > standard. Hence I cannot support arbitrary providers. > Since PyPI already knows how to verify email addresses, I hope you can > arrange that it continue doing that while supporting OpenID fully. That's fairly difficult because I have to park so many data "in the middle". It was easy (or, rather, already done) with username/password pairs; with OpenID, it now gets more complicated. Regards, Martin From ben+python at benfinney.id.au Mon Nov 16 21:57:58 2009 From: ben+python at benfinney.id.au (Ben Finney) Date: Tue, 17 Nov 2009 07:57:58 +1100 Subject: [Catalog-sig] OpenID login to PyPI References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87d43jpbrf.fsf@benfinney.id.au> <4B00F665.8080006@v.loewis.de> <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> <4B019F9D.9040300@v.loewis.de> Message-ID: <87zl6mnq5l.fsf@benfinney.id.au> "Martin v. L?wis" writes: > > It seems that it only causes problems for people who want to use > > OpenID, while not really preventing any opportunities for spammers > > (who can always just use non-OpenID authentication). > > > > Is the plan to eventually disable non-OpenID authentication? > > To keep the code maintainable, I would indeed like to reduce the > number of authentication options. The number of cases to consider > already begins to explode. > > So if OpenID would be successful, it would be good if > username/password authentication could go away some day. So: yes. From > my point of view, that would be the primary use of OpenID for me, as a > relying party. That's great, because that is exactly what the aim is, and is the common benefit that both PyPI-like site users and site developers gain. > I don't care too much that users can login the same way in other > services as well, as I'm not in charge of these other services. It's > the promise of simplified procedures that makes me work on this. It's important to realise, though, that *because* users can log in the same way on many other sites, their decision to register on PyPI becomes that much easier. > Unfortunately, at the same time, I'm skeptical that OpenID can really > deliver here. For example, I see little chance that distutils could > provide reasonable access to PyPI using OpenID, as OpenID is fairly > bound to be run in a web browser only. This is true. I know there are efforts underway to have OpenID working in other contexts, but am not aware of their current status. > So ISTM that package owners will have to set (and remember) a > password, anyway, unless they always add new releases through the web > interface. There are other ways; OpenSSH keys, for example, are used on sites like alioth.debian.org to handle non-web data transfer; and PyPI could gather the user's OpenSSH public key through OpenID attribute exchange at the registration step, similar to gathering their OpenPGP public key as is done now. That's only one option out of many, of course, and I don't necessarily say it's a good option for PyPI. -- \ ?It is far better to grasp the universe as it really is than to | `\ persist in delusion, however satisfying and reassuring.? ?Carl | _o__) Sagan | Ben Finney From tseaver at palladion.com Mon Nov 16 21:58:44 2009 From: tseaver at palladion.com (Tres Seaver) Date: Mon, 16 Nov 2009 15:58:44 -0500 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B01B80E.5050704@v.loewis.de> References: <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> <21787a9f0911160040w2cc09047t31832adf55a9b267@mail.gmail.com> <4B019CA0.4070104@v.loewis.de> <21787a9f0911161201y51779279jad3db233848084c@mail.gmail.com> <4B01B156.50102@v.loewis.de> <21787a9f0911161215y4618e85ct4d4c144944bbea3a@mail.gmail.com> <4B01B80E.5050704@v.loewis.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin v. L?wis wrote: > That's right: you can't use the delegation feature of PyPI right > now. But you could certainly use your OpenID with PyPI, as myopenid.com > is one of the accepted providers. I can understand that you may > not *want* to use that - but it would be certainly possible and > easy for you to do so. By blocking delegation, you are forcing James to use an OpenID which is not the one he prefers. > Even if PyPI would support entering "www.b-list.org", it would > still notice and remember that you are "ubernostrum.myopenid.com", > because it's part of the protocol that it does. PyPI should be remembering the claimed ID, not the delegated ID. If you choose to trust only a subset of all authenticating delegates, that is fine: any "claimed" ID with an unsupported delegate should just be rejected. But if the "claimed" ID switches its delegate tomorrow from MyOpenID to Google, PyPI shouldn't need to care. > I don't know what the point of OpenID delegation is; to me, it > appears as a work-around to not have people remember long and > complicated IDs, but rather have them type something they can > remember. With PyPI, you don't have to remember your ID at all - > it never ever becomes relevant for anything. The point is that the "claimed" ID is the "real" identity: the "delegated-to" ID is an implementation detail which might change in the future: I might switch from MyOpenID to Google, for instance, if I thought the service / availability was better, or if Evil Co. bought MyOpenID and started charging for the service. My "claimed" OpenID ('http://palladion.com/') is my permanent OpenID, no matter who is handling the delegation during my current browser session with PyPI: it will remain mine for as long as I keep control of the domain. 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksBvQAACgkQ+gerLs4ltQ6OtwCgsy1c85j5ygQaBZEpBzHdDSsb ll4AoLbo/QLbwkSr5huIqOGGYUFGBPDC =2aVN -----END PGP SIGNATURE----- From exarkun at twistedmatrix.com Mon Nov 16 22:40:57 2009 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Mon, 16 Nov 2009 21:40:57 -0000 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B019F9D.9040300@v.loewis.de> References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87d43jpbrf.fsf@benfinney.id.au> <4B00F665.8080006@v.loewis.de> <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> <4B019F9D.9040300@v.loewis.de> Message-ID: <20091116214057.27565.1312606125.divmod.xquotient.231@localhost.localdomain> On 06:53 pm, martin at v.loewis.de wrote: >>Since I can create as many gmail accounts as I want and use them to >>register as many separate PyPI accounts as I want, what's the point of >>trying to enforce this restriction on OpenID-based accounts? >> >>It seems that it only causes problems for people who want to use >>OpenID, >>while not really preventing any opportunities for spammers (who can >>always just use non-OpenID authentication). >> >>Is the plan to eventually disable non-OpenID authentication? > >To keep the code maintainable, I would indeed like to reduce the number >of authentication options. The number of cases to consider already >begins to explode. > >So if OpenID would be successful, it would be good if username/password >authentication could go away some day. So: yes. From my point of view, >that would be the primary use of OpenID for me, as a relying party. >I don't care too much that users can login the same way in other >services as well, as I'm not in charge of these other services. It's >the promise of simplified procedures that makes me work on this. > >Unfortunately, at the same time, I'm skeptical that OpenID can really >deliver here. For example, I see little chance that distutils could >provide reasonable access to PyPI using OpenID, as OpenID is fairly >bound to be run in a web browser only. So ISTM that package owners >will have to set (and remember) a password, anyway, unless they always >add new releases through the web interface. If username/password authentication will always need to be allowed on PyPI, what is the rational for placing the current limitations on the OpenID support? Or are you still undecided about whether username/password authentication will indeed always be supported? Jean-Paul From martin at v.loewis.de Mon Nov 16 23:07:48 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 16 Nov 2009 23:07:48 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <20091116214057.27565.1312606125.divmod.xquotient.231@localhost.localdomain> References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87d43jpbrf.fsf@benfinney.id.au> <4B00F665.8080006@v.loewis.de> <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> <4B019F9D.9040300@v.loewis.de> <20091116214057.27565.1312606125.divmod.xquotient.231@localhost.localdomain> Message-ID: <4B01CD34.4090509@v.loewis.de> >> Unfortunately, at the same time, I'm skeptical that OpenID can really >> deliver here. For example, I see little chance that distutils could >> provide reasonable access to PyPI using OpenID, as OpenID is fairly >> bound to be run in a web browser only. So ISTM that package owners >> will have to set (and remember) a password, anyway, unless they always >> add new releases through the web interface. > > If username/password authentication will always need to be allowed on > PyPI, what is the rational for placing the current limitations on the > OpenID support? Or are you still undecided about whether > username/password authentication will indeed always be supported? I certainly don't know what always will be. As I'm not sure which specific restriction you refer to, in order: - [must be in wide use, using procedures that the community trusts] This is necessary to be able to trust the registry information, see below. - [must support OpenID 2.0] This is because that's all what the implementation supports - [must support provider-driven identifier selection] This is because I want to avoid ugly login boxes in the UI, and avoid having to type users in their OpenID. - [must provide a validated email address, either through AX or SREG] This is because I want to be able to trust the user interface, and avoid the email verification roundtrip (sparing both myself the implementation of it, and the user access to his email address at the time of registration) - [must support direct communication over https] This is because I didn't implement DH associations. Regards, Martin From mal at egenix.com Mon Nov 16 23:12:48 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 16 Nov 2009 23:12:48 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87d43jpbrf.fsf@benfinney.id.au> <4B00F665.8080006@v.loewis.de> <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> Message-ID: <4B01CE60.2080905@egenix.com> Georg Brandl wrote: >> Is the plan to eventually disable non-OpenID authentication? > > I hope not. Same here. This whole OpenID thing appears to introduce more problems than it solves. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 16 2009) >>> 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 mal at egenix.com Mon Nov 16 23:20:38 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 16 Nov 2009 23:20:38 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B01CD34.4090509@v.loewis.de> References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87d43jpbrf.fsf@benfinney.id.au> <4B00F665.8080006@v.loewis.de> <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> <4B019F9D.9040300@v.loewis.de> <20091116214057.27565.1312606125.divmod.xquotient.231@localhost.localdomain> <4B01CD34.4090509@v.loewis.de> Message-ID: <4B01D036.8040507@egenix.com> "Martin v. L?wis" wrote: >>> Unfortunately, at the same time, I'm skeptical that OpenID can really >>> deliver here. For example, I see little chance that distutils could >>> provide reasonable access to PyPI using OpenID, as OpenID is fairly >>> bound to be run in a web browser only. So ISTM that package owners >>> will have to set (and remember) a password, anyway, unless they always >>> add new releases through the web interface. >> >> If username/password authentication will always need to be allowed on >> PyPI, what is the rational for placing the current limitations on the >> OpenID support? Or are you still undecided about whether >> username/password authentication will indeed always be supported? > > I certainly don't know what always will be. > > As I'm not sure which specific restriction you refer to, in order: > > - [must be in wide use, using procedures that the community trusts] > This is necessary to be able to trust the registry information, > see below. > - [must support OpenID 2.0] > This is because that's all what the implementation supports > - [must support provider-driven identifier selection] > This is because I want to avoid ugly login boxes in the UI, > and avoid having to type users in their OpenID. > - [must provide a validated email address, either through AX or SREG] > This is because I want to be able to trust the user interface, > and avoid the email verification roundtrip (sparing both myself > the implementation of it, and the user access to his email address > at the time of registration) > - [must support direct communication over https] > This is because I didn't implement DH associations. Are you using python-openid for this ? http://openidenabled.com/python-openid/ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 16 2009) >>> 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 Mon Nov 16 23:23:28 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 16 Nov 2009 23:23:28 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B01D036.8040507@egenix.com> References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87d43jpbrf.fsf@benfinney.id.au> <4B00F665.8080006@v.loewis.de> <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> <4B019F9D.9040300@v.loewis.de> <20091116214057.27565.1312606125.divmod.xquotient.231@localhost.localdomain> <4B01CD34.4090509@v.loewis.de> <4B01D036.8040507@egenix.com> Message-ID: <4B01D0E0.7070907@v.loewis.de> > Are you using python-openid for this ? > > http://openidenabled.com/python-openid/ No, I have written a new OpenID client. The protocol itself is fairly simple, once you got it. Regards, Martin From paul at boddie.org.uk Mon Nov 16 23:53:47 2009 From: paul at boddie.org.uk (Paul Boddie) Date: Mon, 16 Nov 2009 23:53:47 +0100 Subject: [Catalog-sig] OpenID login to PyPI Message-ID: <200911162353.47873.paul@boddie.org.uk> Martin v. L?wis wrote: > > > Are you using python-openid for this ? > > > > http://openidenabled.com/python-openid/ > > No, I have written a new OpenID client. The protocol itself > is fairly simple, once you got it. Is there any benefit to using mod_auth_openid with Apache, given that as far as I'm aware, the python.org services run behind Apache? That might even help to wrap up the Roundup tracker, subject to technical limitations with user identifiers and Roundup (and other services) being willing to accept an identity set by the Web server. Paul From ben+python at benfinney.id.au Tue Nov 17 02:45:33 2009 From: ben+python at benfinney.id.au (Ben Finney) Date: Tue, 17 Nov 2009 12:45:33 +1100 Subject: [Catalog-sig] OpenID login to PyPI References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87d43jpbrf.fsf@benfinney.id.au> <4B00F665.8080006@v.loewis.de> <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> <4B019F9D.9040300@v.loewis.de> <20091116214057.27565.1312606125.divmod.xquotient.231@localhost.localdomain> <4B01CD34.4090509@v.loewis.de> Message-ID: <87hbstoreq.fsf@benfinney.id.au> "Martin v. L?wis" writes: > - [must support provider-driven identifier selection] > This is because I want to avoid ugly login boxes in the UI, > and avoid having to type users in their OpenID. Provider-driven identifier selection is great, for exactly the reason you state here, and I'm glad you have support for it. But it excludes anyone using their own user-controlled OpenID, so *please*, and primarily, support users typing in whatever their OpenID is. > - [must provide a validated email address, either through AX or SREG] > This is because I want to be able to trust the user interface, > and avoid the email verification roundtrip (sparing both myself > the implementation of it, and the user access to his email address > at the time of registration) I don't see why you're setting this as some kind of proviso on properly supporting OpenID authentication. Providing a verified email address is not something you had before. The registration process already knows how to process and verify an email address as specified by the user. The email address you get during registration from the provider is of exactly the same nature as one that the user types in to your web form. So, as far as I can see, adding OpenID authentication is *not* predicated on this at all. I don't understand why this orthogonal issue is being made a condition of standard OpenID support. All we're asking (AFAICT) in this thread is that you separate these two, tackle the streamlining of email address verification as a separate issue, and implement standard OpenID authentication. -- \ ?We should strive to do things in [Gandhi's] spirit? not to use | `\ violence in fighting for our cause, but by non-participation in | _o__) what we believe is evil.? ?Albert Einstein | Ben Finney From ben+python at benfinney.id.au Tue Nov 17 03:17:10 2009 From: ben+python at benfinney.id.au (Ben Finney) Date: Tue, 17 Nov 2009 13:17:10 +1100 Subject: [Catalog-sig] OpenID login to PyPI References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> <878we6p5vd.fsf@benfinney.id.au> <4B01BC71.4000904@v.loewis.de> Message-ID: <87d43hopy1.fsf@benfinney.id.au> "Martin v. L?wis" writes: > > [authenticating user-provided attributes is] not a promise ever made > > by the protocol, so I don't know why you're expecting that. The > > relying party gets information from the provider, but there is no > > guarantee that the email address is verified to anything but the > > *user's own* standards. > > That depends on the provider. Some providers (e.g. Google and > Launchpad) do provide additional guarantees. Clearly, the protocol > cannot make any guarantees Exactly. If you find that the provider is giving extra features orthogonal to OpenID, please feel free to use them; but refusing providers that don't provide those extras is crippling the OpenID authentication service for others. > not even that the OpenID of the user is validated in form. Since authenticating the user's OpenID (validating their Claimed Identity) is central to OpenID, it would be quite reasonable to black-list providers that don't perform authentication sufficiently well. > > If you have a particular standard of verification for an email > > address, it's *not* the job of the OpenID provider to do that for > > you. > > Some providers (e.g. Verisign) have *exactly* that job. I can confirm that's not the case: using Verisign's provider, I can specify any email address I like in response to registration requests, and I make frequent use of this to distinguish email addresses on a per-site basis. This is a good thing. > > Right. So continue vetting the user-supplied data as you would > > normally, whether that user-supplied data comes from an OpenID > > provider or from the user putting data into a form on your web site. > > Hmm. That makes the data flow even more complicated. You already have PyPI doing validation of email addresses provided by the user. I'm advocating that you keep that in place, since that's the only way you can trust an arbitrary user-specified email address. > I'm also skeptical that OpenID users would accept such email > verification, as presumably other sites using OpenID don't do that. > Then I would have to bow to the pressure again "nobody else does it, > so you have to change your procedure". Every service I've used OpenID with that wants a verified email address for good reasons (and yes, I think PyPI's reasons are good in this case), verifies the email address themselves. I have no problem with that; it's the status quo before OpenID came along, and it doesn't seem onerous. > That sounds fairly fanatic. If I want to use some service, and I have > to setup an account for that, I just go ahead and do it. I have no complaint against setting up an account. What is too much of a burden in just about every case is to manage a site-specific set of authentication credentials for every new site. I hit my limit long ago, and OpenID offers a way forward. If I was to come across PyPI today, it would likely not pass the bar of ?worth the effort to manage yet another site-specific authentication set?. This is one main reason why I'm so intrested in having OpenID work properly at PyPI. > > The user generated all those [attributes] at some point. > > Not really. At least the gender was generated by the parents, at least > for most of us (and parents likely didn't control the gender, either). > Likewise for day-of-birth. You are probably fully aware that I mean the *data* is generated in the computer by the user, and is only as trustworthy as any other user-supplied data. > > You can't have [provider-verified email address] and allow users > > their choice of provider, since you can't trust an arbitrary > > provider to verify email addresses to your own standard. > > Hence I cannot support arbitrary providers. Until you do, you'll be stuck with supporting a limited subset of big-name providers, and anyone who deliberately controls their own OpenID in order to be *independent* of such providers will be rejected for that action. That doesn't seem likely to make the situation better. I really hope you will consider your users needs and rethink this position. -- \ ?I have one rule to live by: Don't make it worse.? ?Hazel | `\ Woodcock | _o__) | Ben Finney From martin at v.loewis.de Tue Nov 17 06:44:22 2009 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Tue, 17 Nov 2009 06:44:22 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <200911162353.47873.paul@boddie.org.uk> References: <200911162353.47873.paul@boddie.org.uk> Message-ID: <4B023836.2060901@v.loewis.de> Paul Boddie wrote: > Martin v. L?wis wrote: >>> Are you using python-openid for this ? >>> >>> http://openidenabled.com/python-openid/ >> No, I have written a new OpenID client. The protocol itself >> is fairly simple, once you got it. > > Is there any benefit to using mod_auth_openid with Apache, given that as far > as I'm aware, the python.org services run behind Apache? That might even help > to wrap up the Roundup tracker, subject to technical limitations with user > identifiers and Roundup (and other services) being willing to accept an > identity set by the Web server. The problem I have with this (and also partially with python-openid) is that I don't know how to integrate it with the existing application. How is the module supposed to know what PyPI accounts are, and how they relate to existing IDs, and what postgres database and table this information is to be stored in? For Roundup, the problem is even more difficult, IIUC, assuming I want people to add either an openid or a username/password pair into the existing fields: how is mod_auth_openid supposed to know that the name is not an openid in the first place, just because a password is also provided? The roundup installation uses a reverse proxy, so it would be better to create something that doesn't rely on Apache. Regards, Martin From chris at simplistix.co.uk Tue Nov 17 12:16:26 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 17 Nov 2009 11:16:26 +0000 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B01D0E0.7070907@v.loewis.de> References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87d43jpbrf.fsf@benfinney.id.au> <4B00F665.8080006@v.loewis.de> <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> <4B019F9D.9040300@v.loewis.de> <20091116214057.27565.1312606125.divmod.xquotient.231@localhost.localdomain> <4B01CD34.4090509@v.loewis.de> <4B01D036.8040507@egenix.com> <4B01D0E0.7070907@v.loewis.de> Message-ID: <4B02860A.1030505@simplistix.co.uk> Martin v. L?wis wrote: >> Are you using python-openid for this ? >> >> http://openidenabled.com/python-openid/ > > No, I have written a new OpenID client. The protocol itself > is fairly simple, once you got it. Why do this rather than using (and maybe improving) an existing library? Chris From chris at simplistix.co.uk Tue Nov 17 12:26:40 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 17 Nov 2009 11:26:40 +0000 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B01BC71.4000904@v.loewis.de> References: <200911130038.05516.steve@pearwood.info> <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87my2npevb.fsf@benfinney.id.au> <4B00F4FD.1060108@v.loewis.de> <878we6p5vd.fsf@benfinney.id.au> <4B01BC71.4000904@v.loewis.de> Message-ID: <4B028870.2070604@simplistix.co.uk> Firstly, thanks to Ben for bringing these discussions to the correct list. I'd wondered why PyPI's OpenID support was so difficult to use, now I understand ;-) Martin v. L?wis wrote: >>> If I had to verify the user's real name afterwards anyway, and if I >>> need a verified real name (for some reason), I have no way other than >>> relying that the real name is really reliably provided. >> Yes. Which is no worse than what you have in the absence of OpenID. > > If I had a need for a verified legal name, I would need to require > people to show some kind of legal ID. If I then find a provider to > provide that to me instead, I could drop that verification. How would you verify that the provider is doing its job properly? What would you do for people who could not afford to use that provider or weren't allowed to because they lived in the wrong country? > I'm also skeptical that OpenID users would accept such email > verification, as presumably other sites using OpenID don't do that. > Then I would have to bow to the pressure again "nobody else does > it, so you have to change your procedure". Every site I've ever used OpenID to log in to has verified my email address, just like they would if I typed it on a form. >>> It may be that most providers don't verify this information, and let >>> the user put in arbitrary junk. Such providers I will not trust. >> How will you know? > > By studying their documentation, exchanging email with them, etc. > Initially by recommendation (that's how I got the current list). > It's the standard way trust is established in our society. But from what I've read in this thread, you could still have this trusted list *and* let people use provider-agnostic openids by supporting delegation. Does python-openid already support this? >> My point is that you should treat such information as >> though the user generated it at some arbitrary point in the near or >> distant past, and don't expect that it has gone through any particular >> verification. > > If that was true, OpenID would be useless to a relying party. > Fortunately, it's not true. Then you are a lot more trusting than your responses suggest ;-) > We are going in circles here. I don't *have* to treat the information > as unreliable once I chose to trust a provider that it *is* reliable. My gut feeling is that you'll be hard pressed to find any providers that meet these requirements. Even someone like Google, who can certainly promise to have a valid email account associated with their openids by tacking a gmail account onto each one, can't promise that a human has ever looked at that account. That's why you have an email verification process. If you're paranoid, you even go further than the "click this link" since that's easy enough to write a bot to do... >>> I also *want* to eliminate the email verification at registration >>> time. Ideally, I would also learn about changes to the email address >>> from the provider. >> You can't have that and allow users their choice of provider, since you >> can't trust an arbitrary provider to verify email addresses to your own >> standard. > > Hence I cannot support arbitrary providers. But, from what I understand from this thread, that doesn't imply you can't trust arbitrary openids... cheers, Chris From mal at egenix.com Tue Nov 17 12:43:15 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 17 Nov 2009 12:43:15 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B023836.2060901@v.loewis.de> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> Message-ID: <4B028C53.2010506@egenix.com> "Martin v. L?wis" wrote: > Paul Boddie wrote: >> Martin v. L?wis wrote: >>>> Are you using python-openid for this ? >>>> >>>> http://openidenabled.com/python-openid/ >>> No, I have written a new OpenID client. The protocol itself >>> is fairly simple, once you got it. >> >> Is there any benefit to using mod_auth_openid with Apache, given that as far >> as I'm aware, the python.org services run behind Apache? That might even help >> to wrap up the Roundup tracker, subject to technical limitations with user >> identifiers and Roundup (and other services) being willing to accept an >> identity set by the Web server. > > The problem I have with this (and also partially with python-openid) is > that I don't know how to integrate it with the existing application. How > is the module supposed to know what PyPI accounts are, and how they > relate to existing IDs, and what postgres database and table this > information is to be stored in? Well, python-openid is written in Python, so it should be possible to add whatever special functionality you need. http://openidenabled.com/files/python-openid/docs/2.2.4/openid.consumer.consumer-module.html It also comes with an example implementation that shows how to use the lib in a consumer role: http://openidenabled.com/files/python-openid/repos/2.x.x/examples/ > For Roundup, the problem is even more difficult, IIUC, assuming I want > people to add either an openid or a username/password pair into the > existing fields: how is mod_auth_openid supposed to know that the name > is not an openid in the first place, just because a password is also > provided? The roundup installation uses a reverse proxy, so it would > be better to create something that doesn't rely on Apache. With mod_auth_openid, you'd use a separate login page for the OpenID login, so there wouldn't be a mixup between the two variants. mod_auth_openid also allows you to set a user app that implements the authorization part. This could be a Python application that hooks into the PG database: http://trac.butterfat.net/public/mod_auth_openid mod_auth_openid also supports proxies, so it should be possible to use it for roundup as well. Since you were looking for simplification of the used code, it may be worthwhile looking at these two options to outsource the complexity into a 3rd party tool. Both come with their own session database to handle the authentication process sessions. Note that I'm only suggesting to look at these things in order to simplify the implementation. IMHO, OpenID is problematic from a privacy POV in multiple ways. The simple standard user/password login doesn't have these issues and is a lot easier to implement and maintain. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 17 2009) >>> 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 chris at simplistix.co.uk Tue Nov 17 18:28:50 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 17 Nov 2009 17:28:50 +0000 Subject: [Catalog-sig] Do we really need this list? Message-ID: <4B02DD52.1020608@simplistix.co.uk> Hi All, Why do we not just use distutils-sig instead? I don't think I've yet seen a discussion on this list that isn't relevant to distutils-sig... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From cool-rr at cool-rr.com Tue Nov 17 18:42:41 2009 From: cool-rr at cool-rr.com (Ram Rachum) Date: Tue, 17 Nov 2009 17:42:41 +0000 (UTC) Subject: [Catalog-sig] Please help me use PyPI Message-ID: Hi all, I'm trying to release my project to PyPI today. I have three problems: (1.) I have 4 different forks for my project for Python versions 2.4, 2.5, 2.6 and 3.1. Should they all be on the same name in PyPI? (2.) I'm trying to upload an MSI. I'm doing `setup.py bdist_msi register upload`. It builds the project and the setup script finishes, but then I get: error: garlicsim-0.1: No such file or directory And no .msi file is uploaded to PyPi. Why? (3.) I tried uploading my 2.5 fork. It asks me to identify, I do, it gives an OK response (which doesn't happen unless the identification is right), but then it claims I didn't identify! Why? [...] removing 'build\bdist.win32\egg' (and everything under it) running register We need to know who you are, so please choose either: 1. use your existing login, 2. register as a new user, 3. have the server generate a new password for you (and email it to you), or 4. quit Your selection [default 1]: 1 Username: coolRR Password: Server response (200): OK running upload Submitting dist\garlicsim-0.1.zip to http://pypi.python.org/pypi Upload failed (401): You must be identified to edit package information removing 'build' (and everything under it) error: garlicsim-0.1: No such file or directory Thanks, Ram. From ssteinerx at gmail.com Tue Nov 17 19:09:33 2009 From: ssteinerx at gmail.com (ssteinerX@gmail.com) Date: Tue, 17 Nov 2009 13:09:33 -0500 Subject: [Catalog-sig] Do we really need this list? In-Reply-To: <4B02DD52.1020608@simplistix.co.uk> References: <4B02DD52.1020608@simplistix.co.uk> Message-ID: <0583036C-D2CF-4D45-8C2A-FC16545A46A5@gmail.com> On Nov 17, 2009, at 12:28 PM, Chris Withers wrote: > Hi All, > > Why do we not just use distutils-sig instead? > I don't think I've yet seen a discussion on this list that isn't > relevant to distutils-sig... "The Python Catalog SIG is the forum for development and discussion of indexes of Python packages." Seems to me that distutils-sig is about the tools that put stuff up into the catalogs that need to be discussed on catalog-sig. The catalog(s) is/are not the tools for creating things to go into it/ them. S From chris at simplistix.co.uk Tue Nov 17 19:10:56 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 17 Nov 2009 18:10:56 +0000 Subject: [Catalog-sig] Do we really need this list? In-Reply-To: <0583036C-D2CF-4D45-8C2A-FC16545A46A5@gmail.com> References: <4B02DD52.1020608@simplistix.co.uk> <0583036C-D2CF-4D45-8C2A-FC16545A46A5@gmail.com> Message-ID: <4B02E730.3070809@simplistix.co.uk> ssteinerX at gmail.com wrote: > > "The Python Catalog SIG is the forum for development and discussion of > indexes of Python packages." > > Seems to me that distutils-sig is about the tools that put stuff up into > the catalogs that need to be discussed on catalog-sig. > > The catalog(s) is/are not the tools for creating things to go into it/them. That may be, but discussions of one seem to invariably involve discussion of the other. It seems not many people know about catalog-sig anyway so the discussions end up on distutils-sig or, worse yet, python-dev... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From ssteinerx at gmail.com Tue Nov 17 19:12:57 2009 From: ssteinerx at gmail.com (ssteinerX@gmail.com) Date: Tue, 17 Nov 2009 13:12:57 -0500 Subject: [Catalog-sig] Do we really need this list? In-Reply-To: <4B02E730.3070809@simplistix.co.uk> References: <4B02DD52.1020608@simplistix.co.uk> <0583036C-D2CF-4D45-8C2A-FC16545A46A5@gmail.com> <4B02E730.3070809@simplistix.co.uk> Message-ID: <038E511C-9E52-43E6-A6AF-2C4EE87736D6@gmail.com> On Nov 17, 2009, at 1:10 PM, Chris Withers wrote: > ssteinerX at gmail.com wrote: >> "The Python Catalog SIG is the forum for development and discussion >> of indexes of Python packages." >> Seems to me that distutils-sig is about the tools that put stuff up >> into the catalogs that need to be discussed on catalog-sig. >> The catalog(s) is/are not the tools for creating things to go into >> it/them. > > That may be, but discussions of one seem to invariably involve > discussion of the other. It seems not many people know about catalog- > sig anyway so the discussions end up on distutils-sig or, worse yet, > python-dev... Discussions of whether you use Open-ID or whatever, for example, don't belong on distutils or python-dev. It's an issue relating to authentication to a catalog and doesn't have doodly to do with building distributions or developing python per se. S From martin at v.loewis.de Wed Nov 18 00:17:28 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 18 Nov 2009 00:17:28 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B02860A.1030505@simplistix.co.uk> References: <4222a8490911120831y5233e547pbfd22de60bcf436e@mail.gmail.com> <7AF4743F-4602-4E4C-8B8F-2FBC34D3945F@masklinn.net> <87vdhfwis8.fsf@benfinney.id.au> <4AFC8842.5050904@v.loewis.de> <805B874E-6FD5-44DB-A908-922C93866458@masklinn.net> <4AFC9C2C.9090408@v.loewis.de> <4AFECECF.6080301@simplistix.co.uk> <87zl6npiky.fsf_-_@benfinney.id.au> <87d43jpbrf.fsf@benfinney.id.au> <4B00F665.8080006@v.loewis.de> <20091116134806.27565.1560199253.divmod.xquotient.178@localhost.localdomain> <4B019F9D.9040300@v.loewis.de> <20091116214057.27565.1312606125.divmod.xquotient.231@localhost.localdomain> <4B01CD34.4090509@v.loewis.de> <4B01D036.8040507@egenix.com> <4B01D0E0.7070907@v.loewis.de> <4B02860A.1030505@simplistix.co.uk> Message-ID: <4B032F08.5080808@v.loewis.de> >>> Are you using python-openid for this ? >>> >>> http://openidenabled.com/python-openid/ >> >> No, I have written a new OpenID client. The protocol itself >> is fairly simple, once you got it. > > Why do this rather than using (and maybe improving) an existing library? It's not really any existing library. It's an OpenID provider (which also happens to implement a client). Regards, Martin From martin at v.loewis.de Wed Nov 18 00:24:04 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 18 Nov 2009 00:24:04 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B028C53.2010506@egenix.com> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> Message-ID: <4B033094.7060506@v.loewis.de> > Well, python-openid is written in Python, so it should be possible > to add whatever special functionality you need. For this, I would like to see contributions. I found myself that it is absolutely necessary to understand the actual message flow, so I couldn't have used the package before implementing a client myself - perhaps I might now be able to understand how to use it. For mod_auth_openid, I still cannot grasp how to use it. > With mod_auth_openid, you'd use a separate login page for the > OpenID login, so there wouldn't be a mixup between the two > variants. That would be unfortunate UI clutter, IMO. > Since you were looking for simplification of the used code, > it may be worthwhile looking at these two options to outsource > the complexity into a 3rd party tool. Both come with their own > session database to handle the authentication process sessions. Please go ahead and do so. > Note that I'm only suggesting to look at these things in > order to simplify the implementation. At least for python-openid, my feeling would be that it is actually more complicated to use the library than to write my own. For mod_auth_openid, a shallow glance also looks like using it would be quite some challenge. Regards, Martin From david.lyon at preisshare.net Wed Nov 18 00:36:47 2009 From: david.lyon at preisshare.net (David Lyon) Date: Tue, 17 Nov 2009 18:36:47 -0500 Subject: [Catalog-sig] =?utf-8?q?Do_we_really_need_this_list=3F?= In-Reply-To: <4B02E730.3070809@simplistix.co.uk> References: <4B02DD52.1020608@simplistix.co.uk> <0583036C-D2CF-4D45-8C2A-FC16545A46A5@gmail.com> <4B02E730.3070809@simplistix.co.uk> Message-ID: On Tue, 17 Nov 2009 18:10:56 +0000, Chris Withers wrote: > That may be, but discussions of one seem to invariably involve > discussion of the other. It seems not many people know about catalog-sig > anyway so the discussions end up on distutils-sig or, worse yet, > python-dev... Well, anybody is welcome to start a discussion on some relevant topic. For example, I don't mind seeing discussion on PEP-345. It was created in 2005 so that means it's been open for four years. Also, I've noticed that there are two distinct political camps with python packaging. One camp is the traditional pythoners who were there from day one, know all the tools, know the tools that they like, and know how to install them, manually if necessary. Generally speaking they are python centric and not interested in any other languages or even try them. That's ok. Let's call them specialists. The other camp are the ones who have come from the outside python and are used to perhaps alternate packaging solutions. Maybe this camp go from place to place and are exposed to different tools and have to make whatever they are given work. Lets call them corporate software contractors. Moving on... As some know, Guido posted a week or two back on getting python more functionally compatible with CPAN. Outsider's "know" that python lags perl (and other languages) in third-party package loading capability. It's not always possible to discuss those issues on distutils-ml because everything must be realistically implementable within the legacy code framework of distutils. A lot of PEP discussion should be high level and it should be driven from catalog-sig instead of distutils-sig imo. Especially PEP-345. Catalog-sig should be about the real world needs of packaging and distutils-sig should be about the implementation imho. within From tjreedy at udel.edu Wed Nov 18 00:52:52 2009 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 17 Nov 2009 18:52:52 -0500 Subject: [Catalog-sig] Please help me use PyPI In-Reply-To: References: Message-ID: Ram Rachum wrote: > Hi all, > > I'm trying to release my project to PyPI today. > > I have three problems: > > (1.) I have 4 different forks for my project for Python versions 2.4, 2.5, 2.6 > and 3.1. Should they all be on the same name in PyPI? I suggest you look at http://pypi.python.org/pypi/an_example_pypi_project/0.0.5 One project, several files for both different Python versions and differen packaging type, including an msi. I notice that garlicsim (new version uploaded, just by coindidence) has separate projects for each Python release (2.4, 2.5, 2.6, 3.1), but I am not sure that is normal. I think I would personally prefer just one unless there is a technical reason otherwise. > > (2.) I'm trying to upload an MSI. I'm doing `setup.py bdist_msi register > upload`. It builds the project and the setup script finishes, but then I get: > > error: garlicsim-0.1: No such file or directory > > And no .msi file is uploaded to PyPi. Why? > > (3.) I tried uploading my 2.5 fork. It asks me to identify, I do, it gives an OK > response (which doesn't happen unless the identification is right), but then it > claims I didn't identify! Why? > > [...] > removing 'build\bdist.win32\egg' (and everything under it) > running register > We need to know who you are, so please choose either: > 1. use your existing login, > 2. register as a new user, > 3. have the server generate a new password for you (and email it to you), > or > 4. quit > Your selection [default 1]: 1 > Username: coolRR > Password: > Server response (200): OK > running upload > Submitting dist\garlicsim-0.1.zip to http://pypi.python.org/pypi > Upload failed (401): You must be identified to edit package information > removing 'build' (and everything under it) > error: garlicsim-0.1: No such file or directory > > Thanks, > Ram. From paul at boddie.org.uk Wed Nov 18 01:26:15 2009 From: paul at boddie.org.uk (Paul Boddie) Date: Wed, 18 Nov 2009 01:26:15 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B023836.2060901@v.loewis.de> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> Message-ID: <200911180126.15960.paul@boddie.org.uk> On Tuesday 17 November 2009 06:44:22 Martin v. L?wis wrote: > [mod_auth_openid] > The problem I have with this (and also partially with python-openid) is > that I don't know how to integrate it with the existing application. How > is the module supposed to know what PyPI accounts are, and how they > relate to existing IDs, and what postgres database and table this > information is to be stored in? Since OpenID is an authentication solution, you should probably just accept the claimed identity as the username. In fact, mod_auth_openid provides this as the REMOTE_USER CGI environment variable. If you then want to associate this information with things like e-mail addresses, you can do this using the normal dialogues presumably implemented for this purpose - it's not as optimal as asking the OpenID infrastructure for such information, but it's nothing the application isn't doing already. Such integration of authentication details is only awkward if applications aren't designed to deal with REMOTE_USER or make special assumptions about the nature of such information. Bugzilla, for instance, would rather you have an e-mail address as a username, and in the "authentication pass-through" mode (or whatever it's called) this imposes constraints on the usernames employed in the actual authentication solution deployed in front of Bugzilla. > For Roundup, the problem is even more difficult, IIUC, assuming I want > people to add either an openid or a username/password pair into the > existing fields: how is mod_auth_openid supposed to know that the name > is not an openid in the first place, just because a password is also > provided? The roundup installation uses a reverse proxy, so it would > be better to create something that doesn't rely on Apache. I can see that a hybrid solution could be a problem. The worst case might involve having two separate URLs for the entire application, if Apache insists on guarding the application with a specific authentication solution, not setting REMOTE_USER outside that URL hierarchy, and preventing people getting to a public page within that hierarchy to log in the traditional way. Paul P.S. Once upon a time I had a brief encounter with an Apache module for the Sun single sign-on technology SAML (which led to the Liberty Alliance stuff), and that probably also fed the identity via the standard REMOTE_USER variable, too. From david.lyon at preisshare.net Wed Nov 18 04:07:15 2009 From: david.lyon at preisshare.net (David Lyon) Date: Tue, 17 Nov 2009 22:07:15 -0500 Subject: [Catalog-sig] Package Quality Measurement for packages on Pypi Message-ID: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> > (cut from python-dev) > On Fri, 13 Nov 2009 01:14:54 +0100, "Martin v. L?wis" > wrote: > >> http://pycheesecake.org/ > > > Apparently, there is a service running somewhere that computes cheesecake > data for PyPI packages; > it also sends them to PyPI. People have expressed to concerns that any > kind of ranking based on kwalitee sounds fairly useless. I've had a look at this and been able to run the assessments locally on a number of packages that I've been able to download from pypi. It's interesting. I totally agree that some people might have issues with the terminology being used there. What if the terminology could be cleaned up? And the tests extended? What do you think would be more meaningful in terms of output? In regards to something that could be useful for potential publishing on pypi. David From ubernostrum at gmail.com Wed Nov 18 04:48:00 2009 From: ubernostrum at gmail.com (James Bennett) Date: Tue, 17 Nov 2009 21:48:00 -0600 Subject: [Catalog-sig] Package Quality Measurement for packages on Pypi In-Reply-To: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> References: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> Message-ID: <21787a9f0911171948sacdfc3fm344be13ce870a8e2@mail.gmail.com> On Tue, Nov 17, 2009 at 9:07 PM, David Lyon wrote: > What if the terminology could be cleaned up? And the tests extended? The terminology is perhaps a bit too humorous for PyPI, but a couple friends of mine put this together for a Django hack weekend: http://pypants.org/ See an example report here: http://pypants.org/projects/webcolors/1.3.1/evaluations/6137/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." From martin at v.loewis.de Wed Nov 18 06:46:43 2009 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Wed, 18 Nov 2009 06:46:43 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <200911180126.15960.paul@boddie.org.uk> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <200911180126.15960.paul@boddie.org.uk> Message-ID: <4B038A43.60408@v.loewis.de> >> The problem I have with this (and also partially with python-openid) is >> that I don't know how to integrate it with the existing application. How >> is the module supposed to know what PyPI accounts are, and how they >> relate to existing IDs, and what postgres database and table this >> information is to be stored in? > > Since OpenID is an authentication solution, you should probably just accept > the claimed identity as the username. It can't work that way, and shouldn't. First, OpenID defines the Simple Registration extensions (SREG) to explicitly cover a nickname, and also provide an email address. Whether or not I trust these data - at a minimum, I should use them - that's what OpenID users expect to happen. I see that mod_auth_openid has some support for AX (a similar protocol) since 0.3, and that may also support SREG, but again, I'm unsure how to use it. In addition, existing users will expect to be able to use OpenID, and will expect to be able to map OpenIDs to existing accounts. > In fact, mod_auth_openid provides this as the REMOTE_USER CGI > environment variable. That can work for logins, but not for registrations. Regards, Martin From ben+python at benfinney.id.au Wed Nov 18 08:39:12 2009 From: ben+python at benfinney.id.au (Ben Finney) Date: Wed, 18 Nov 2009 18:39:12 +1100 Subject: [Catalog-sig] OpenID login to PyPI References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <200911180126.15960.paul@boddie.org.uk> <4B038A43.60408@v.loewis.de> Message-ID: <87tywsl1sv.fsf@benfinney.id.au> "Martin v. L?wis" writes: > > Since OpenID is an authentication solution, you should probably just > > accept the claimed identity as the username. > > It can't work that way, and shouldn't. First, OpenID defines the > Simple Registration extensions (SREG) to explicitly cover a nickname, > and also provide an email address. Whether or not I trust these data - > at a minimum, I should use them - that's what OpenID users expect to > happen. Martin is correct here. The ?nickname? field is expected to become the username for the newly-registered site-local account. -- \ ?It's my belief we developed language because of our deep inner | `\ need to complain.? ?Jane Wagner, via Lily Tomlin | _o__) | Ben Finney From mal at egenix.com Wed Nov 18 11:56:03 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 18 Nov 2009 11:56:03 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B033094.7060506@v.loewis.de> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> Message-ID: <4B03D2C3.8060104@egenix.com> "Martin v. L?wis" wrote: >> Well, python-openid is written in Python, so it should be possible >> to add whatever special functionality you need. > > For this, I would like to see contributions. > > I found myself that it is absolutely necessary to understand the actual > message flow, so I couldn't have used the package before implementing > a client myself - perhaps I might now be able to understand how to use > it. For mod_auth_openid, I still cannot grasp how to use it. > >> With mod_auth_openid, you'd use a separate login page for the >> OpenID login, so there wouldn't be a mixup between the two >> variants. > > That would be unfortunate UI clutter, IMO. > >> Since you were looking for simplification of the used code, >> it may be worthwhile looking at these two options to outsource >> the complexity into a 3rd party tool. Both come with their own >> session database to handle the authentication process sessions. > > Please go ahead and do so. > >> Note that I'm only suggesting to look at these things in >> order to simplify the implementation. > > At least for python-openid, my feeling would be that it is actually > more complicated to use the library than to write my own. > > For mod_auth_openid, a shallow glance also looks like using it > would be quite some challenge. Like I said in my email: I'm not a fan of OpenID and don't understand why so much complexity has to be added just to avoid letting a browser fill in the username/password automatically. My suggestions were only targeting your statement that you want to keep the code simple. If you don't think that's possible using python-openid or Paul's suggestion to use mod_auth_openid, that's fine. Regarding contributing to the PyPI implementation: I'm not aware of how this could be done. To me, PyPI appears to be a closed application that is solely under your control. After some searching I did find what appears to be the repository of the currently used code base: https://svn.python.org/packages/trunk/pypi/ However, it is not clear how this is deployed on the pypi.python.org server. Is there a staging installation to be used for testing ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 18 2009) >>> 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 paul at boddie.org.uk Wed Nov 18 20:10:15 2009 From: paul at boddie.org.uk (Paul Boddie) Date: Wed, 18 Nov 2009 20:10:15 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B038A43.60408@v.loewis.de> References: <200911162353.47873.paul@boddie.org.uk> <200911180126.15960.paul@boddie.org.uk> <4B038A43.60408@v.loewis.de> Message-ID: <200911182010.15920.paul@boddie.org.uk> On Wednesday 18 November 2009 06:46:43 Martin v. L?wis wrote: > > > Since OpenID is an authentication solution, you should probably just > > accept the claimed identity as the username. > > It can't work that way, and shouldn't. First, OpenID defines the Simple > Registration extensions (SREG) to explicitly cover a nickname, and also > provide an email address. Whether or not I trust these data - at a > minimum, I should use them - that's what OpenID users expect to happen. I misinterpreted what you wrote, there. Yes, there's probably a difficulty in presenting a single page to all users and letting them type in a username (or identifier) and having a single piece of software work out whether they can authenticate that person or not. Some kind of pass-through from mod_auth_openid to the existing solution would be necessary, aside from having separate entry points to the application. I was actually just saying that the claimed identity is the thing that you'd probably end up with as the "username" from mod_auth_openid, and that's the only thing you'd ever need to actually tell users apart. Certainly, I wouldn't want to put anything else in my users table. Ben Finney wrote: "Martin is correct here. The ?nickname? field is expected to become the username for the newly-registered site-local account." SREG doesn't guarantee that a nickname exists for an identity, and whether the user wants their identity to be displayed using a particular nickname is separate from the nature of their identity itself. Sure, you could let people use nicknames to log in (having associated a specific identity with a nickname) on a first-come first-served basis, but the claimed identity would still have to float around in the application somewhere. > I see that mod_auth_openid has some support for AX (a similar protocol) > since 0.3, and that may also support SREG, but again, I'm unsure how to > use it. I guess it could be used (presumably via various environment variables, but I don't know) to pre-fill any registration or preference details. > In addition, existing users will expect to be able to use OpenID, and > will expect to be able to map OpenIDs to existing accounts. This is where you'd probably have to do some work, yes. > > In fact, mod_auth_openid provides this as the REMOTE_USER CGI > > environment variable. > > That can work for logins, but not for registrations. Well, upon authenticating themselves - providing their OpenID identity - you'd be able to tell whether the application knows them from before by seeing if that identity is recorded anywhere. If it isn't, you could send the user to a registration page where they get to fill out their e-mail address and other details. OpenID is, after all, only an authentication technology. What you do with the user identity and whether you let the user in or trust them in any way is an authorisation problem. I'm not saying that mod_auth_openid will solve all problems instantly, but I just thought that it could do a lot of the work and minimise changes to the applications, and that's presumably what its developers intended. Paul From tjreedy at udel.edu Wed Nov 18 20:32:24 2009 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 18 Nov 2009 14:32:24 -0500 Subject: [Catalog-sig] Package Quality Measurement for packages on Pypi In-Reply-To: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> References: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> Message-ID: David Lyon wrote: >> (cut from python-dev) >> On Fri, 13 Nov 2009 01:14:54 +0100, "Martin v. L?wis" > >> wrote: >> >>> http://pycheesecake.org/ >> >> Apparently, there is a service running somewhere that computes cheesecake > >> data for PyPI packages; >> it also sends them to PyPI. People have expressed to concerns that any >> kind of ranking based on kwalitee sounds fairly useless. I would like to see something like Cheesecake rating NNN/MMM where the rating links to the full report so I can decide whether the missed points are things I am concerned about or not. > I've had a look at this and been able to run the assessments locally > on a number of packages that I've been able to download from pypi. It's > interesting. The fact that a 3rd party can download, install, and run the assessment indicates that it meets some bare miminum of quality. The system used should be included in the report. > I totally agree that some people might have issues with the terminology > being used there. I remember being dissed for opining that 'cheeseshop' was too much of an esoteric and cutesy insider joke to be the public name and url for the catalog. While I appreciate that 'kwalitee' is intended to evade discussion about whether it really measures 'quality', I can see how someone who had not read the explanation could be put off by it. 'Cheesecake rating' is pretty neutral, which still paying homage to M.P. > What if the terminology could be cleaned up? And the tests extended? If the main directly includes 'test_all.py', that could potentially be run and the last line of the result reported, and bonus points given for passing. Perhaps some standard is needed for reporting success. Another possibility with binaries to run a checksum and then a virus checker. The report should be something neutral like "Virus checker xxx found no problems with binary a.b with checksum MMM." As a Windows user, I worry about the possibility of a malware author masquerading as a fake developer, or even just a real developer unknowingly having a clever virus that silently somehow piggybacks on exported binaries. I believe there are websites that will run multiple checkers on submitted files. Perhaps PyPI should push in the direction of Python download pages like http://python.org/download/releases/3.1.1/ reporting "The source tarballs is signed with Benjamin Peterson's key (fingerprint: 12EF 3DC3 8047 DA38 2D18 A5B9 99CD EA9D A413 5B38). The Windows installers was signed by Martin von L?wis' public key which has a key id of 7D9DC8D2. The public keys are located on the download page. MD5 checksums and sizes of the released files: f1317dbb2398374d6691edd5bff1b91d 11525876 python-3.1.1.tgz d1ddd9f16e3c6a51c7208f33518cd674 9510105 python-3.1.1.tar.bz2 d31e3e91c2ddd3e5ea7c40abe436917e 14130176 python-3.1.1.amd64.msi e05a6134b920ae86f0e33b8a43a801b3 13737984 python-3.1.1.msi 9c7f85cc7fb5a2fa533d338c88229633 17148746 python-3.1.1.dmg " (What is missing there is info on how to use this information ;-). > What do you think would be more meaningful in terms of output? In regards > to something that could be useful for potential publishing on pypi. Terry Jan Reedy From robert.kern at gmail.com Wed Nov 18 21:33:27 2009 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 18 Nov 2009 14:33:27 -0600 Subject: [Catalog-sig] Package Quality Measurement for packages on Pypi In-Reply-To: References: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> Message-ID: On 2009-11-18 13:32 PM, Terry Reedy wrote: > David Lyon wrote: >>> (cut from python-dev) >>> On Fri, 13 Nov 2009 01:14:54 +0100, "Martin v. L?wis" >> >>> wrote: >>> >>>> http://pycheesecake.org/ >>> >>> Apparently, there is a service running somewhere that computes >>> cheesecake >> >>> data for PyPI packages; >>> it also sends them to PyPI. People have expressed to concerns that any >>> kind of ranking based on kwalitee sounds fairly useless. > > I would like to see something like > Cheesecake rating NNN/MMM > where the rating links to the full report so I can decide whether the > missed points are things I am concerned about or not. Personally, I don't want to see any aggregates of incommensurable observations ever. I don't mind seeing a dashboard of individual observations (even if I disagree with many of the individual measurements), but aggregating them with arbitrary weights into a single score is simply wrong. I disagree with including user ratings, too, for much the same reasons. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From martin at v.loewis.de Wed Nov 18 23:52:17 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 18 Nov 2009 23:52:17 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <4B03D2C3.8060104@egenix.com> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> <4B03D2C3.8060104@egenix.com> Message-ID: <4B047AA1.9050302@v.loewis.de> > However, it is not clear how this is deployed on the > pypi.python.org server. Is there a staging installation > to be used for testing ? See http://wiki.python.org/moin/CheeseShopDev Regards, Martin From martin at v.loewis.de Thu Nov 19 00:00:06 2009 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Thu, 19 Nov 2009 00:00:06 +0100 Subject: [Catalog-sig] OpenID login to PyPI In-Reply-To: <200911182010.15920.paul@boddie.org.uk> References: <200911162353.47873.paul@boddie.org.uk> <200911180126.15960.paul@boddie.org.uk> <4B038A43.60408@v.loewis.de> <200911182010.15920.paul@boddie.org.uk> Message-ID: <4B047C76.5050704@v.loewis.de> > I'm not saying that mod_auth_openid will solve all problems instantly, but I > just thought that it could do a lot of the work and minimise changes to the > applications, and that's presumably what its developers intended. For me, it feels that the only possible users of an openid client implementation are the authors of that implementation. At least for the ones I have looked up, I just don't get how I'm supposed to use it. So: contributions are welcome. Regards, Martin From david.lyon at preisshare.net Thu Nov 19 00:02:33 2009 From: david.lyon at preisshare.net (David Lyon) Date: Wed, 18 Nov 2009 18:02:33 -0500 Subject: [Catalog-sig] Package Quality Measurement for packages on Pypi In-Reply-To: References: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> Message-ID: <156be7cf76473f56e97a1e7408612e12@preisshare.net> On Wed, 18 Nov 2009 14:33:27 -0600, Robert Kern wrote: > Personally, I don't want to see any aggregates of incommensurable > observations > ever. I don't mind seeing a dashboard of individual observations (even if I > > disagree with many of the individual measurements), but aggregating them > with > arbitrary weights into a single score is simply wrong. I disagree with > including > user ratings, too, for much the same reasons. I'm not sure if CPANTS displays their findings/ratings to package users on CPAN either. I think you have to navigate to a seperate site to see the grade. The purpose of testing packages isn't to warn users off a package, say, because it has no docstrings. It's about taking their package, running the internal test suite on a number of different platforms (windows, linux, mac), checking that it installs properly with distribute/setuptools/distutils/pip. After that, to probe it and put some numbers (ratings) on what is and isn't done. Like documentation, tests, pylint, pep8. Any new package writer would expect to submit a package and get a rating in the C or D range (if graded with letters). With some extra polishing, you'd expect them to be interested in moving their package up into the A or B range. I can't see why it would be so wrong to give them tools that would allow them to do something like that. Otherwise, there's no incentive to try to make things good. Because it looks like nobody cares. Ratings to assist a package developer identify weaknesses are a good thing. Both for the developer and for the python community at large.. David From robert.kern at gmail.com Thu Nov 19 00:42:19 2009 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 18 Nov 2009 17:42:19 -0600 Subject: [Catalog-sig] Package Quality Measurement for packages on Pypi In-Reply-To: <156be7cf76473f56e97a1e7408612e12@preisshare.net> References: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> <156be7cf76473f56e97a1e7408612e12@preisshare.net> Message-ID: On 2009-11-18 17:02 PM, David Lyon wrote: > On Wed, 18 Nov 2009 14:33:27 -0600, Robert Kern > wrote: >> Personally, I don't want to see any aggregates of incommensurable >> observations >> ever. I don't mind seeing a dashboard of individual observations (even if > I >> >> disagree with many of the individual measurements), but aggregating them >> with >> arbitrary weights into a single score is simply wrong. I disagree with >> including >> user ratings, too, for much the same reasons. > > I'm not sure if CPANTS displays their findings/ratings to package users > on CPAN either. I think you have to navigate to a seperate site to see > the grade. > > The purpose of testing packages isn't to warn users off a package, say, > because it has no docstrings. It's about taking their package, running the > internal test suite on a number of different platforms (windows, linux, > mac), > checking that it installs properly with > distribute/setuptools/distutils/pip. > > After that, to probe it and put some numbers (ratings) on what is > and isn't done. Like documentation, tests, pylint, pep8. > > Any new package writer would expect to submit a package and get a rating > in the C or D range (if graded with letters). With some extra polishing, > you'd expect them to be interested in moving their package up into the > A or B range. Personally, I am entirely uninterested in moving up grades. I am interested in having good, discoverable documentation, easy and robust builds, good test coverage, etc. I object thoroughly to the idea that I *should* care about such a meaningless aggregate grade rather than the specific, individual issues uncovered by the tests. > I can't see why it would be so wrong to give them tools that would allow > them to do something like that. Otherwise, there's no incentive to try > to make things good. Because it looks like nobody cares. Making your package work well has a plethora of incentives that are entirely unrelated to, and are not helped by, an automated grading system. Of course people care, and all package makers understand that. If we didn't think people cared about our packages, we wouldn't release them. An automated build/test/style-check service is great. By all means, continue your work. It provides actual value to the community. Just don't try to mash together a variety of disparate measurements into an arbitrary, meaningless grade. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From lists at zopyx.com Thu Nov 19 07:02:31 2009 From: lists at zopyx.com (Andreas Jung) Date: Thu, 19 Nov 2009 07:02:31 +0100 Subject: [Catalog-sig] Package Quality Measurement for packages on Pypi In-Reply-To: References: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> <156be7cf76473f56e97a1e7408612e12@preisshare.net> Message-ID: <4B04DF77.4030302@zopyx.com> Am 19.11.09 00:42, schrieb Robert Kern: > > Personally, I am entirely uninterested in moving up grades. I am > interested in having good, discoverable documentation, Amen. Any PyPI package release w/o proper metadata and without reasonable description/documentation is a broken release and should be banned from PyPI. Package quality starts with your metadata and the willingness of a package maintainer fulfilling certain minimum standards. Andreas -- ZOPYX Ltd. & Co KG \ zopyx group Charlottenstr. 37/1 \ The full-service network for your D-72070 T?bingen \ Python, Zope and Plone projects www.zopyx.com, info at zopyx.com \ www.zopyxgroup.com ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available URL: From mal at egenix.com Thu Nov 19 11:15:17 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 19 Nov 2009 11:15:17 +0100 Subject: [Catalog-sig] PyPI Development In-Reply-To: <4B047AA1.9050302@v.loewis.de> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> <4B03D2C3.8060104@egenix.com> <4B047AA1.9050302@v.loewis.de> Message-ID: <4B051AB5.7020303@egenix.com> "Martin v. L?wis" wrote: >> However, it is not clear how this is deployed on the >> pypi.python.org server. Is there a staging installation >> to be used for testing ? > > See > > http://wiki.python.org/moin/CheeseShopDev Thanks for the link... I should have searched for "CheeseShop" instead of "PyPI". I'd like to work on adding support for registering more package download information, including the possibility to register download links (as opposed to uploading files to PyPI itself) and more information on the intended target platform and Python version of a particular download resource. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 19 2009) >>> 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 mal at egenix.com Thu Nov 19 11:37:32 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 19 Nov 2009 11:37:32 +0100 Subject: [Catalog-sig] Extending the package meta-data with more detailed download information Message-ID: <4B051FEC.3050905@egenix.com> In the current or intended next vesion (1.2 - see PEP 345), the package meta data does not include any machine usable form of defining download URLs for particular platforms, Python versions and variants. The only entry we have is: """ Download-URL A string containing the URL from which this version of the package can be downloaded. (This means that the URL can't be something like ".../package-latest.tgz", but instead must be ".../package-0.45.tgz".) """ which may be usable by a developer looking for the download links, but isn't really suited for package managers to use. PyPI has already extended the meta-data information to include uploaded files, but only makes this information available via the RPC interface. Now I'm not sure whether such download information should be part of the package's meta-data, but do see a point in having all package related information in one place for easy access by package managers and developers. I would like to extend the available download information to make automated downloads more reliable. Here's a list of things that would be needed: * Distribution type (sdist, bdist_egg, bdist_msi, bdist_wininst, etc.) * Distribution URL (full URL of the download file) * Distribution Comment (any text) * Distribution MD5 digest (as HEX string) * Distribution SHA1 digest (as HEX string) * Distribution PGP signature (as string) * Distribution variant (list defined by the package) * Python implementation (CPython, Jython, etc.) * Python version (2.5, 3.1, etc.) * Python build variant (UCS2, UCS4) * OS identifier (Windows, Linux, Mac OS X, FreeBSD, etc.) * OS version (XP, 2, 10.4, 7, etc.) * Architecture identifier (x86, x64, ppc, ppc64, sparc, sparc64, etc.) * Processor identifier (i386, i686, arm, etc.) (more, if needed) Some of these would be optional, or could be set to 'n/a' if not applicable to the distribution. distutils should then get a new API for matching the available download information to the currently running Python interpreter (but that's to be discussed on distutils-sig). Thoughts ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 19 2009) >>> 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 david.lyon at preisshare.net Thu Nov 19 15:29:32 2009 From: david.lyon at preisshare.net (David Lyon) Date: Thu, 19 Nov 2009 09:29:32 -0500 Subject: [Catalog-sig] Extending the package meta-data with more detailed download information In-Reply-To: <4B051FEC.3050905@egenix.com> References: <4B051FEC.3050905@egenix.com> Message-ID: <0a8edd4be4e59dd32ebf73a185c49af9@preisshare.net> On Thu, 19 Nov 2009 11:37:32 +0100, "M.-A. Lemburg" wrote: > In the current or intended next vesion (1.2 - see PEP 345), the > package meta data does not include any machine usable form of > defining download URLs for particular platforms, Python versions > and variants. > > The only entry we have is: > > """ > Download-URL > A string containing the URL from which this version of the package can > be downloaded. (This > means that the URL can't be something like ".../package-latest.tgz", but > instead must be > ".../package-0.45.tgz".) > """ > > which may be usable by a developer looking for the download links, > but isn't really suited for package managers to use. > > PyPI has already extended the meta-data information to include uploaded > files, but only makes this information available via the RPC interface. Which imo is entirely satisfactory. > Now I'm not sure whether such download information should be part > of the package's meta-data, but do see a point in having all package > related information in one place for easy access by package managers > and developers. The key thing for imho now is to have the dependencies available in the metadata. > I would like to extend the available download information to make > automated downloads more reliable. Here's a list of things that > would be needed: > > * Distribution type (sdist, bdist_egg, bdist_msi, bdist_wininst, etc.) > * Distribution URL (full URL of the download file) > * Distribution Comment (any text) > * Distribution MD5 digest (as HEX string) > * Distribution SHA1 digest (as HEX string) > * Distribution PGP signature (as string) > * Distribution variant (list defined by the package) We could. To me these things are a little fluffy. One could ask how much value they actually add. > * Python implementation (CPython, Jython, etc.) > * Python version (2.5, 3.1, etc.) > * Python build variant (UCS2, UCS4) Definitely. But these are already slated to go in aren't they? with the conditionals specification. > * OS identifier (Windows, Linux, Mac OS X, FreeBSD, etc.) > * OS version (XP, 2, 10.4, 7, etc.) > * Architecture identifier (x86, x64, ppc, ppc64, sparc, sparc64, etc.) > * Processor identifier (i386, i686, arm, etc.) These were discussed on distutils a little during the year. > Some of these would be optional, or could be set to 'n/a' if > not applicable to the distribution. Or just left out. > distutils should then get a new API for matching the available > download information to the currently running Python interpreter > (but that's to be discussed on distutils-sig). > > Thoughts ? They're good thoughts. David From mal at egenix.com Thu Nov 19 16:06:41 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 19 Nov 2009 16:06:41 +0100 Subject: [Catalog-sig] PyPI Development In-Reply-To: <4B051AB5.7020303@egenix.com> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> <4B03D2C3.8060104@egenix.com> <4B047AA1.9050302@v.loewis.de> <4B051AB5.7020303@egenix.com> Message-ID: <4B055F01.4030208@egenix.com> M.-A. Lemburg wrote: > "Martin v. L?wis" wrote: >>> However, it is not clear how this is deployed on the >>> pypi.python.org server. Is there a staging installation >>> to be used for testing ? >> >> See >> >> http://wiki.python.org/moin/CheeseShopDev > > Thanks for the link... I should have searched for "CheeseShop" > instead of "PyPI". > > I'd like to work on adding support for registering more package > download information, including the possibility to register > download links (as opposed to uploading files to PyPI itself) > and more information on the intended target platform and > Python version of a particular download resource. I'm getting a permission denied when trying to do a checkout using this URL (taken from the wiki page): svn+ssh://svn.python.org/data/repos/packages/trunk/pypi Has the URL changed or do I have to use some other setup on the client side than for Python SVN access ? Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 19 2009) >>> 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 Thu Nov 19 20:47:48 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 19 Nov 2009 20:47:48 +0100 Subject: [Catalog-sig] PyPI Development In-Reply-To: <4B051AB5.7020303@egenix.com> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> <4B03D2C3.8060104@egenix.com> <4B047AA1.9050302@v.loewis.de> <4B051AB5.7020303@egenix.com> Message-ID: <4B05A0E4.8030207@v.loewis.de> > I'd like to work on adding support for registering more package > download information, including the possibility to register > download links (as opposed to uploading files to PyPI itself) > and more information on the intended target platform and > Python version of a particular download resource. Sure! Let me know if you run into problems. Regards, Martin From martin at v.loewis.de Thu Nov 19 20:52:34 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 19 Nov 2009 20:52:34 +0100 Subject: [Catalog-sig] PyPI Development In-Reply-To: <4B055F01.4030208@egenix.com> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> <4B03D2C3.8060104@egenix.com> <4B047AA1.9050302@v.loewis.de> <4B051AB5.7020303@egenix.com> <4B055F01.4030208@egenix.com> Message-ID: <4B05A202.4050306@v.loewis.de> > I'm getting a permission denied when trying to do a checkout > using this URL (taken from the wiki page): > > svn+ssh://svn.python.org/data/repos/packages/trunk/pypi > > Has the URL changed or do I have to use some other setup > on the client side than for Python SVN access ? Just go with the read-only checkout for the moment. This specific URL only works for Richard Jones; I personally use the https checkout myself to commit, as well. In any case, it's separate from the python-dev setup. Regards, Martin From sridharr at activestate.com Thu Nov 19 21:11:01 2009 From: sridharr at activestate.com (Sridhar Ratnakumar) Date: Thu, 19 Nov 2009 12:11:01 -0800 Subject: [Catalog-sig] Package Quality Measurement for packages on Pypi In-Reply-To: <4B04DF77.4030302@zopyx.com> References: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> <156be7cf76473f56e97a1e7408612e12@preisshare.net> <4B04DF77.4030302@zopyx.com> Message-ID: On Wed, 18 Nov 2009 22:02:31 -0800, Andreas Jung wrote: > Am 19.11.09 00:42, schrieb Robert Kern: >> >> Personally, I am entirely uninterested in moving up grades. I am >> interested in having good, discoverable documentation, > > Amen. Any PyPI package release w/o proper metadata and without > reasonable description/documentation > is a broken release and should be banned from PyPI. Package quality > starts with your metadata and > the willingness of a package maintainer fulfilling certain minimum > standards. I agree about metadata (not sure about documentation). Based on what I see from building packages[1] for PyPM, most packages fail due to one of the following reasons: 1) Missing PKG-INFO file (the author did not use the `sdist` command). Twisted, IMDBPy are some examples. 2) Trying to read a non-existent file from setup.py (eg: author forgot to include README.txt in the tarball -- buggy MANIFEST.in?) 3) no setup.py 4) reading stdin in setup.py (so the "setup.py build" runs indefinitely) 5) no downloads URL (no tarballs either) 7) Import itself in setup.py (foo-0.1.tar.gz/setup.py has "import foo" -- and that in turns imports uninstalled deps) 6) Missing "build dependencies" (many packages try to import numpy.distutils/twisted so on) Other failures usually include missing library dependencies (libxml, for instance) or some Python syntax error. -srid PS: Now that we have the build infrastructure that periodically (i.e., every day) builds packages from PyPI, I might experiment with measuring the core "installability" rating for all packages sometimes during the weekend. *** [1] reports at http://pypm.activestate.com/ From ubernostrum at gmail.com Thu Nov 19 22:14:15 2009 From: ubernostrum at gmail.com (James Bennett) Date: Thu, 19 Nov 2009 15:14:15 -0600 Subject: [Catalog-sig] Package Quality Measurement for packages on Pypi In-Reply-To: References: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> <156be7cf76473f56e97a1e7408612e12@preisshare.net> <4B04DF77.4030302@zopyx.com> Message-ID: <21787a9f0911191314x24391525ib7389720649a0782@mail.gmail.com> On Thu, Nov 19, 2009 at 2:11 PM, Sridhar Ratnakumar wrote: > 7) Import itself in setup.py (foo-0.1.tar.gz/setup.py has "import foo" -- > and that in turns imports uninstalled deps) Although that's not *always* a problem, and so I'd be wary of automatically flagging it. Django's setup.py, for example, does an import from Django, but only to get a function which outputs a version number for packaging (and which lives in Django itself since it's used in various places). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." From ben+python at benfinney.id.au Thu Nov 19 23:48:56 2009 From: ben+python at benfinney.id.au (Ben Finney) Date: Fri, 20 Nov 2009 09:48:56 +1100 Subject: [Catalog-sig] PyPI Development References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> <4B03D2C3.8060104@egenix.com> <4B047AA1.9050302@v.loewis.de> <4B051AB5.7020303@egenix.com> <4B055F01.4030208@egenix.com> <4B05A202.4050306@v.loewis.de> Message-ID: <87r5rugmg7.fsf@benfinney.id.au> "Martin v. L?wis" writes: > > I'm getting a permission denied when trying to do a checkout > > using this URL (taken from the wiki page): > > > > svn+ssh://svn.python.org/data/repos/packages/trunk/pypi > > > > Has the URL changed or do I have to use some other setup > > on the client side than for Python SVN access ? > > Just go with the read-only checkout for the moment. This specific URL > only works for Richard Jones; I personally use the https checkout > myself to commit, as well. I don't have an account on ?svn.python.org?. How can I get a read-only checkout of the Subversion repository of the PyPI code? Neither of HTTP (error 404) nor HTTPS (HTTP authentication required) work for me with the above hostname and path. -- \ ?Guaranteed to work throughout its useful life.? ?packaging for | `\ clockwork toy, Hong Kong | _o__) | Ben Finney From ssteinerx at gmail.com Thu Nov 19 23:58:16 2009 From: ssteinerx at gmail.com (ssteinerX@gmail.com) Date: Thu, 19 Nov 2009 17:58:16 -0500 Subject: [Catalog-sig] PyPI Development In-Reply-To: <87r5rugmg7.fsf@benfinney.id.au> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> <4B03D2C3.8060104@egenix.com> <4B047AA1.9050302@v.loewis.de> <4B051AB5.7020303@egenix.com> <4B055F01.4030208@egenix.com> <4B05A202.4050306@v.loewis.de> <87r5rugmg7.fsf@benfinney.id.au> Message-ID: This worked for me just now: svn co https://svn.python.org/packages/trunk S On Nov 19, 2009, at 5:48 PM, Ben Finney wrote: > "Martin v. L?wis" writes: > >>> I'm getting a permission denied when trying to do a checkout >>> using this URL (taken from the wiki page): >>> >>> svn+ssh://svn.python.org/data/repos/packages/trunk/pypi >>> >>> Has the URL changed or do I have to use some other setup >>> on the client side than for Python SVN access ? >> >> Just go with the read-only checkout for the moment. This specific URL >> only works for Richard Jones; I personally use the https checkout >> myself to commit, as well. > > I don't have an account on ?svn.python.org?. How can I get a read-only > checkout of the Subversion repository of the PyPI code? > > Neither of HTTP (error 404) nor HTTPS (HTTP authentication required) > work for me with the above hostname and path. > > -- > \ ?Guaranteed to work throughout its useful life.? ?packaging for | > `\ clockwork toy, Hong Kong | > _o__) | > Ben Finney > > _______________________________________________ > Catalog-SIG mailing list > Catalog-SIG at python.org > http://mail.python.org/mailman/listinfo/catalog-sig From ben+python at benfinney.id.au Fri Nov 20 00:18:29 2009 From: ben+python at benfinney.id.au (Ben Finney) Date: Fri, 20 Nov 2009 10:18:29 +1100 Subject: [Catalog-sig] PyPI Development References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> <4B03D2C3.8060104@egenix.com> <4B047AA1.9050302@v.loewis.de> <4B051AB5.7020303@egenix.com> <4B055F01.4030208@egenix.com> <4B05A202.4050306@v.loewis.de> <87r5rugmg7.fsf@benfinney.id.au> Message-ID: <876396gl2y.fsf@benfinney.id.au> "ssteinerX at gmail.com" writes: > This worked for me just now: > > svn co https://svn.python.org/packages/trunk Okay, so ?the HTTPS checkout? isn't a simple substitiution of the scheme in the URL. Thanks. For reference, the URL for retrieving a read-only checkout of PyPI code is . -- \ ?I call him Governor Bush because that's the only political | `\ office he's ever held legally.? ?George Carlin, 2008 | _o__) | Ben Finney From david.lyon at preisshare.net Fri Nov 20 03:25:50 2009 From: david.lyon at preisshare.net (David Lyon) Date: Thu, 19 Nov 2009 21:25:50 -0500 Subject: [Catalog-sig] Package Quality Measurement for packages on Pypi In-Reply-To: References: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> <156be7cf76473f56e97a1e7408612e12@preisshare.net> <4B04DF77.4030302@zopyx.com> Message-ID: <3f6b7403067be4fa987caf1a917d9c0b@preisshare.net> Hi Srid, On Thu, 19 Nov 2009 12:11:01 -0800, "Sridhar Ratnakumar" wrote: > I agree about metadata (not sure about documentation). Based on what I see > > from building packages[1] for PyPM, most packages fail due to one of the > following reasons: > > 1) Missing PKG-INFO file (the author did not use the `sdist` command). > Twisted, IMDBPy are some examples. > 2) Trying to read a non-existent file from setup.py (eg: author forgot to > include README.txt in the tarball -- buggy MANIFEST.in?) > 3) no setup.py > 4) reading stdin in setup.py (so the "setup.py build" runs indefinitely) > 5) no downloads URL (no tarballs either) > 7) Import itself in setup.py (foo-0.1.tar.gz/setup.py has "import foo" -- > and that in turns imports uninstalled deps) > 6) Missing "build dependencies" (many packages try to import > numpy.distutils/twisted so on) > > Other failures usually include missing library dependencies (libxml, for > instance) or some Python syntax error. So what do you guys do with the results? David From sridharr at activestate.com Fri Nov 20 03:50:16 2009 From: sridharr at activestate.com (Sridhar Ratnakumar) Date: Thu, 19 Nov 2009 18:50:16 -0800 Subject: [Catalog-sig] Package Quality Measurement for packages on Pypi In-Reply-To: <3f6b7403067be4fa987caf1a917d9c0b@preisshare.net> References: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> <156be7cf76473f56e97a1e7408612e12@preisshare.net> <4B04DF77.4030302@zopyx.com> <3f6b7403067be4fa987caf1a917d9c0b@preisshare.net> Message-ID: On Thu, 19 Nov 2009 18:25:50 -0800, David Lyon wrote: > On Thu, 19 Nov 2009 12:11:01 -0800, "Sridhar Ratnakumar" > wrote: >> I agree about metadata (not sure about documentation). Based on what I > see >> >> from building packages[1] for PyPM, most packages fail due to one of >> the > >> following reasons: >> >> 1) Missing PKG-INFO file (the author did not use the `sdist` command). >> Twisted, IMDBPy are some examples. >> 2) Trying to read a non-existent file from setup.py (eg: author forgot >> to > >> include README.txt in the tarball -- buggy MANIFEST.in?) >> 3) no setup.py >> 4) reading stdin in setup.py (so the "setup.py build" runs indefinitely) >> 5) no downloads URL (no tarballs either) >> 7) Import itself in setup.py (foo-0.1.tar.gz/setup.py has "import foo" >> -- > >> and that in turns imports uninstalled deps) >> 6) Missing "build dependencies" (many packages try to import >> numpy.distutils/twisted so on) >> >> Other failures usually include missing library dependencies (libxml, for > >> instance) or some Python syntax error. > > So what do you guys do with the results? Can you elaborate your question? -srid From martin at v.loewis.de Fri Nov 20 08:11:02 2009 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Fri, 20 Nov 2009 08:11:02 +0100 Subject: [Catalog-sig] PyPI Development In-Reply-To: <87r5rugmg7.fsf@benfinney.id.au> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> <4B03D2C3.8060104@egenix.com> <4B047AA1.9050302@v.loewis.de> <4B051AB5.7020303@egenix.com> <4B055F01.4030208@egenix.com> <4B05A202.4050306@v.loewis.de> <87r5rugmg7.fsf@benfinney.id.au> Message-ID: <4B064106.6010108@v.loewis.de> > I don't have an account on ?svn.python.org?. How can I get a read-only > checkout of the Subversion repository of the PyPI code? > > Neither of HTTP (error 404) nor HTTPS (HTTP authentication required) > work for me with the above hostname and path. Please try again, accessing https://svn.python.org/packages/ Regards, Martin From martin at v.loewis.de Fri Nov 20 08:20:28 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 20 Nov 2009 08:20:28 +0100 Subject: [Catalog-sig] Extending the package meta-data with more detailed download information In-Reply-To: <4B051FEC.3050905@egenix.com> References: <4B051FEC.3050905@egenix.com> Message-ID: <4B06433C.9040801@v.loewis.de> > Thoughts ? The issue I see is that you have not only one, but many such distributions per release. So I'm curious as to how you would provide/render that information. Regards, Martin From martin at v.loewis.de Fri Nov 20 08:56:58 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 20 Nov 2009 08:56:58 +0100 Subject: [Catalog-sig] adding a trove classifier? In-Reply-To: <4AFC4028.5080006@plope.com> References: <4AFC4028.5080006@plope.com> Message-ID: <4B064BCA.6090302@v.loewis.de> > I hope this is the right place to ask the question, but whom does one > petition to add new Trove classifiers? This is the right place; alternatively/additionally, the PyPI bug tracker would have been good as well. In any case, I have now added these classifiers. Regards, Martin From david.lyon at preisshare.net Fri Nov 20 09:28:06 2009 From: david.lyon at preisshare.net (David Lyon) Date: Fri, 20 Nov 2009 03:28:06 -0500 Subject: [Catalog-sig] Package Quality Measurement for packages on Pypi In-Reply-To: References: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> <156be7cf76473f56e97a1e7408612e12@preisshare.net> <4B04DF77.4030302@zopyx.com> <3f6b7403067be4fa987caf1a917d9c0b@preisshare.net> Message-ID: <9669e402c83cba62dd34d9699e9e69df@preisshare.net> On Thu, 19 Nov 2009 18:50:16 -0800, "Sridhar Ratnakumar" wrote: >>> Other failures usually include missing library dependencies (libxml, for >>> instance) or some Python syntax error. >> >> So what do you guys do with the results? > > Can you elaborate your question? > What do you do with broken packages? Do you contact the authors? or attempt to fix them yourselves.. David From mal at egenix.com Fri Nov 20 10:23:29 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 20 Nov 2009 10:23:29 +0100 Subject: [Catalog-sig] Extending the package meta-data with more detailed download information In-Reply-To: <4B06433C.9040801@v.loewis.de> References: <4B051FEC.3050905@egenix.com> <4B06433C.9040801@v.loewis.de> Message-ID: <4B066011.4050401@egenix.com> "Martin v. L?wis" wrote: >> Thoughts ? > > The issue I see is that you have not only one, but many such > distributions per release. Exactly and that's why more information is needed to figure out which dsitribution file to download than just a single URL can deliver. > So I'm curious as to how you would provide/render that information. Since the meta-format uses RFC822 format, the natural choice would be to be have one semi-colon separated multi-line entry per distribution file. However, since PEP 345 already uses the semi-colon for environment markers, we'd have to use a plain comma... (Working) Example: import email meta_data = """\ Distribution-File: Type: sdist, URL: http://example.net/pkg-A-1.2.3.tgz, Comment: "Source package, needs a C compiler installed.", MD5: 123456789ABCDEF, SHA1: 123456789ABCDEF, PGP: ".....(multi-line text) .....", Python-Implementation: CPython, OS: Windows, Distribution-File: Type: bdist_msi, URL: http://example.net/pkg-1.2.3.msi, MD5: 123456789ABCDEF, SHA1: 123456789ABCDEF, PGP: ".....(multi-line text) .....", Python-Implementation: CPython, Python-Version: 2.5, Python-Variant: UCS2, OS: Windows, OS-Version: XP, Architecture: x86, Processor: i686 Distribution-File: Type: bdist_rpm, URL: http://example.net/pkg-1.2.3.rpm, MD5: 123456789ABCDEF, SHA1: 123456789ABCDEF, PGP: ".....(multi-line text) .....", Python-Implementation: CPython, Python-Version: 2.5, Python-Variant: UCS2, OS: Fedora, OS-Version: 8, Architecture: x86, Processor: i386 """ m = email.message_from_string(meta_data + '\n\n') print m.items() Which gives: [('Distribution-File', ' Type: sdist,\n URL: http://example.net/pkg-A-1.2.3.tgz,\n Comment: "Source package, needs a C compiler installed.",\n MD5: 123456789ABCDEF,\n SHA1: 123456789ABCDEF,\n PGP: ".....(multi-line text)\n .....",\n Python-Implementation: CPython,\n OS: Windows,'), ('Distribution-File', ' Type: bdist_msi,\n URL: http://example.net/pkg-1.2.3.msi,\n MD5: 123456789ABCDEF,\n SHA1: 123456789ABCDEF,\n PGP: ".....(multi-line text)\n .....",\n Python-Implementation: CPython,\n Python-Version: 2.5,\n Python-Variant: UCS2,\n OS: Windows,\n OS-Version: XP,\n Architecture: x86,\n Processor: i686'), ('Distribution-File', ' Type: bdist_rpm,\n URL: http://example.net/pkg-1.2.3.rpm,\n MD5: 123456789ABCDEF,\n SHA1: 123456789ABCDEF,\n PGP: ".....(multi-line text)\n .....",\n Python-Implementation: CPython,\n Python-Version: 2.5,\n Python-Variant: UCS2,\n OS: Fedora,\n OS-Version: 8,\n Architecture: x86,\n Processor: i386')] The entries can then be further decoded into dictionaries: import re ENTRY_RE = re.compile('\s+([-a-zA-Z0-9]+):\s*("[^"]+"|[^,\n\r]+)([,\n\r]|$)') dist_files = [] for name, value in m.items(): if name.lower() == 'distribution-file': d = {} for match in ENTRY_RE.finditer(value): token_name = match.group(1) token_value = match.group(2) d[token_name] = token_value dist_files.append(d) print dist_files Which gives: [{'Comment': '"Source package, needs a C compiler installed."', 'SHA1': '123456789ABCDEF', 'URL': 'http://example.net/pkg-A-1.2.3.tgz', 'OS': 'Windows', 'Python-Implementation': 'CPython', 'PGP': '".....(multi-line text)\n ....."', 'Type': 'sdist', 'MD5': '123456789ABCDEF'}, {'OS': 'Windows', 'SHA1': '123456789ABCDEF', 'URL': 'http://example.net/pkg-1.2.3.msi', 'Python-Variant': 'UCS2', 'Python-Implementation': 'CPython', 'Python-Version': '2.5', 'Architecture': 'x86', 'PGP': '".....(multi-line text)\n ....."', 'OS-Version': 'XP', 'Type': 'bdist_msi', 'Processor': 'i686', 'MD5': '123456789ABCDEF'}, {'OS': 'Fedora', 'SHA1': '123456789ABCDEF', 'URL': 'http://example.net/pkg-1.2.3.rpm', 'Python-Variant': 'UCS2', 'Python-Implementation': 'CPython', 'Python-Version': '2.5', 'Architecture': 'x86', 'PGP': '".....(multi-line text)\n ....."', 'OS-Version': '8', 'Type': 'bdist_rpm', 'Processor': 'i386', 'MD5': '123456789ABCDEF'}] -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 20 2009) >>> 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 mal at egenix.com Fri Nov 20 10:49:27 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 20 Nov 2009 10:49:27 +0100 Subject: [Catalog-sig] PyPI Development In-Reply-To: <4B05A202.4050306@v.loewis.de> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> <4B03D2C3.8060104@egenix.com> <4B047AA1.9050302@v.loewis.de> <4B051AB5.7020303@egenix.com> <4B055F01.4030208@egenix.com> <4B05A202.4050306@v.loewis.de> Message-ID: <4B066627.1050202@egenix.com> "Martin v. L?wis" wrote: >> I'm getting a permission denied when trying to do a checkout >> using this URL (taken from the wiki page): >> >> svn+ssh://svn.python.org/data/repos/packages/trunk/pypi >> >> Has the URL changed or do I have to use some other setup >> on the client side than for Python SVN access ? > > Just go with the read-only checkout for the moment. This specific URL > only works for Richard Jones; I personally use the https checkout > myself to commit, as well. > > In any case, it's separate from the python-dev setup. Ok, thanks, got that working... there's just a minor nit: orig/SVN-PyPI> make checkout Error validating server certificate for 'https://svn.python.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: svn.python.org - Valid: from Apr 10 00:00:00 2007 GMT until Apr 9 23:59:59 2010 GMT - Issuer: http://www.usertrust.com, The USERTRUST Network, Salt Lake City, UT, US - Fingerprint: fc:67:c1:59:f5:57:71:29:f5:13:50:bc:c9:16:f1:74:da:1f:12:98 (R)eject or accept (t)emporarily? t Too bad, Subversion doesn't offer the option to permanently accept that certificate. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 20 2009) >>> 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 chris at simplistix.co.uk Fri Nov 20 16:00:50 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Fri, 20 Nov 2009 15:00:50 +0000 Subject: [Catalog-sig] PyPI Development In-Reply-To: <4B066627.1050202@egenix.com> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> <4B03D2C3.8060104@egenix.com> <4B047AA1.9050302@v.loewis.de> <4B051AB5.7020303@egenix.com> <4B055F01.4030208@egenix.com> <4B05A202.4050306@v.loewis.de> <4B066627.1050202@egenix.com> Message-ID: <4B06AF22.3020107@simplistix.co.uk> M.-A. Lemburg wrote: > Ok, thanks, got that working... there's just a minor nit: > > orig/SVN-PyPI> make checkout > Error validating server certificate for 'https://svn.python.org:443': > - The certificate is not issued by a trusted authority. Use the > fingerprint to validate the certificate manually! > Certificate information: > - Hostname: svn.python.org > - Valid: from Apr 10 00:00:00 2007 GMT until Apr 9 23:59:59 2010 GMT > - Issuer: http://www.usertrust.com, The USERTRUST Network, Salt Lake City, UT, US > - Fingerprint: fc:67:c1:59:f5:57:71:29:f5:13:50:bc:c9:16:f1:74:da:1f:12:98 > (R)eject or accept (t)emporarily? t It usually does, but I do know you can also add to the trusted authorities, although I can't remember how to do that off hand :-S Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From chrism at plope.com Fri Nov 20 16:06:30 2009 From: chrism at plope.com (Chris McDonough) Date: Fri, 20 Nov 2009 10:06:30 -0500 Subject: [Catalog-sig] adding a trove classifier? In-Reply-To: <4B064BCA.6090302@v.loewis.de> References: <4AFC4028.5080006@plope.com> <4B064BCA.6090302@v.loewis.de> Message-ID: <4B06B076.1070602@plope.com> Thank you Martin. Martin v. L?wis wrote: >> I hope this is the right place to ask the question, but whom does one >> petition to add new Trove classifiers? > > This is the right place; alternatively/additionally, the PyPI bug > tracker would have been good as well. > > In any case, I have now added these classifiers. > > Regards, > Martin > From mal at egenix.com Fri Nov 20 16:19:44 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 20 Nov 2009 16:19:44 +0100 Subject: [Catalog-sig] PyPI Development In-Reply-To: <4B06AF22.3020107@simplistix.co.uk> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> <4B03D2C3.8060104@egenix.com> <4B047AA1.9050302@v.loewis.de> <4B051AB5.7020303@egenix.com> <4B055F01.4030208@egenix.com> <4B05A202.4050306@v.loewis.de> <4B066627.1050202@egenix.com> <4B06AF22.3020107@simplistix.co.uk> Message-ID: <4B06B390.8000000@egenix.com> Chris Withers wrote: > M.-A. Lemburg wrote: >> Ok, thanks, got that working... there's just a minor nit: >> >> orig/SVN-PyPI> make checkout >> Error validating server certificate for 'https://svn.python.org:443': >> - The certificate is not issued by a trusted authority. Use the >> fingerprint to validate the certificate manually! >> Certificate information: >> - Hostname: svn.python.org >> - Valid: from Apr 10 00:00:00 2007 GMT until Apr 9 23:59:59 2010 GMT >> - Issuer: http://www.usertrust.com, The USERTRUST Network, Salt Lake >> City, UT, US >> - Fingerprint: >> fc:67:c1:59:f5:57:71:29:f5:13:50:bc:c9:16:f1:74:da:1f:12:98 >> (R)eject or accept (t)emporarily? t > > It usually does, but I do know you can also add to the trusted > authorities, although I can't remember how to do that off hand :-S I'm going to try something along these lines: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2405077 The message comes up with every 'svn update' which is a bit annoying. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 20 2009) >>> 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 mal at egenix.com Fri Nov 20 16:27:51 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 20 Nov 2009 16:27:51 +0100 Subject: [Catalog-sig] PyPI Development In-Reply-To: <4B06B390.8000000@egenix.com> References: <200911162353.47873.paul@boddie.org.uk> <4B023836.2060901@v.loewis.de> <4B028C53.2010506@egenix.com> <4B033094.7060506@v.loewis.de> <4B03D2C3.8060104@egenix.com> <4B047AA1.9050302@v.loewis.de> <4B051AB5.7020303@egenix.com> <4B055F01.4030208@egenix.com> <4B05A202.4050306@v.loewis.de> <4B066627.1050202@egenix.com> <4B06AF22.3020107@simplistix.co.uk> <4B06B390.8000000@egenix.com> Message-ID: <4B06B577.3010900@egenix.com> M.-A. Lemburg wrote: > Chris Withers wrote: >> M.-A. Lemburg wrote: >>> Ok, thanks, got that working... there's just a minor nit: >>> >>> orig/SVN-PyPI> make checkout >>> Error validating server certificate for 'https://svn.python.org:443': >>> - The certificate is not issued by a trusted authority. Use the >>> fingerprint to validate the certificate manually! >>> Certificate information: >>> - Hostname: svn.python.org >>> - Valid: from Apr 10 00:00:00 2007 GMT until Apr 9 23:59:59 2010 GMT >>> - Issuer: http://www.usertrust.com, The USERTRUST Network, Salt Lake >>> City, UT, US >>> - Fingerprint: >>> fc:67:c1:59:f5:57:71:29:f5:13:50:bc:c9:16:f1:74:da:1f:12:98 >>> (R)eject or accept (t)emporarily? t >> >> It usually does, but I do know you can also add to the trusted >> authorities, although I can't remember how to do that off hand :-S > > I'm going to try something along these lines: > > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2405077 > > The message comes up with every 'svn update' which is a bit annoying. This worked for me: ~/.subversion/servers: [groups] svn.python.org = svn.python.org [svn.python.org] ssl-authority-files = /home/lemburg/orig/certs/svn.python.org.pem Use this command to get the PEM file: openssl s_client -showcerts -host svn.python.org -port 443 The PEM file should look something like this: -----BEGIN CERTIFICATE----- MIIEdDCCA1ygAwIBAgIQRL4Mi1AAJLQR0zYq/mUK/TANBgkqhkiG9w0BAQUFADCB lzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2Ug Q2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xHzAdBgNVBAMTFlVUTi1VU0VSRmlyc3Qt SGFyZHdhcmUwHhcNOTkwNzA5MTgxMDQyWhcNMTkwNzA5MTgxOTIyWjCBlzELMAkG A1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xHzAdBgNVBAMTFlVUTi1VU0VSRmlyc3QtSGFyZHdh cmUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx98M4P7Sof885glFn 0G2f0v9Y8+efK+wNiVSZuTiZFvfgIXlIwrthdBKWHTxqctU8EGc6Oe0rE81m65UJ M6Rsl7HoxuzBdXmcRl6Nq9Bq/bkqVRcQVLMZ8Jr28bFdtqdt++BxF2uiiPsA3/4a MXcMmgF6sTLjKwEHOG7DpV4jvEWbe1DByTCP2+UretNb+zNAHqDVmBe8i4fDidNd oI6yqqr2jmmIBsX6iSHzCJ1pLgkzmykNRg+MzEk0sGlRvfkGzWitZky8PqxhvQqI DsjfPe58BEydCl5rkdbux+0ojatNh4lz0G6k0B4WixThdkQDf2Os5M1JnMWS9Ksy oUhbAgMBAAGjgbkwgbYwCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFKFyXyYbKJhDlV0HN9WFlp1L0sNFMEQGA1UdHwQ9MDswOaA3oDWGM2h0 dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNFUkZpcnN0LUhhcmR3YXJlLmNy bDAxBgNVHSUEKjAoBggrBgEFBQcDAQYIKwYBBQUHAwUGCCsGAQUFBwMGBggrBgEF BQcDBzANBgkqhkiG9w0BAQUFAAOCAQEARxkP3nTGmZev/K0oXnWO6y1n7k57K9cM //bey1WiCuFMVGWTYGufEpytXoMs61quwOQt9ABjHbjAbPLPSbtNk28Gpgoiskli CE7/yMgUsogWXecB5BKV5UU0s4tpvc+0hY91UZ59Ojg6FEgSxvunOxqNDYJAB+gE CJChicsZUN/KHAG8HQQZexB2lzvukJDKxA4fFm517zP4029bHpbj4HR3dHuKom4t 3XbWOTCC8KucUvIqx69JXn7HaOWCgchqJ/kniCrVWFCVH/A7HFe7fRQ5YiuayZSS KqMiDP+JJn1fIytH1xUdqWqeUQ0qUZ6B+dQ7XnASfxAynB67nfhmqA== -----END CERTIFICATE----- -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 20 2009) >>> 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 sridharr at activestate.com Fri Nov 20 18:13:46 2009 From: sridharr at activestate.com (Sridhar Ratnakumar) Date: Fri, 20 Nov 2009 09:13:46 -0800 Subject: [Catalog-sig] Package Quality Measurement for packages on Pypi In-Reply-To: <9669e402c83cba62dd34d9699e9e69df@preisshare.net> References: <0b9d4adfcec2a1fb78cc78abe6922fd6@preisshare.net> <156be7cf76473f56e97a1e7408612e12@preisshare.net> <4B04DF77.4030302@zopyx.com> <3f6b7403067be4fa987caf1a917d9c0b@preisshare.net> <9669e402c83cba62dd34d9699e9e69df@preisshare.net> Message-ID: On Fri, 20 Nov 2009 00:28:06 -0800, David Lyon wrote: > On Thu, 19 Nov 2009 18:50:16 -0800, "Sridhar Ratnakumar" > wrote: > >>>> Other failures usually include missing library dependencies (libxml, > for >>>> instance) or some Python syntax error. >>> >>> So what do you guys do with the results? >> >> Can you elaborate your question? >> > > What do you do with broken packages? Do you contact the authors? or > attempt to fix them yourselves.. I have reported a few bugs in the past; most of them are not fixed by the authors yet. For important packages (eg: lxml, numpy, etc..), we attempt to patch the code ourself. Currently the patches are internal, but I am planning to work on a system to publish it to the public. -srid From ziade.tarek at gmail.com Sun Nov 22 16:51:23 2009 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Sun, 22 Nov 2009 16:51:23 +0100 Subject: [Catalog-sig] Extending the package meta-data with more detailed download information In-Reply-To: <4B051FEC.3050905@egenix.com> References: <4B051FEC.3050905@egenix.com> Message-ID: <94bdd2610911220751k5ad019fek31d3b87783aba852@mail.gmail.com> On Thu, Nov 19, 2009 at 11:37 AM, M.-A. Lemburg wrote: > In the current or intended next vesion (1.2 - see PEP 345), the > package meta data does not include any machine usable form of > defining download URLs for particular platforms, Python versions > and variants. > > The only entry we have is: > > """ > Download-URL > ? ?A string containing the URL from which this version of the package can be downloaded. (This > means that the URL can't be something like ".../package-latest.tgz", but instead must be > ".../package-0.45.tgz".) > """ > > which may be usable by a developer looking for the download links, > but isn't really suited for package managers to use. > > PyPI has already extended the meta-data information to include uploaded > files, but only makes this information available via the RPC interface. > > Now I'm not sure whether such download information should be part > of the package's meta-data, but do see a point in having all package > related information in one place for easy access by package managers > and developers. > > I would like to extend the available download information to make > automated downloads more reliable. Here's a list of things that > would be needed: > So, if I understand correctly, you would generate automatically all those extra meta-data within the same "Distribution-File" field, when the distribution is built ? Why they are all grouped under a single field though ? > ?* Distribution type (sdist, bdist_egg, bdist_msi, bdist_wininst, etc.) > ?* Distribution URL (full URL of the download file) > ?* Distribution Comment (any text) > ?* Distribution MD5 digest (as HEX string) > ?* Distribution SHA1 digest (as HEX string) > ?* Distribution PGP signature (as string) > ?* Distribution variant (list defined by the package) Nice ! Although I am not sure about "Comment". What will it provide that we can't provide in Summary and Description ? What's "Distribution variant" ? > > ?* Python implementation (CPython, Jython, etc.) > ?* Python version (2.5, 3.1, etc.) > ?* Python build variant (UCS2, UCS4) > ?* OS identifier (Windows, Linux, Mac OS X, FreeBSD, etc.) > ?* OS version (XP, 2, 10.4, 7, etc.) > ?* Architecture identifier (x86, x64, ppc, ppc64, sparc, sparc64, etc.) > ?* Processor identifier (i386, i686, arm, etc.) What are those useful for ? We are currently adding in PEP 345 fields such as "Requires-Python", that allows to describe the Python versions that are compatible with this distribution, so I am not sure what these build information field will be useful for. Regards Tarek From mal at egenix.com Mon Nov 23 10:23:26 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 23 Nov 2009 10:23:26 +0100 Subject: [Catalog-sig] Extending the package meta-data with more detailed download information In-Reply-To: <94bdd2610911220751k5ad019fek31d3b87783aba852@mail.gmail.com> References: <4B051FEC.3050905@egenix.com> <94bdd2610911220751k5ad019fek31d3b87783aba852@mail.gmail.com> Message-ID: <4B0A548E.1050100@egenix.com> Tarek Ziad? wrote: > On Thu, Nov 19, 2009 at 11:37 AM, M.-A. Lemburg wrote: >> In the current or intended next vesion (1.2 - see PEP 345), the >> package meta data does not include any machine usable form of >> defining download URLs for particular platforms, Python versions >> and variants. >> >> The only entry we have is: >> >> """ >> Download-URL >> A string containing the URL from which this version of the package can be downloaded. (This >> means that the URL can't be something like ".../package-latest.tgz", but instead must be >> ".../package-0.45.tgz".) >> """ >> >> which may be usable by a developer looking for the download links, >> but isn't really suited for package managers to use. >> >> PyPI has already extended the meta-data information to include uploaded >> files, but only makes this information available via the RPC interface. >> >> Now I'm not sure whether such download information should be part >> of the package's meta-data, but do see a point in having all package >> related information in one place for easy access by package managers >> and developers. >> >> I would like to extend the available download information to make >> automated downloads more reliable. Here's a list of things that >> would be needed: >> > > So, if I understand correctly, you would generate automatically all > those extra meta-data within the same "Distribution-File" field, when > the distribution is built ? Yes, you could have distutils generate most of those fields, except for the URL and comment. For one, the developer will run the setup.py several times to build distribution files for various platforms and then upload the generated files to some server or PyPI. As a result, you'd have to append one "Distribution-File" entry per generated distribution file and allow the developer to customize the details (e.g. URL, comment, etc.). What's not clear yet is how to get the data into the meta file. Perhaps it shouldn't go there and instead you have PyPI generate the extra fields in the PKG-INFO file based on what it knows a package and its distribution files. > Why they are all grouped under a single field though ? Because you can have more than just one distribution file for a package. >> * Distribution type (sdist, bdist_egg, bdist_msi, bdist_wininst, etc.) >> * Distribution URL (full URL of the download file) >> * Distribution Comment (any text) >> * Distribution MD5 digest (as HEX string) >> * Distribution SHA1 digest (as HEX string) >> * Distribution PGP signature (as string) >> * Distribution variant (list defined by the package) > > Nice ! Although I am not sure about "Comment". What will it provide > that we can't provide in Summary and Description ? It's a per-distribution file comment and mimics what we have on PyPI. This is a developer edited field. Apart from the variant and sha1 fields, the above fields are already implemented in PyPI. > What's "Distribution variant" ? This optional field is meant for the developer to use on a per package basis. It could be used to flag distribution files that have certain features enabled or not (e.g. a distribution file that includes debug, coverage code or tests vs. one that doesn't). Developers are free to use the variant field for their own purposes. Package managers should provide an option to define the variant the user intends to install. It's an easy way to provide several different builds for the same target platform. Without variants, the only alternative would be creating completely new packages. Here's an example of a C extension: mylib-1.2.3.exe - default variant mylib-1.2.3-debug.exe - 'debug' variant built with debug code enabled mylib-1.2.3-devel.exe - 'devel' variant with header files included >> * Python implementation (CPython, Jython, etc.) >> * Python version (2.5, 3.1, etc.) >> * Python build variant (UCS2, UCS4) >> * OS identifier (Windows, Linux, Mac OS X, FreeBSD, etc.) >> * OS version (XP, 2, 10.4, 7, etc.) >> * Architecture identifier (x86, x64, ppc, ppc64, sparc, sparc64, etc.) >> * Processor identifier (i386, i686, arm, etc.) > > What are those useful for ? > > We are currently adding in PEP 345 fields such as "Requires-Python", > that allows to describe > the Python versions that are compatible with this distribution, so I > am not sure what these build > information field will be useful for. The above fields are meant to be able to match a distribution file to a target installation. Since a developer will often build distribution files for several platforms, you have to include the build information for each file that you create. Those fields are actually the main addition to what we already have on PyPI. They make it possible for a package manager tool to determine the right file to download automatically in a much safer way than is currently possible by trying to parse the distribution file's file name. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 23 2009) >>> 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 Mon Nov 23 10:46:40 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 23 Nov 2009 10:46:40 +0100 Subject: [Catalog-sig] Extending the package meta-data with more detailed download information In-Reply-To: <4B0A548E.1050100@egenix.com> References: <4B051FEC.3050905@egenix.com> <94bdd2610911220751k5ad019fek31d3b87783aba852@mail.gmail.com> <4B0A548E.1050100@egenix.com> Message-ID: <4B0A5A00.1000500@v.loewis.de> > Yes, you could have distutils generate most of those fields, > except for the URL and comment. What's the use case for these new data? Is this for files also hosted at PyPI, or for files hosted elsewhere? Who would use that information, and what for? Regards, Martin From mal at egenix.com Mon Nov 23 11:27:10 2009 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 23 Nov 2009 11:27:10 +0100 Subject: [Catalog-sig] Extending the package meta-data with more detailed download information In-Reply-To: <4B0A5A00.1000500@v.loewis.de> References: <4B051FEC.3050905@egenix.com> <94bdd2610911220751k5ad019fek31d3b87783aba852@mail.gmail.com> <4B0A548E.1050100@egenix.com> <4B0A5A00.1000500@v.loewis.de> Message-ID: <4B0A637E.8090601@egenix.com> "Martin v. L?wis" wrote: >> Yes, you could have distutils generate most of those fields, >> except for the URL and comment. > > What's the use case for these new data? Is this for files > also hosted at PyPI, or for files hosted elsewhere? Who would > use that information, and what for? As mentioned in the original email, the use case is to have PyPI list download information for all distribution files of a package together with a set of details that allow automatic selection of a file for installation by a package manager tool. PyPI currently only provides limited details for each uploaded file and doesn't support referencing files hosted on other servers at all. I'd like to extend PyPI to also provide support for listing files on other servers as well as making it possible for the package manager tools to automatically select the right installation file for the intended target platform. At eGenix we often find that users download and install the wrong distribution files for the target Python installation - even though we do try to make this selection process as simple as possible on the download pages. To enhance the user experience we were thinking about providing a tool to automate the whole process. However, if PIP can provide this functionality based on the extended distribution file information, we'd rather point our users to PIP. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 23 2009) >>> 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 Mon Nov 23 11:51:39 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 23 Nov 2009 11:51:39 +0100 Subject: [Catalog-sig] Extending the package meta-data with more detailed download information In-Reply-To: <4B0A637E.8090601@egenix.com> References: <4B051FEC.3050905@egenix.com> <94bdd2610911220751k5ad019fek31d3b87783aba852@mail.gmail.com> <4B0A548E.1050100@egenix.com> <4B0A5A00.1000500@v.loewis.de> <4B0A637E.8090601@egenix.com> Message-ID: <4B0A693B.50304@v.loewis.de> > As mentioned in the original email, the use case is to have > PyPI list download information for all distribution files > of a package together with a set of details that allow automatic > selection of a file for installation by a package manager > tool. That's the description of the feature. I still don't understand who would be using the feature, and in what way. > I'd like to extend PyPI to also provide support for listing > files on other servers as well as making it possible for > the package manager tools to automatically select the right > installation file for the intended target platform. In such a scenario, how do people get the files onto the server? Will they typically know the URLs of the files upfront? ISTM that it would be better to be able to add new such URLs one by one, e.g. through a web form. > To enhance the user experience we were thinking about providing > a tool to automate the whole process. However, if PIP can > provide this functionality based on the extended distribution > file information, we'd rather point our users to PIP. If the use case is automated download, I think the list of properties should be restricted to the set of properties relevant for that use case. Regards, Martin From david.lyon at preisshare.net Mon Nov 23 14:46:35 2009 From: david.lyon at preisshare.net (David Lyon) Date: Mon, 23 Nov 2009 08:46:35 -0500 Subject: [Catalog-sig] Extending the package meta-data with more detailed download information In-Reply-To: <4B0A637E.8090601@egenix.com> References: <4B051FEC.3050905@egenix.com> <94bdd2610911220751k5ad019fek31d3b87783aba852@mail.gmail.com> <4B0A548E.1050100@egenix.com> <4B0A5A00.1000500@v.loewis.de> <4B0A637E.8090601@egenix.com> Message-ID: <510a5aa6ea8fb10e04ab546d4f1aa3dd@preisshare.net> On Mon, 23 Nov 2009 11:27:10 +0100, "M.-A. Lemburg" wrote: > "Martin v. L?wis" wrote: > As mentioned in the original email, the use case is to have > PyPI list download information for all distribution files > of a package together with a set of details that allow automatic > selection of a file for installation by a package manager > tool. That can happen already though, without extending pypi. > PyPI currently only provides limited details for each uploaded > file and doesn't support referencing files hosted on other > servers at all. > > I'd like to extend PyPI to also provide support for listing > files on other servers as well as making it possible for > the package manager tools to automatically select the right > installation file for the intended target platform. That's complex. easy_install and pip already do this. So to get that you only have to use one of those tools. Wholistically, it would be much better to improve pypi and continue not to support download links to other servers. It isn't unreasonable imo for pypi to hold all the good packages. And for users to be able to get them there. > At eGenix we often find that users download and install the > wrong distribution files for the target Python installation - > even though we do try to make this selection process as simple > as possible on the download pages. Of course. what we have is overly complex in some ways. More download links than what already exist could make the problem worse. > To enhance the user experience we were thinking about providing > a tool to automate the whole process. Well let me know if you want a custom version of pythonpkgmgr. > However, if PIP can > provide this functionality based on the extended distribution > file information, we'd rather point our users to PIP. Thats an option too.. Best Regards David From chris at simplistix.co.uk Wed Nov 25 15:43:09 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 25 Nov 2009 14:43:09 +0000 Subject: [Catalog-sig] More problems with the comments system... Message-ID: <4B0D427D.5090802@simplistix.co.uk> This stems from a user of the type all the package maintainers have been complaining about, and the reason why want the commenting and rating system to be optional, that occurred here: http://pypi.python.org/pypi/zope.app.sqlscript/3.5.0 If PyPI wants to be a threaded discussion system, it needs to get a whole lot better: - So, originally, the rater was bitten by by this bug: http://sourceforge.net/tracker/?func=detail&aid=2881546&group_id=66150&atid=513503 - When questioned as to why he'd rated the package as zero, he put up a fairly meaningless collection of bullet points (exactly what a lot of us have been complaining about) - The comment turned into a big long threaded discussion with a lot of people commenting, and comments appearing on comments (another thing we've been complaining about) - The whiner, *cough* I mean rater, then decided he didn't like the comments suggesting he use the right mailing list and/or asking him to explain his nonsensical bullet list and so deleted the whole thread, replacing it with his nonsensical bullet point list. (So now the comments pointing to the right mailing lists can't be found by anyone, and all the work done by people trying to help this individual is lost, nice...) - Because I'm marked as a "Package Index Owner", I can't rate or independently comment on this package, even though I'm not its maintainer, I'm just someone who's volunteered to take responsibility for releasing a load of zope-related eggs when no-one else is around. *sigh* Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From faassen at startifact.com Wed Nov 25 16:01:10 2009 From: faassen at startifact.com (Martijn Faassen) Date: Wed, 25 Nov 2009 16:01:10 +0100 Subject: [Catalog-sig] More problems with the comments system... In-Reply-To: <4B0D427D.5090802@simplistix.co.uk> References: <4B0D427D.5090802@simplistix.co.uk> Message-ID: Hi there, Chris Withers wrote: [snip] > - The whiner, *cough* I mean rater, then decided he didn't like the > comments suggesting he use the right mailing list and/or asking him to > explain his nonsensical bullet list and so deleted the whole thread, > replacing it with his nonsensical bullet point list. (So now the > comments pointing to the right mailing lists can't be found by anyone, > and all the work done by people trying to help this individual is lost, > nice...) I just resubscribed to this mailing list to report this scenario (independently from Chris. I tend to express myself a bit less forcefully too :) In this discussion, I placed a comment in the zope.app.sqlscript thread to point to more modern ways to integrate the Zope Toolkit with relational databases. This comment (along with many others) is now lost because the original person deleted his comment and then recreated it. The current design therefore gives the commenter the power to destroy responses by package owners. And... > - Because I'm marked as a "Package Index Owner", I can't rate or > independently comment on this package, even though I'm not its > maintainer, I'm just someone who's volunteered to take responsibility > for releasing a load of zope-related eggs when no-one else is around. Happened to me too. I attempted to place my comment in a separate thread to get it out of the power of the original rater, but I'm also one of the many package owners of this package. I therefore cannot place comments. This means that any replies by package owners are at the mercy of package commenters. If a commenter wants to put up a negative comment and prevent the package owners from replying to it directly or indirectly, they have the power right now. Of course the package owners can put a "reply" to the comment in the actual long description of the package, but that doesn't seem to be the right medium for it. If comment disabling is implemented, I think a nice feature might be to repeat the author email metadata in its place (or perhaps a special metadata field for diccussion forums). This way someone who wants to comment on the package gets a clear indication of where they can to go. Then again, offering a comment on ones rating versus a comment to the developers might be two different purposes. Regards, Martijn From martin at v.loewis.de Wed Nov 25 17:47:42 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 25 Nov 2009 17:47:42 +0100 Subject: [Catalog-sig] More problems with the comments system... In-Reply-To: References: <4B0D427D.5090802@simplistix.co.uk> Message-ID: <4B0D5FAE.2020809@v.loewis.de> > In this discussion, I placed a comment in the zope.app.sqlscript thread > to point to more modern ways to integrate the Zope Toolkit with > relational databases. This comment (along with many others) is now lost > because the original person deleted his comment and then recreated it. It's not completely lost, as there still is a log of it somewhere. So if you need the actual text, please let me know. > The current design therefore gives the commenter the power to destroy > responses by package owners. And... That's true, and unfortunate. Can you propose an alternative approach (short of removing the comment facility altogether)? >> - Because I'm marked as a "Package Index Owner", I can't rate or >> independently comment on this package, even though I'm not its >> maintainer, I'm just someone who's volunteered to take responsibility >> for releasing a load of zope-related eggs when no-one else is around. > > Happened to me too. Not sure what exactly happened: that you wanted to rate, and couldn't, or that you wanted to comment, and couldn't? Why would you want to comment on the package, when you can put whatever you want to say into the packages' page? > Of course the package owners can put a "reply" to the comment in the > actual long description of the package, but that doesn't seem to be the > right medium for it. I agree that this is not the right place for a reply. As for other information or remarks that you want to publish, I'm not so sure. > If comment disabling is implemented, I think a nice feature might be to > repeat the author email metadata in its place (or perhaps a special > metadata field for diccussion forums). This way someone who wants to > comment on the package gets a clear indication of where they can to go. This I cannot understand. Can you rephrase? Regards, Martin From faassen at startifact.com Wed Nov 25 18:04:21 2009 From: faassen at startifact.com (Martijn Faassen) Date: Wed, 25 Nov 2009 18:04:21 +0100 Subject: [Catalog-sig] More problems with the comments system... In-Reply-To: <4B0D5FAE.2020809@v.loewis.de> References: <4B0D427D.5090802@simplistix.co.uk> <4B0D5FAE.2020809@v.loewis.de> Message-ID: Martin v. L?wis wrote: >> In this discussion, I placed a comment in the zope.app.sqlscript thread >> to point to more modern ways to integrate the Zope Toolkit with >> relational databases. This comment (along with many others) is now lost >> because the original person deleted his comment and then recreated it. > > It's not completely lost, as there still is a log of it somewhere. So if > you need the actual text, please let me know. Thanks, but that isn't a problem. >> The current design therefore gives the commenter the power to destroy >> responses by package owners. And... > > That's true, and unfortunate. Can you propose an alternative approach > (short of removing the comment facility altogether)? Perhaps when someone removes their comment it will say "comment removed" (and the commenter's name could be eliminated as well). The followups would remain in-tact this way. That isn't the complete context of course for future readers, but better than nothing. >>> - Because I'm marked as a "Package Index Owner", I can't rate or >>> independently comment on this package, even though I'm not its >>> maintainer, I'm just someone who's volunteered to take responsibility >>> for releasing a load of zope-related eggs when no-one else is around. >> Happened to me too. > > Not sure what exactly happened: that you wanted to rate, and couldn't, > or that you wanted to comment, and couldn't? I wanted to comment, but couldn't. I can only reply to comments as a package owner, not create new comments. > Why would you want to comment on the package, when you can put whatever > you want to say into the packages' page? I wanted to comment on the package itself, because my comment got removed in a comment on a comment. I wanted to put this information back in. Of course often updating the long description is an alternative to doing so. But this would have been quite a bit more work than placing a comment; the long description of this package is generated by setup.py of the package, and it'd meant having to check out the package and doing a new description upload. I just wanted to spend a minute to provide helpful information. [snip] >> If comment disabling is implemented, I think a nice feature might be to >> repeat the author email metadata in its place (or perhaps a special >> metadata field for diccussion forums). This way someone who wants to >> comment on the package gets a clear indication of where they can to go. > > This I cannot understand. Can you rephrase? If it's possible to disable comments on a per-package basis, it might be useful to say in the UI: "If you want to comment on this package, please use the following forum: ." This would need sufficient metadata in the package to describe such discussion forums. I'm not sure whether author email is enough, but perhaps other metadata fields apply. But perhaps there's a better idea than that: it would be useful to provide a "feedback" functionality for a package. This is separate from comments: comments are meant to be read by others. Feedback is supposed to go to the package maintainers but doesn't need to be shown. Regards, Martijn From ziade.tarek at gmail.com Wed Nov 25 18:35:34 2009 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Wed, 25 Nov 2009 18:35:34 +0100 Subject: [Catalog-sig] More problems with the comments system... In-Reply-To: References: <4B0D427D.5090802@simplistix.co.uk> <4B0D5FAE.2020809@v.loewis.de> Message-ID: <94bdd2610911250935v6c315c35i36a842eecf05c5f3@mail.gmail.com> On Wed, Nov 25, 2009 at 6:04 PM, Martijn Faassen wrote: > Martin v. L?wis wrote: >>> >>> In this discussion, I placed a comment in the zope.app.sqlscript thread >>> to point to more modern ways to integrate the Zope Toolkit with >>> relational databases. This comment (along with many others) is now lost >>> because the original person deleted his comment and then recreated it. >> >> It's not completely lost, as there still is a log of it somewhere. So if >> you need the actual text, please let me know. > > Thanks, but that isn't a problem. > >>> The current design therefore gives the commenter the power to destroy >>> responses by package owners. And... >> >> That's true, and unfortunate. Can you propose an alternative approach >> (short of removing the comment facility altogether)? > > Perhaps when someone removes their comment it will say "comment removed" > (and the commenter's name could be eliminated as well). The followups would > remain in-tact this way. That isn't the complete context of course for > future readers, but better than nothing. > >>>> - Because I'm marked as a "Package Index Owner", I can't rate or >>>> independently comment on this package, even though I'm not its >>>> maintainer, I'm just someone who's volunteered to take responsibility >>>> for releasing a load of zope-related eggs when no-one else is around. >>> >>> Happened to me too. >> >> Not sure what exactly happened: that you wanted to rate, and couldn't, >> or that you wanted to comment, and couldn't? > > I wanted to comment, but couldn't. I can only reply to comments as a package > owner, not create new comments. > >> Why would you want to comment on the package, when you can put whatever >> you want to say into the packages' page? > > I wanted to comment on the package itself, because my comment got removed in > a comment on a comment. I wanted to put this information back in. > > Of course often updating the long description is an alternative to doing so. > But this would have been quite a bit more work than placing a comment; the > long description of this package is generated by setup.py of the package, > and it'd meant having to check out the package and doing a new description > upload. I just wanted to spend a minute to provide helpful information. > > [snip] >>> >>> If comment disabling is implemented, I think a nice feature might be to >>> repeat the author email metadata in its place (or perhaps a special >>> metadata field for diccussion forums). This way someone who wants to >>> comment on the package gets a clear indication of where they can to go. >> >> This I cannot understand. Can you rephrase? > > If it's possible to disable comments on a per-package basis, it might be > useful to say in the UI: > > "If you want to comment on this package, please use the following forum: > ." Note that I have introduced three new fields in PEP 345 to help on this (after I have read Catalog-SIG threads on the commenting issues -- someone suggested them): http://www.python.org/dev/peps/pep-0345 # Repository-URL # Repository-Browser-URL # Bug-Tracker-URL Any feedback is welcome about it at Distutils-SIG, if you see anything else that could be done at the metadata level (then used and highlighted by PyPI) Regards, Tarek From martin at v.loewis.de Wed Nov 25 18:41:34 2009 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 25 Nov 2009 18:41:34 +0100 Subject: [Catalog-sig] More problems with the comments system... In-Reply-To: References: <4B0D427D.5090802@simplistix.co.uk> <4B0D5FAE.2020809@v.loewis.de> Message-ID: <4B0D6C4E.2090709@v.loewis.de> >> That's true, and unfortunate. Can you propose an alternative approach >> (short of removing the comment facility altogether)? > > Perhaps when someone removes their comment it will say "comment removed" > (and the commenter's name could be eliminated as well). The followups > would remain in-tact this way. That isn't the complete context of course > for future readers, but better than nothing. Ok, will do. > I wanted to comment on the package itself, because my comment got > removed in a comment on a comment. I wanted to put this information back > in. > > Of course often updating the long description is an alternative to doing > so. But this would have been quite a bit more work than placing a > comment; the long description of this package is generated by setup.py > of the package, and it'd meant having to check out the package and doing > a new description upload. I just wanted to spend a minute to provide > helpful information. Assuming your comment wasn't actually removed, this specific need would go away, right? Notice that you don't have to run the complete upload process again if you want to edit the long description - you can easily do that over the web page as well. >>> If comment disabling is implemented, I think a nice feature might be to >>> repeat the author email metadata in its place (or perhaps a special >>> metadata field for diccussion forums). This way someone who wants to >>> comment on the package gets a clear indication of where they can to go. >> >> This I cannot understand. Can you rephrase? > > If it's possible to disable comments on a per-package basis, it might be > useful to say in the UI: > > "If you want to comment on this package, please use the following forum: > ." Now, *that* is something that I would consider appropriate for long_description. Notice that the comment facility in PyPI is quite different from posting to a mailing list. The audience for the mailing list are developers/authors of the package, and current users. The (intended) use of the PyPI commenting facility is to address prospective users of the package, which want to know whether the package is any good. > But perhaps there's a better idea than that: it would be useful to > provide a "feedback" functionality for a package. This is separate from > comments: comments are meant to be read by others. Feedback is supposed > to go to the package maintainers but doesn't need to be shown. Again, that's (yet) another feature - messages that are primarily addressed at the package authors. I'm not sure many package authors would like that (and the poll indicates that the option "mail to package owner only" receives little interest). They either have bug reporting and support channels already, or they would prefer to get such messages in direct email; some may not want to be bothered with package feedback at all. Regards, Martin From faassen at startifact.com Wed Nov 25 22:18:14 2009 From: faassen at startifact.com (Martijn Faassen) Date: Wed, 25 Nov 2009 22:18:14 +0100 Subject: [Catalog-sig] More problems with the comments system... In-Reply-To: <4B0D6C4E.2090709@v.loewis.de> References: <4B0D427D.5090802@simplistix.co.uk> <4B0D5FAE.2020809@v.loewis.de> <4B0D6C4E.2090709@v.loewis.de> Message-ID: Martin v. L?wis wrote: [snip] >> Of course often updating the long description is an alternative to doing >> so. But this would have been quite a bit more work than placing a >> comment; the long description of this package is generated by setup.py >> of the package, and it'd meant having to check out the package and doing >> a new description upload. I just wanted to spend a minute to provide >> helpful information. > > Assuming your comment wasn't actually removed, this specific need would > go away, right? Yes, though I must say I spent quite a few minutes hunting through the user interface to try to figure out how I could add a new comment until I figured out it would only work for those packages I am not a maintainer of. :) > Notice that you don't have to run the complete upload process again if > you want to edit the long description - you can easily do that over the > web page as well. I know that, but then the information will be lost next time I do an upload, unless I also add it to the version control system too. I don't want to maintain information in two places if I can avoid it. [snip] >> "If you want to comment on this package, please use the following forum: >> ." > > Now, *that* is something that I would consider appropriate for > long_description. I think this goes more into a discussion about metadata. Author email and a mailing list or forum address should be separate categories. But I think I need to take that up in the distutils-sig. > Notice that the comment facility in PyPI is quite different from posting > to a mailing list. The audience for the mailing list are > developers/authors of the package, and current users. The (intended) use > of the PyPI commenting facility is to address prospective users of the > package, which want to know whether the package is any good. True. Though in reality these use cases flow into each other: * see whether a package is any good * reading the mailing list * feedback to the authors. >> But perhaps there's a better idea than that: it would be useful to >> provide a "feedback" functionality for a package. This is separate from >> comments: comments are meant to be read by others. Feedback is supposed >> to go to the package maintainers but doesn't need to be shown. > > Again, that's (yet) another feature - messages that are primarily > addressed at the package authors. > > I'm not sure many package authors would like that (and the poll > indicates that the option "mail to package owner only" receives > little interest). They either have bug reporting and support channels > already, or they would prefer to get such messages in direct email; > some may not want to be bothered with package feedback at all. But since the package owners do get these messages now too, they'll undoubtedly be used as a feedback mechanism as well. Regards, Martijn From tjreedy at udel.edu Wed Nov 25 22:40:51 2009 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 25 Nov 2009 16:40:51 -0500 Subject: [Catalog-sig] More problems with the comments system... In-Reply-To: <4B0D5FAE.2020809@v.loewis.de> References: <4B0D427D.5090802@simplistix.co.uk> <4B0D5FAE.2020809@v.loewis.de> Message-ID: Martin v. L?wis wrote: >> In this discussion, I placed a comment in the zope.app.sqlscript thread >> to point to more modern ways to integrate the Zope Toolkit with >> relational databases. This comment (along with many others) is now lost >> because the original person deleted his comment and then recreated it. There is nothing now, so I cannot see what Chris is complaining about. > It's not completely lost, as there still is a log of it somewhere. So if > you need the actual text, please let me know. I will trust that Chris's complaint has some merit. > Not sure what exactly happened: that you wanted to rate, and couldn't, > or that you wanted to comment, and couldn't? As I said in another thread (ignored), I wanted to comment on a package and say something helpful without rating it. As I remember, I had looked at the package to see that something was missing (maybe in the doc, not the code) but had not used it and therefore could not fairly rate it and therefore would not. > Why would you want to comment on the package, when you can put whatever > you want to say into the packages' page? As a 3rd party, I cannot do that! If you want community discussion, you have to let people discuss without fake ratings. Terry Jan Reedy From pje at telecommunity.com Wed Nov 25 23:57:44 2009 From: pje at telecommunity.com (P.J. Eby) Date: Wed, 25 Nov 2009 17:57:44 -0500 Subject: [Catalog-sig] More problems with the comments system... In-Reply-To: <4B0D6C4E.2090709@v.loewis.de> References: <4B0D427D.5090802@simplistix.co.uk> <4B0D5FAE.2020809@v.loewis.de> <4B0D6C4E.2090709@v.loewis.de> Message-ID: <20091125225750.779813A40A8@sparrow.telecommunity.com> At 06:41 PM 11/25/2009 +0100, Martin v. L?wis wrote: >I'm not sure many package authors would like that (and the poll >indicates that the option "mail to package owner only" receives >little interest). They either have bug reporting and support channels >already, or they would prefer to get such messages in direct email; >some may not want to be bothered with package feedback at all. That's because that poll is skewed. You can only choose one option, even if more than one is acceptable to you. Thus, persons must vote strategically to avoid a bad outcome due to a split vote. If you were allowed to select all acceptable options, I would've included "mail to package owner only" as an acceptable option. But since I can only pick one, I would not "waste my vote" and thus keep my most-preferred option (no commenting system at all) from receiving a plurality of votes. From sridharr at activestate.com Thu Nov 26 01:51:19 2009 From: sridharr at activestate.com (Sridhar Ratnakumar) Date: Wed, 25 Nov 2009 16:51:19 -0800 Subject: [Catalog-sig] More problems with the comments system... In-Reply-To: <20091125225750.779813A40A8@sparrow.telecommunity.com> References: <4B0D427D.5090802@simplistix.co.uk> <4B0D5FAE.2020809@v.loewis.de> <4B0D6C4E.2090709@v.loewis.de> <20091125225750.779813A40A8@sparrow.telecommunity.com> Message-ID: On Wed, 25 Nov 2009 14:57:44 -0800, P.J. Eby wrote: > At 06:41 PM 11/25/2009 +0100, Martin v. L?wis wrote: >> I'm not sure many package authors would like that (and the poll >> indicates that the option "mail to package owner only" receives >> little interest). They either have bug reporting and support channels >> already, or they would prefer to get such messages in direct email; >> some may not want to be bothered with package feedback at all. > > That's because that poll is skewed. You can only choose one option, > even if more than one is acceptable to you. Thus, persons must vote > strategically to avoid a bad outcome due to a split vote. > > If you were allowed to select all acceptable options, I would've > included "mail to package owner only" as an acceptable option. But > since I can only pick one, I would not "waste my vote" and thus keep my > most-preferred option (no commenting system at all) from receiving a > plurality of votes. > That's exactly what I thought too. Except my vote still went to "mail to package owner only". -srid From exarkun at twistedmatrix.com Thu Nov 26 03:22:12 2009 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Thu, 26 Nov 2009 02:22:12 -0000 Subject: [Catalog-sig] Requesting ownership of the package "Twisted Pair" Message-ID: <20091126022212.26747.592998136.divmod.xquotient.45@localhost.localdomain> Hi, Can the "Twisted Pair" owner on PyPI be changed to me? Whoever registered the account "twisted" has forgotten about it. My PyPI username is "exarkun". Thanks, Jean-Paul From ianb at colorstudy.com Sat Nov 28 22:42:00 2009 From: ianb at colorstudy.com (Ian Bicking) Date: Sat, 28 Nov 2009 15:42:00 -0600 Subject: [Catalog-sig] More descriptive ratings Message-ID: Instead of a score, maybe it would be more useful to have a count of people's experiences. Here's a possible list: * I use this package and like it * I use this package, but have problems with it * I used this package, but stopped because I found something better * I used this package, but stopped because it caused me too many problems * I used this package, but stopped because of reasons that don't reflect on the quality of the package * I tried to use this package, but couldn't get it working. That entirely leaves out people who haven't used the package at all, which seems fine. The descriptions are a bit long, not sure if anything can be done with that. Jesse Noller noted (from Zed?) that there's generally a bifurcation of votes -- either 5 or 0, depending on whether you love/hate the package. My proposal doesn't try to represent fine distinctions. Also it separates beginner problems that are blockers (which are what a lot of people's pithy complaints or 0's are from) from more substantive problems -- and both deserve to be represented, but just should be represented differently. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker -------------- next part -------------- An HTML attachment was scrubbed... URL: