On Thu, Nov 12, 2009 at 8:38 AM, Steven D'Aprano <steve@pearwood.info> wrote:

On Thu, 12 Nov 2009 08:44:32 pm Ludvig Ericson wrote:

...

Why are there comments on PyPI? Moreso, why are there comments which I cannot control as a package author on my very own packages? That's just absurd.

No, what's absurd is thinking that the act of publishing software somehow gives you the right to demand control over what others say about your software.

I don't suppose that this rant of yours has something to do with the comment posted today?

Frankly, I agree with him. As implemented, I *and others* think this is broken. I've taken the stance of not publishing things to PyPi until A> I find the time to contribute to make it better or B> It changes. jesse

On Thu, Nov 12, 2009 at 9:25 AM, Barry Warsaw <barry@python.org> wrote:

On Nov 12, 2009, at 8:06 AM, Jesse Noller wrote:

...

Frankly, I agree with him. As implemented, I *and others* think this is broken. I've taken the stance of not publishing things to PyPi until A> I find the time to contribute to make it better or B> It changes.

That's distressing.  For better or worse PyPI is the central repository of 3rd party packages.  It should be easy, desirable, fun and socially encouraged to get your packages there.

I personally think a ratings system can be useful, but you should be able to opt-out of it if you want.  Or just write such awesome software that the bogus bad reviews will be buried by an avalanche of kudos.

-Barry

I completely and totally agree with you. That's why it's a self-imposed thing for me, I want to help, but don't have the time. In the same breath, I don't want to support it as-is. PyPI isn't a place to file bugs, complain something didn't work for you if you didn't even have the common decency in some cases to email them. Being unable, as an author, to remove, moderate, or even respond to issues there bothers me quite a bit. Heck, I would even be for requiring packages have a mailing list and / or bug tracker to even upload, rather than comments. At least then the authors or maintainers have a fighting chance.

On 03:01 pm, dalcinl@gmail.com wrote:

On Thu, Nov 12, 2009 at 12:32 PM, Jesse Noller <jnoller@gmail.com> wrote:

...

On Thu, Nov 12, 2009 at 9:25 AM, Barry Warsaw <barry@python.org> wrote:

...

On Nov 12, 2009, at 8:06 AM, Jesse Noller wrote:

...

Frankly, I agree with him. As implemented, I *and others* think this is broken. I've taken the stance of not publishing things to PyPi until A> I find the time to contribute to make it better or B> It changes.

That's distressing. �For better or worse PyPI is the central repository of 3rd party packages. �It should be easy, desirable, fun and socially encouraged to get your packages there.

PyPI isn't a place to file bugs, complain something didn't work for you if you didn't even have the common decency in some cases to email them. Being unable, as an author, to remove, moderate, or even respond to issues there bothers me quite a bit.

I also agree with you. I do not see the point to make PyPI yet another social network.

+1 Jean-Paul

Barry Warsaw wrote:

On Nov 12, 2009, at 8:06 AM, Jesse Noller wrote:

...

Frankly, I agree with him. As implemented, I *and others* think this is broken. I've taken the stance of not publishing things to PyPi until A> I find the time to contribute to make it better or B> It changes.

That's distressing. For better or worse PyPI is the central repository of 3rd party packages. It should be easy, desirable, fun and socially encouraged to get your packages there.

I think his point is that a new book announcement servive is different from a book review and rating service. And that mixing the two is 'socially discouraging'. I do not know what the answer is

I personally think a ratings system can be useful, but you should be able to opt-out of it if you want. Or just write such awesome software that the bogus bad reviews will be buried by an avalanche of kudos.

Intention = precision => for a better PyPI On Thu, Nov 12, 2009 at 1:54 PM, Guido van Rossum <guido@python.org> wrote:

On Thu, Nov 12, 2009 at 10:30 AM, Terry Reedy <tjreedy@udel.edu> wrote:

...

Barry Warsaw wrote:

...

On Nov 12, 2009, at 8:06 AM, Jesse Noller wrote:

...

Frankly, I agree with him. As implemented, I *and others* think this is broken. I've taken the stance of not publishing things to PyPi until A> I find the time to contribute to make it better or B> It changes.

That's distressing.  For better or worse PyPI is the central repository of 3rd party packages.  It should be easy, desirable, fun and socially encouraged to get your packages there.

I think his point is that a new book announcement servive is different from a book review and rating service.  And that mixing the two is 'socially discouraging'. I do not know what the answer is

I would say that publishers disagree -- they seem to really like adding "social" stuff to their book announcement service. See e.g. Amazon (which combines all functions: announcement/promotion, ordering/download, review/comments/rate/popularity).

... but (most) book writers don't use an issue tracker to manage and get *useful* feedback from their readers (I know there are exceptions to the rule ;o) and fix the book chapters or anything else . Besides there are some differences between software and books and the way both of them are created, used and enhanced . What I don't like (today) about comments + votes is that I have to do the same thing in two different places (especially because one of the sources is *very* noisy). If there's a way to integrate both and «reduce» the noise , that would be nice . ;o)

I agree that creating a good social app is not easy, and if we can't improve the social app embedded in PyPI quickly enough, we should at least give authors the option to disable comments.

+1

Of course, as a user, I might not trust a module that has no reviews or ratings.

Not really sure. For example, if a user access the page for setuptools (just an example ;o) soon she/he will realize that other people use it very often and also has a high kwalitee score, therefore it is quite unlikely that such package be «irrelevant» or «untrusted» (this is IMHO) . -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:

On Thu, Nov 12, 2009 at 11:25 AM, Jesse Noller <jnoller@gmail.com> wrote:

I'd not trust a package without a bug tracker, mailing list or link to the source a lot sooner than something without comments and ratings.

Yeah, but you're not exactly an average user. Most users don't know how to use a bug tracker. Also, there's a large variety of packages on PyPI. Not every developer has the same attitude, but they all live happily together on PyPI. (Or did you want someone to start a separate CPAN "for the rest of them" ? :-) [...]

What about astroturfing? What's to stop me from writing a script to create a pile of accounts and then bumping packages I like with glowing ratings and reviews? Who is going to be the moderator, and how to decide between spam, incorrect comment, etc?

Those are all hard problems, though all of them have at least partial solutions in the other worlds (Amazon, Wikipedia, Apple app store, etc.). Maybe there should be a standard "social app" that you can just customize for a specific purpose. Sounds like an interesting project, actually. -- --Guido van Rossum (python.org/~guido)

Intention = personal opinion => for a better PyPI On Thu, Nov 12, 2009 at 2:38 PM, Jesse Noller <jnoller@gmail.com> wrote:

On Thu, Nov 12, 2009 at 2:30 PM, Guido van Rossum <guido@python.org> wrote:

...

On Thu, Nov 12, 2009 at 11:25 AM, Jesse Noller <jnoller@gmail.com> wrote:

...

I'd not trust a package without a bug tracker, mailing list or link to the source a lot sooner than something without comments and ratings.

Yeah, but you're not exactly an average user. Most users don't know how to use a bug tracker. Also, there's a large variety of packages on PyPI. Not every developer has the same attitude, but they all live happily together on PyPI. (Or did you want someone to start a separate CPAN "for the rest of them" ? :-)

True, but if you make entries for them mandatory (bug trackers, source, etc), and you encourage users to use them, you begin being to be the change you want to be, which is making PyPi *less* of an "app store" where the consumer doesn't collaborate with the authors.

Or maybe rather than *putting* this stuff into Pypi; pypi allows plugins to allow authors to link in RSS feeds to their bug trackers, wiki streams, what have you.

IMO plugins could be a little bit complicated because PyPI would need to be extended, and there's also the problem of installing, upgrading and maintaining each plugin . OTOH if PyPI relies on a single API based on open standards (e.g. RPC or something RESTful ;o) then that would represent less overhead for PyPI maintainers . Instead of votes + comments I'd prefer a similar user interface but doing things as follows (feel free to filter things; besides I'll mention how it should work using Trac XmlRpcPlugin , but should be similar for other PMS ;o) : - Previous comments retrieved from third party site and shown (e.g. no more than 5 and only most recent shown like TH.org) as well as a link to navigate to third party site in order to look for further issues . (ticket.getAll + ticket.get) - Text input would be the description of a ticket (ticket.create) - A combobox to select either comment | defect | support (ticket.create) - Ratings could be interpreted as a priority or severity ... (labels = ticket.priority.getAll + ticket.priority.getAll , values for single item = ticket.get ) Implementing all this might require to add more information to the index (I am not sure) and also config options in the site for package maintainers, but since it'd be more useful (for me) probable (me and others) will prefer something like that : *and users won't even notice the changes* ;o) Nonetheless plugins approach is more general and flexible, and it is also possible to develop a plugin to support the RPC-based integration with external issue trackers . The main difference is maintenance effort once it's up and running . ;o)

I think everyone can co exist, just not one at the cost of another ;)

+1 ... keeping relevant data in single place -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:

On Thu, Nov 12, 2009 at 11:45 AM, Jacob Kaplan-Moss <jacob@jacobian.org> wrote:

On Thu, Nov 12, 2009 at 1:30 PM, Guido van Rossum <guido@python.org> wrote:

...

Yeah, but you're not exactly an average user. Most users don't know how to use a bug tracker.

But they do know how to use mailing lists. Or IRC chats. Or support forums.

Those places have (for many projects) tens, hundreds, or even thousands of peers who are able and willing to help new users get started. Only the package maintainers see comments on PyPI, meaning we've got to deal with requests for support there manually.

This isn't academic; just this morning a user asked a question on Django's PyPI listing that would have been better asked on any of the support channels we provide. I have no way of directing him there besides lamely commenting after the fact, and then it just seems like I'm giving him the runaround.

Maybe that's an example of a user who doesn't know how to use those support channels? I know I wouldn't bother with IRC even if it was the only way to get in touch with users, I hate it with a vengeance. (Though arguably I'm a special case -- whenever I show up everyone goes "ooooh, Guido is here." :-) And I might not want to sign up for a mailing list for a casual question. And what exactly is a "forum"?

Look, nobody's asking to kill the feature. We're asking to *make it optional*, and to allow us to link to a more appropriate support forum instead. Can you please explain to me what's wrong with that?

I already said it was fine to make it opt-out. What more do you want? -- --Guido van Rossum (python.org/~guido)

On Thu, Nov 12, 2009 at 11:30:27AM -0800, Guido van Rossum wrote:

etc.). Maybe there should be a standard "social app" that you can just customize for a specific purpose. Sounds like an interesting project, actually.

For comments, haloscan and disqus are third-party comment-hosting services; http://redalt.com/blog/comment-services has a longer list. I don't know if any of them support rating of the posts or objects being commented on (as opposed to rating other comments, which is supported by some of them). Or if any of them can delegate moderation to the module authors, as opposed to the PyPI admins. PyPI's REST-style URLs also work nicely as keys or RDF identifiers, so it would be straightforward to use them for identifying ratings or comment threads. --amk

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Guido van Rossum wrote:

On Thu, Nov 12, 2009 at 11:25 AM, Jesse Noller <jnoller@gmail.com> wrote:

...

I'd not trust a package without a bug tracker, mailing list or link to the source a lot sooner than something without comments and ratings.

Yeah, but you're not exactly an average user. Most users don't know how to use a bug tracker. Also, there's a large variety of packages on PyPI. Not every developer has the same attitude, but they all live happily together on PyPI. (Or did you want someone to start a separate CPAN "for the rest of them" ? :-)

[...]

...

What about astroturfing? What's to stop me from writing a script to create a pile of accounts and then bumping packages I like with glowing ratings and reviews? Who is going to be the moderator, and how to decide between spam, incorrect comment, etc?

Those are all hard problems, though all of them have at least partial solutions in the other worlds (Amazon, Wikipedia, Apple app store, etc.). Maybe there should be a standard "social app" that you can just customize for a specific purpose. Sounds like an interesting project, actually.

The appstore analogy actually helps Jesse's case" "iFart in your general direction." (iFart is the top-rated app). Popularity and quality aren't related in any direct fashion. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAkr8kZMACgkQ+gerLs4ltQ4ScQCeJtYU9KkAq2K1Dkk0jK9ffHvB IuwAoNBWpMPFR1YsdhQN31oS1L5m91UL =qmmQ -----END PGP SIGNATURE-----

On Thu, 12 Nov 2009 at 15:42, Terry Reedy wrote:

Part of the pypi problem is a startup problem of initially low numbers. If the only people who bother to log in to rate are the disgruntled, then the ratings/reviews will be biased. I wonder how many of the people promoting the new feature have themselves logged in to systematically rate and possibly comment on every package they have looked at, and thereby kickstart the system with fair responses.

For what it's worth, I never look at PyPI. I get my packages either through Gentoo's portage or, if it isn't there (yet), by finding the package's home site through Google. So I'm a happy user of a number of packages, whose comments will never show up on PyPI. --David (RDM)

Except when they have a problem, and then they are likely to only complain through the comments.

As this theory has been repeated often here, I decided to go through all comments and classify them, as: - good: (overall) positive evaluation (possibly including minor criticism/wishes) - bad: negative evaluation, complaint, bug report - neutral: statement of fact (typically in response to some help request) Here is what I got: - good: 20 - bad: 11 - neutral: 9 So far, the theory that only complainers will comment cannot be substantiated by facts. Of course, it could be that all the negative comments come from easy_install users, and all the positive comments from people who browse through PyPI... Notice however that such easy_install users often would have to create a PyPI account first. Regards, Martin

And how many of the "good" comments are astroturfers?

If I understand that term correctly, it's about disguise: how would I be able to answer that question?

What's so bad about package maintainers from having an opt-out?

PyPI is not just (and perhaps not even primarily) there for the package authors, but for the package users (and not surprisingly, it's primarily the package authors who ask for banning the user opinions). I'm just not willing to submit to one side; hence the poll. Regards, Martin

Why can't we just disable it until we can come up with a better system that finds a balance between the rights of maintainers, and those of the user?

Because I want to wait for the outcome of the poll first. Regards, Martin

Ben Finney <ben+python <at> 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. cheers Antoine.

Ben Finney <ben+python <at> 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.

As Ian says: setuptools relies on it. It's part of the specification of the package index. Regards, Martin

On Fri, Nov 13, 2009 at 12:44 AM, Ben Finney <ben+python@benfinney.id.au> wrote:

"Martin v. Löwis" <martin@v.loewis.de> writes:

...

...

Why can't we just disable it until we can come up with a better system that finds a balance between the rights of maintainers, and those of the user?

Because I want to wait for the outcome of the poll first.

There's a problem with the poll's placement: on the front page of the PyPI website.

I only know about the poll because you said there was one, and I went hunting for it. The front page of PyPI is not one I ever visit, as a package maintainer; I'll visit the pages for the packages I maintain, or make a specific search of packages I'm looking for.

So, the poll's audience is limited to those who visit the front page (which is hardly ever necessary for package maintainers), and those who already know it exists (e.g. through this discussion thread). You'll be missing the opinions of those maintainers who, like the OP of this thread, only discovered the behaviour much later.

This poll is only visible if you're logged into PyPI. This strikes me as a mistake. I went looking for a poll and didn't see it. I only found the poll by accident by wondering randomly what might change if I hit the login using open id button. So you can only vote in the poll if you a) get told about it b) realise you need to create an account to login and use in order to vote. I realise there's good reasons for that, but I think it's a mistake. (There's no guidance that you need to log in to see the poll for example) Michael.

Ben Finney schrieb:

Michael Sparks <sparks.m@gmail.com> writes:

...

On Fri, Nov 13, 2009 at 12:44 AM, Ben Finney <ben+python@benfinney.id.au> wrote:

...

So, the poll's audience is limited to those who visit the front page (which is hardly ever necessary for package maintainers), and those who already know it exists (e.g. through this discussion thread). You'll be missing the opinions of those maintainers who, like the OP of this thread, only discovered the behaviour much later.

This poll is only visible if you're logged into PyPI. This strikes me as a mistake. I went looking for a poll and didn't see it.

The mistake, I think, is having a poll basically asking “what should the PyPI maintainers do?”, instead of weighing evidence and reasoned arguments. A poll may be good for gathering preferences and opinion, but it's a poor way to make a *decision*.

I haven't seen Martin commit to doing whatever the poll's preferred outcome was. I think it's just to see if there is really so much silent resistance or support as is claimed by both arguing sides. 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.

2009/11/13 Tres Seaver <tseaver@palladion.com>:

I can see the information about the poll, and a link to view the results, without logging in.

 http://pypi.python.org/pypi

(second paragraph there).  That paragraph tells you that you need to log in to vote in the poll.

I don't want to create a PyPI account (more account details I'll rarely use to remember) just to vote. I can see why anonymous votes are bad, but the sample's going to be self-selecting - people like me who don't want to create an account will be excluded. By the way, there's no way for me to vote that I don't care what option ends up being chosen, but I strongly oppose choosing something that would tend to make developers avoid using PyPI. The distutils/setuptools/distribute/... saga has fragmented Python's package ecosystem enough already. Let's not have PyPI go the same way :-( Paul.

On Sat, Nov 14, 2009 at 08:43:25AM +1100, Ben Finney wrote:

There's also no option to vote that decisions on how to manage Python infrastructure (like PyPI) shouldn't be made by popular vote.

If the open source approach of 'the maintainer decides' is followed, well, both the maintainer of the code and the admin of the site is Martin. Comments stay, then. If 'BDFL decides' is followed, GvR thinks the idea is reasonable (http://mail.python.org/pipermail/python-dev/2009-November/094058.html), though the implementation might be improved. Again, comments stay. If popular vote is ruled out, I don't see who else could possibly make the decision to disable comments and/or ratings. --amk

"A.M. Kuchling" <amk@amk.ca> writes:

If popular vote is ruled out, I don't see who else could possibly make the decision to disable comments and/or ratings.

Reasoned argument with the person who decides. A bad idea with many people's support is still a bad idea; a good idea with few people's support is still a good idea. -- \ “I have a microwave fireplace in my house. The other night I | `\ laid down in front of the fire for the evening in two minutes.” | _o__) —Steven Wright | Ben Finney

[We really should be discussing this on catalog-sig, but moving things mid-thread never works, so here we go. I apologize to python-dev. I also apologize for the length.] On 2009-11-13 17:18 PM, Steven D'Aprano wrote:

On Sat, 14 Nov 2009 09:57:18 am Ben Finney wrote:

...

"A.M. Kuchling"<amk@amk.ca> writes:

...

If popular vote is ruled out, I don't see who else could possibly make the decision to disable comments and/or ratings.

Reasoned argument with the person who decides. A bad idea with many people's support is still a bad idea; a good idea with few people's support is still a good idea.

Okay, let's talk reasoned debate.

I understand the reason for making comments compulsory: they're for the benefit of the users, not the package owner. It helps prevent information about the package from being fragmented: there is One Obvious place to find out about a package on PyPI, which is the PyPI page, instead of having to search for blogs where people may or may not have made comments about the package. If individual package owners don't like this, too bad, because PyPI is run for the benefit of the community, not individual package owners.

I understand the reason for making comments optional: personal choice of the package owner is valuable in and of itself, even if it is against the best interests of the community.

But for the life of me, I can't understand the 1/3 of the votes that have been cast in favour of prohibiting comments for everybody, even those who want comments.

While I do have a couple of packages on PyPI, I use PyPI as a consumer of packages much more frequently, every day in fact. I voted against comments and ratings because I think it is a detriment to my experience of PyPI as a user (I also think that they will be a detriment to the community, but that's a prediction, not a fact). Short form comments are simply not useful to me. Ratings are worse. They do not carry reliable information; they carry short statements of opinion from a wide variety of experiences, most of which are entirely unrelated to my own needs. To make an example, I have a lot of experience making ornery stuff build. A lot of other people don't. Their personal experience of not managing to install a package correctly turns into a weird, objective-seeming statement that the "package is difficult to build". People have different thresholds, different experiences, and different standards. When such opinions get numerically aggregated by a monolithic rating system, that's even worse. Even with short-form comments, they have the ability, though often not the propensity, to give a little bit of information ("I had trouble building it on Windows.") that can help me tease out whether their experiences will be relevant to mine, but one star is just one star. I *do* like to read long-form reviews where people relate what their needs were, what they tried to use the package for, and exactly where the package succeeded and where it failed. I can compare that context with my own needs and extract the relevant parts of their experience. Blogs are great for that. Now I do appreciate ratings and comments on shopping sites if they don't provide the capability for long-form reviews. But that's because the product is locked behind the barrier of payment and often shipping. There is no such barrier on PyPI. If I can get to a web view of their repository, thirty seconds with it will give a much better idea of whether the package is worth trying than any amount of comments I could read in that time. I can easily see how much documentation they have, if they have funny build requirements, if they are just prototyping, etc. without needing to trust that everyone else has needs and standards like mine. That's the key difference between comments and ratings on shopping sites and why I don't think that their success in that field translates to here. If you want one idea that would make my use of PyPI much more pleasant and informative, it would be to add a "Repository-URL" entry to the recommended PyPI metadata so that I could always start looking at the code in one click. Or integrate the source code browsing into PyPI itself; it could open up the sdists and eggs and show a WebVCS-like browser interface. Now, these are all reasons why commenting and rating are not beneficial to me. Where I think they are harmful is that when one is exposed to them, one cannot just ignore them. They have an emotional, unreasonable impact whether I want them to or not. And that's why I do not want to see them. Give me access to information, not opinions. If authors do want comments and ratings on their packages, let them use the services that already exist for *just* that purpose like Ohloh. They have the time and energy to implement these mechanisms with the care and attention that they need. -- 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

+1

Having a "Repository-URL", "Repository-Browse-URL" and a "Bug-Tracker-URL" field in PyPI would be a lot more usefule then comments and ratings.

+1

On approximately 11/14/2009 7:29 AM, came the following characters from the keyboard of Floris Bruynooghe:

Having a "Repository-URL", "Repository-Browse-URL" and a "Bug-Tracker-URL" field in PyPI would be a lot more usefule then comments and ratings.

+1 Here's a thought... if the author supplies the above URLs, then comments would be prevented, in favor of using the author-supplied system. If the author doesn't supply the above URL, or someone reports that the URLs don't work, then comments on PyPI would be enabled. -- Glenn ------------------------------------------------------------------------ “Everyone is entitled to their own opinion, but not their own facts. In turn, everyone is entitled to their own opinions of the facts, but not their own facts based on their opinions.” -- Guy Rocha, retiring NV state archivist

Robert Kern a écrit :

While I do have a couple of packages on PyPI, I use PyPI as a consumer of packages much more frequently, every day in fact.

Another "consumer" opinion: when investigating a new package, I usually look for the following things, in that order: 1) the "big picture" description: is there a coherent design? does it fit my needs? On PyPI, the description field should provide that. 2) the changelog: is the project still alive? are bugs fixed, or just features added? is the code rewritten from scratch for each release? Well, every project on PyPI should have a public changelog, so a link to that fits my need. 3) documentation: I don't necessarily care for the number of lines, but more whether it is understandable and goes into sufficient detail to not leave me guessing. Again, a link to the docs fits my needs. A single number (number of documentation lines,...) does not. 4) a mailing list archive (or newsgroup, or web forum), where I'm looking for signs of a healthy community. I usually go for the -devel list, but a -user list will do as well if the committers keep an eye on it. If a healthy community exists around a project, I will completely disregard comments, if present: time invested in the community speaks louder than the opinion of random bystanders. Only for small projects with no real community will I look at the comments (+ answers from the author) in order to make an opinion on the developpement process. I always disregard ratings. So as a conclusion about comments, they can have their use for projects without a publicly archived mailing list, but can otherwise be *replaced* by a direct link to a list archive. This could be a reasonable default for PyPI: disable comments when a link to a list archive is provided. While my experience may not be that of a typical user, I believe users will ultimately make use of all information they are provided. So it is important to provide the most relevant information, and not just what naive users ask for. Cheers, B.

On Fri, Nov 13, 2009 at 1:33 PM, Paul Moore <p.f.moore@gmail.com> wrote:

By the way, there's no way for me to vote that I don't care what option ends up being chosen, but I strongly oppose choosing something that would tend to make developers avoid using PyPI.

I think the damage has already been done. There are enough people -- I'm one -- who feel this has revealed huge flaws in PyPI's stewardship. I'm pretty convinced, results of the poll or not, that the way PyPI is being run is fatally flawed. This "poll" business is just smoke and mirrors, anyway -- notice the way the "no comments" votors are split among three choices, while the "pro comments" voters have just two choices. It's also worded in a way that obscures the real debate. Regardless of the outcome, the poll's not going to change anyone's mind, and it certainly won't change the fact that PyPI's being run as a one-man show, not as a community resource. I'm just not comfortable with that. Unless PyPI changes its governance radically, I'm not going to invest any more effort in it. Jacob

On Sat, 14 Nov 2009 10:19:17 am Steven D'Aprano wrote:

On Sat, 14 Nov 2009 09:17:40 am Jacob Kaplan-Moss wrote:

...

This "poll" business is just smoke and mirrors, anyway -- notice the way the "no comments" votors are split among three choices, while the "pro comments" voters have just two choices.

What?

Allow ratings and comments on all packages (status quo) Allow package owners to disallow comments (ratings unmodified) Allow comments, but only send them to package owners (ratings unmodified) Disallow comments (ratings unmodified) Disallow ratings and comments (status three months ago)

That's three choices for allowing comments, two for disallowing.

Sorry, I should have been more explicit: The first choice makes comments compulsory. In other words, comments are allowed. The second choice makes comments optional. Whether it is opt-in or opt-out, PyPI still allows comments as an option. The third choice makes comments available, but private. That's still allowing comments. Only the fourth and fifth options disallow comments. If you don't want there to be comments on PyPI, you only have two choices: 4 or 5. -- Steven D'Aprano

Jacob Kaplan-Moss wrote:

that obscures the real debate. Regardless of the outcome, the poll's not going to change anyone's mind, and it certainly won't change the fact that PyPI's being run as a one-man show, not as a community resource.

While I may not agree on his choices regarding comments and ratings, I don't feel this is fair to Martin. No one else, as far as I know, has offered to step up and help with the maintenance of PyPI. I don't know if Richard is still active, but the lack of response from him would suggest not. A test on your hypothesis would be to offer to help. I don't know who has access to the server the software runs on, but ultimately any core python committer can change the code in the subversion repository. I did just actually have a look over the code and was happy to find it was a lot simpler than I had feared but a bit dismayed at the style of coding and total lack of unit tests ;-) I might well be up for helping with the maintenance of PyPI if I'm welcome, especially as I'm already familiar with a lot of the components used, although I don't know how much time I can commit :-( Martin, are you interested in help? Chris PS: While I'm sure a lot of python-dev people are interested in this topic, I'm pretty sure this whole huge sprawling thread belongs on catalog-sig... -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

On Fri, Nov 13, 2009 at 6:44 PM, Chris Withers <chris@simplistix.co.uk> wrote:

PS: While I'm sure a lot of python-dev people are interested in this topic, I'm pretty sure this whole huge sprawling thread belongs on catalog-sig...

+100

Paul Moore wrote:

2009/11/13 Tres Seaver <tseaver@palladion.com>:

...

I can see the information about the poll, and a link to view the results, without logging in.

http://pypi.python.org/pypi

(second paragraph there). That paragraph tells you that you need to log in to vote in the poll.

I don't want to create a PyPI account (more account details I'll rarely use to remember) just to vote. I can see why anonymous votes are bad, but the sample's going to be self-selecting - people like me who don't want to create an account will be excluded.

This is indeed intentional: people like you won't upload packages to PyPI, nor will they take part in the rating system, as both require a PyPI account. Regards, Martin

...

...

I don't want to create a PyPI account (more account details I'll rarely use to remember) just to vote. I can see why anonymous votes are bad, but the sample's going to be self-selecting - people like me who don't want to create an account will be excluded.

This is indeed intentional: people like you won't upload packages to PyPI, nor will they take part in the rating system, as both require a PyPI account.

Which is bizarre, since Paul belongs to the group of people you say you care most about - i.e., those people browsing the index and looking for packages. The *consumers* of the comments, in other words.

Ok: "intentional" is not the right attribute. It's more that I don't consider it too harmful. Regards, Martin

Terry Reedy <tjreedy@udel.edu> writes:

Martin v. Löwis wrote:

...

...

...

This is indeed intentional: people like you won't upload packages to PyPI, nor will they take part in the rating system, as both require a PyPI account.

Why? I already have python tracker account and a python wiki account which is already 2 too many. The latter was a pain because the site lost my registration and as of a year ago, the registration process was broken. I would much prefer just one python site registration.

And that registration should be using any OpenID, so that I don't need any new identities to participate on the Python sites: I can re-use existing identities. I would make a bug report for that, but the Python bug tracker also requires yet-another-identity. It's lunacy. -- \ “Value your freedom or you will lose it, teaches history. | `\ “Don't bother us with politics,” respond those who don't want | _o__) to learn.” —Richard Stallman, 2002 | Ben Finney

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

Ben Finney writes:

...

I would make a bug report for that, but the Python bug tracker also requires yet-another-identity. It's lunacy.

No, it's legacy. The software predates the availability of OpenID.

I don't agree that's a “no”; it's a “yes, and” :-)

If you'd like to integrate Open ID authentication into Roundup, I will personally be happy to do the followup required to get the patch on the radar of the Python site and Roundup software maintainers.

I'll give the usual caveat of “this is but one of the many services I would like to be able to authenticate in with OpenID”, but it's a caveat rather than a rejection. I'll keep your kind offer in mind in case I get the bandwidth to take that on. -- \ “Our products just aren't engineered for security.” —Brian | `\ Valentine, senior vice-president of Microsoft Windows | _o__) development, 2002 | Ben Finney

"Martin v. Löwis" <martin@v.loewis.de> writes:

...

And that registration should be using any OpenID, so that I don't need any new identities to participate on the Python sites: I can re-use existing identities.

PyPI actually does support OpenID.

I commend the PyPI administrators for this step, but the implementation is currently insufficient: it conflates a user's OpenID (their identity, as a URL) with their OpenID provider (the service which the person has chosen to do the authentication check and serve the data). That's what I meant by “should be using any OpenID”. One of the best features of the OpenID system is identity delegation: that one's identity can be decoupled from the service behind the scenes which provides that identity. This is important, because it means I am not tied to a particular provider to maintain my identity; if they no longer provide my identity in a way I like, I can switch to a different provider while keeping the same identity. Fred can use his own OpenID ‘fred.example.org’, initially set up behind the scenes to delegate to ‘bigcorp.example.com’ as the provider. Any time he likes, Fred can *change* which provider is actually used for authentication, without changing his OpenID. PyPI gets to find out which provider Fred is using for the identity ‘fred.example.org’ each time it performs discovery on that identity, not before. So, PyPI should not be asking the user “what is your provider?” since that's (a) a detail irrelevant to the user if they just know their OpenID, (b) liable to change independent of the OpenID, and (c) discoverable from the OpenID auth process anyway. PyPI should instead ask the user for their OpenID (‘fred.example.org’), without discussing providers. Then, attempt to authenticate that user, at which point PyPI automatically gets to find out which provider is in use (‘bigcorp.example.com’). If you *then* want to be picky and complain that PyPI refuses identities provided by ‘bigcorp.example.com’, that's the time to do it. I hope that makes more sense. -- \ “Geeks like to think that they can ignore politics. You can | `\ leave politics alone, but politics won't leave you alone.” | _o__) —Richard Stallman, 2002-07-26 | Ben Finney

"Martin v. Löwis" <martin@v.loewis.de> writes:

...

Fred can use his own OpenID ‘fred.example.org’, initially set up behind the scenes to delegate to ‘bigcorp.example.com’ as the provider. Any time he likes, Fred can *change* which provider is actually used for authentication, without changing his OpenID. PyPI gets to find out which provider Fred is using for the identity ‘fred.example.org’ each time it performs discovery on that identity, not before.

Does that actually work? What actual OpenID provider allows me to claim 'fred.example.org' as my OpenID?

It's inherent in the protocol, and any standards-conformant provider supports it. If Fred controls ‘fred.example.org’ (i.e. can cause that URL to serve a document of his choosing), then Fred gets to delegate to any OpenID provider, and can change it at any time while keeping the same identity URL. If Albert, on the other hand, doesn't want to set up a URL under his control but instead just use an identity managed by someone else, that's a perfectly valid option: he can use ‘bigcorp.example.com/albert’ as his OpenID, and BigCorp will take care of being the endpoint as well. Albert is not getting any benefit from identity delegation (he's going to have a transition difficulty at some later date when he decides BigCorp isn't serving his identity needs any more), but neither is he required to know about delegation or other protocol details.

Sure, one can use authentication delegation, by means of the openid.delegate link. However, that still doesn't make the claimed identifier fred.example.com, but bigcorp.example.com/fred.

That's not right (this is what I mean by unnecessarily conflating “who provides the identity this time” with “what is the identity”). The ‘bigcorp.example.com/fred’ URL is *not* Fred's identity in our example, it is only the “endpoint URL”: where Fred has configured his delegation to go. Having control over ‘fred.example.org’, Fred configures delegation, and then can happily forget the endpoint URL in his daily activities. When asked for his OpenID, Fred uses ‘fred.example.org’. Albert, on the other hand, has punted on the whole issue of delegation; he uses ‘bigcorp.example.com/albert’ as his OpenID, because BigCorp causes that URL to be both an OpenID and an endpoint. That's still fine as far as the authentication process is concerned. But the relying party (the party requesting an OpenID from the user; in this case the relying party is PyPI) should not ask the user what their provider is. The user is asked only for their OpenID: Fred will provide ‘fred.example.org’, Albert will provide ‘bigcorp.example.com/albert’. PyPI discovers automatically, each time they use those identities, where the provider is this time by using the OpenID discovery step on the identity they provide. Fred is very happy for this, since he can keep using ‘fred.example.org’ even if he later changes which provider he's delegating to. Albert is very happy for this, because he doesn't have to know anything about “provider” or “delegation” or “endpoint”, he just needs to remember his OpenID. PyPI's user interface becomes simpler, because it only needs to ask the user “what is your OpenID?” and the rest is taken care of by the OpenID protocol implementation.

Please correct me if I'm wrong.

I hope that helps. The documents at <URL:http://openid.net/developers/> may be useful if you need more specifics. -- \ “Computer perspective on Moore's Law: Human effort becomes | `\ twice as expensive roughly every two years.” —anonymous | _o__) | Ben Finney

...

So the only thing users gain with delegation is that they don't need to remember the tedious URL that their provider assigns them. When they switch providers, their claimed ID will still change, and they'll have to reregister in all services they use.

No, the whole point of delegation is that I can use voidspace.org.uk as my openid - backed with any provider I want. I can then use voidspace.org.uk as my openid and not be tied to any provider.

I'm fairly skeptical that you actually do use voidspace.org.uk. I can believe that this is what you type into the openid field - but the ID that is validated to the relying party is http://fuzzyman.myopenid.com/. So when you change the provider (and hence the openid.delegate value), you will have to create new accounts for all services that you use, right?

I'm afraid the PyPI implementation of openid is useless to me too - I want to use voidspace.org.uk as my openid but it doesn't let me.

See above - the services may let you *enter* that string, but it isn't your openid. Regards, Martin

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. From the OpenID 1.1 specification: # Now, when a Consumer sees that, it'll talk to # http://www.livejournal.com/openid/server.bml and ask if the End User # is exampleuser.livejournal.com, never mentioning www.example.com # anywhere on the wire. So all I (as a relying party) get verifyied is fuzzyman.myopenid.com. Why should I trust that voidspace.org.uk is actually a valid ID? Can't you then produce hundreds of IDs, all delegating to the same identity? 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? Regards, Martin

...

Can't you then produce hundreds of IDs, all delegating to the same identity?

Yes.

But then, users can easily create as many fake accounts as they want to. This is not something I want to happen (it's still possible to setup fake accounts, but it should be more difficult for the average script kiddy).

If the provider dictates the identity, as you keep insisting, that sentence makes no sense whatsoever. The value entered as the identifier is the identifier you should use. Otherwise, what's the point of delegation at all?

It may help users to remember their openid more easily, and always fill in the same text into the login box. Regards, Martin

Martin v. Löwis wrote:

...

...

Can't you then produce hundreds of IDs, all delegating to the same identity?

Yes.

But then, users can easily create as many fake accounts as they want to. This is not something I want to happen (it's still possible to setup fake accounts, but it should be more difficult for the average script kiddy).

This doesn't seem to be a problem for all the other sites I use my openid with. Why not allow users to login with their own openid, but only allow one account to refer back to the same delegated account? Michael

...

If the provider dictates the identity, as you keep insisting, that sentence makes no sense whatsoever. The value entered as the identifier is the identifier you should use. Otherwise, what's the point of delegation at all?

It may help users to remember their openid more easily, and always fill in the same text into the login box.

Regards, Martin

-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog

Martin v. Löwis wrote:

[snip...]

...

Why not allow users to login with their own openid, but only allow one account to refer back to the same delegated account?

That sounds good. I'm not sure how to implement a provider change in that scenario, though.

Even not having provider changes supported would still allow me to use my openid with PyPI which would be great. The only problem with changing provider that I can see is when the provider a user changes to would then be a duplicate - in which case I think just refusing to allow the login would be fine (rather than changing the provider for that account). All the best, Michael

Regards, Martin

-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog

Martin v. Löwis wrote:

...

Even not having provider changes supported would still allow me to use my openid with PyPI which would be great. The only problem with changing provider that I can see is when the provider a user changes to would then be a duplicate - in which case I think just refusing to allow the login would be fine (rather than changing the provider for that account).

In that case, it would be much easier to record your true openid (i.e. the one that your provider is able to validate). You can then enter the alias that you are used to, and PyPI would map that right away to the verifiable ID, and log you in with that.

Would it be possible to detect a change of provider and then offer the option to migrate the account to the new provider (so long as it does not conflict with another account)?

For this to work, you would have to upgrade your web page to OpenID 2, as this is the only protocol that PyPI supports.

This I can do. Thanks Michael

Regards, Martin

-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog

Martin v. Löwis wrote:

...

Would it be possible to detect a change of provider and then offer the option to migrate the account to the new provider (so long as it does not conflict with another account)?

That would be possible - but again complicate the UI.

Why? You should only need to present this option *after* the user has authenticated with the a different provider to the one associated with their account (or perhaps on detecting that the provider is different - but either way no UI changes until / unless the user actually has changed provider). That complicates the UI code perhaps, but shouldn't change the standard UI. I don't think it should be given as an option to the user before they have changed provider, given that one of the major use cases is to allow the user to switch provider if their current one becomes unavailable. A UI that only allows them to switch provider if they can first login via their current provider would lock them out if their provider goes down. Michael

Regards, Martin

-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog

Martin v. Löwis wrote:

Michael Foord wrote:

...

Martin v. Löwis wrote:

...

...

Would it be possible to detect a change of provider and then offer the option to migrate the account to the new provider (so long as it does not conflict with another account)?

That would be possible - but again complicate the UI.

Why? You should only need to present this option *after* the user has authenticated

That's what I mean - it's another HTML form to present, in certain cases.

It would be easier to change the underlying ID silently, and refuse login if that then would conflict with an existing account.

Sounds good to me. Michael

Regards, Martin

-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog

Why? I already have python tracker account and a python wiki account which is already 2 too many. The latter was a pain because the site lost my registration and as of a year ago, the registration process was broken. I would much prefer just one python site registration.

Then I recommend that you get a google account for your email address, and register to PyPI using OpenID. Regards, Martin

Martin> Then I recommend that you get a google account for your email Martin> address, and register to PyPI using OpenID. I've never found OpenID at all intuitive to use. Are there instructions on pypi.python.org which detail the steps necessary to use OpenID to login? I saw the "Claim OpenID" link on my PyPI profile page. So now I have an OpenID URL. What am I supposed to do with that? If I visit that URL it downloads a small bit of XML. I've tried using my Yahoo! and Luanchpad OpenIDs for other sites in the past. I've never successfully logged into any website with them, at least not as far as I can recall. I realize that maybe this is something that just doesn't click with me (maybe I'm an OpenID Luddite), but it seems to me that OpenID needs to be a bit easier (or obvious?) to use if it's to become some sort of de facto standard login mechanism. Skip

Martin> That's indeed what PyPI attempts to do. At the "claim openid" Martin> place, follow the Launchpad link. It should guide you through Martin> the procedure. Well, since I use Google a lot more I'd prefer to use that. If I click the Google OpenID link I now get OpenID is already claimed Martin> Then, when you want to login, again follow the Launchpad link on Martin> the front page. That seems to work, but I'm not sure how. Doesn't seem to use cookies. The Google OpenID link leads to http://pypi.python.org/pypi?:action=login&provider=Google which contains nothing about me. I saw a pypi.python.org cookie which expires "On Quit", so I restarted Camino and verified there were no pypi.python.org cookies, then clicked the Google OpenID link. It still works. I must be missing something obvious... S

Martin> It's far from obvious. It's called "provider-driven identifier Martin> selection". PyPI redirects your browser to Google. Google looks Martin> at the Google cookie, and finds your identity; they also see Martin> that you have opted to automatically log into PyPI. So without Martin> further questions, they redirect you back to PyPI. PyPI finds Martin> your account, and displays a logged-in page. Thanks. Makes sense now... Skip

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 P.J. Eby wrote:

At 09:45 AM 11/14/2009 +0100, Martin v. Löwis wrote:

...

Paul Moore wrote:

...

2009/11/13 Tres Seaver <tseaver@palladion.com>:

...

I can see the information about the poll, and a link to view the results, without logging in.

http://pypi.python.org/pypi

(second paragraph there). That paragraph tells you that you need to log in to vote in the poll. I don't want to create a PyPI account (more account details I'll rarely use to remember) just to vote. I can see why anonymous votes are bad, but the sample's going to be self-selecting - people like me who don't want to create an account will be excluded. This is indeed intentional: people like you won't upload packages to PyPI, nor will they take part in the rating system, as both require a PyPI account.

Which is bizarre, since Paul belongs to the group of people you say you care most about - i.e., those people browsing the index and looking for packages. The *consumers* of the comments, in other words.

I agree with Martin that anonymous votes, like anonymous comments, are process-harmful here. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAksA0aYACgkQ+gerLs4ltQ4WEACfUJmt5LEFujv5xZNCl1tbDGzR CrIAoKUtK10tQVIiEbDljaHhyTssr4r5 =+UqM -----END PGP SIGNATURE-----

I only found the poll by accident by wondering randomly what might change if I hit the login using open id button. So you can only vote in the poll if you a) get told about it b) realise you need to create an account to login and use in order to vote. I realise there's good reasons for that, but I think it's a mistake. (There's no guidance that you need to log in to see the poll for example)

Why do you say that? "If you want to vote, you need to login to PyPI (on the right)." If that isn't clear to you, please propose a rephrasing (English is not my native language, nor the native language of MAL who proposed this specific wording) Regards, Martin

A.M. Kuchling wrote:

On Fri, Nov 13, 2009 at 11:44:42AM +1100, Ben Finney wrote:

...

There's a problem with the poll's placement: on the front page of the PyPI website.

I've posted a tweet to the ThePSF account about the poll. If the poll runs for a week or two, that would provide time for word of the poll to propagate through Twitter, blogs, etc.

You should also make an announcement on python-announce. -- 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

There's a problem with the poll's placement: on the front page of the PyPI website.

You really should participate in the proper forum for the discussion of PyPI: catalog-sig. Then you would have noticed that I said I'll announce the poll later (i.e. today), which I'm doing right now. Feel free to announce it places where I didn't. Regards, Martin

Jacob Kaplan-Moss <jacob@jacobian.org> writes:

If the poll ended this moment, how would you judge? Would it just be mob rule (no comments)? […]

Even though that's my preferred option, I *don't* want it chosen on the basis of a poll result, but on the basis of evidence and reasoned argument.

On a deeper level, why are we voting at all? When else in the history of Python have we used popular vote to decide questions of this nature?

+1 -- \ “I do not believe in immortality of the individual, and I | `\ consider ethics to be an exclusively human concern with no | _o__) superhuman authority behind it.” —Albert Einstein, letter, 1953 | Ben Finney

Matthew Woodcraft <matthew <at> woodcraft.me.uk> writes:

It seems clear to me that, given those figures, allowing comments would not be following the result of the vote.

So I think that simply implementing the option that receives most votes is not a wise plan.

Can we defer any further discussion about this until the poll is closed? Thank you Antoine.

Steven D'Aprano <steve@pearwood.info> wrote:

Why do you think it is okay to combine the Disallow vote, without also combining the Allow vote? Less than a third of the total votes are in favour of disallowing comments, with two-thirds in favour of allowing them.

I don't. I was giving one example of the problem with the plan of not combining options at all. I wasn't writing to take sides. I was trying to say that using 'first past the post' voting with five options which are combinations of different issues (comments, ratings, whether to allow package owners to opt out) can't be expected to give a good decision. I think there is no safe way to pick a winner from this vote (unless more than half the voters choose a single option). (As a general point, in any discussion it tends to be unhelpful to ask "Why do you think X" unless the person you're asking has clearly indicated that they do in fact think X.) -M-

On 13 Nov 2009, at 00:34 , Jesse Noller wrote:

That's because as an author/maintainer - we have methods of giving feedback and communication. Why not rate ( or auto-rate) packages on objective criteria?

E.g.: tests and test coverage, docs, installs on python version X, Y, Z, works on windows, etc? Because there are lots of subjective criteria which are still very useful to users? The feeling of the API, the completeness of the library or its flexibility, etc…?

If pypi one day has a CPAN-style buildbot farm allowing it to test the package on any platform under the sun, that can be included, the tests can be included as well but given the number of testing solutions (and coverage discovery associated) that would be quite an undertaking. And as far as docs go, what would be the criterion? "Has documentation"? How do you define "has documentation"? Has auto-extracted documentation from the docstrings? Has a README? Has a complete sphinx package? I don't think there's much that you can rate "objectively" about documentation.

David Lyon wrote:

On Fri, 13 Nov 2009 00:44:30 +0100, Xavier Morel <catch-all@masklinn.net> wrote:

...

If pypi one day has a CPAN-style buildbot farm allowing it to test the package on any platform under the sun, that can be included, the tests can be included as well but given the number of testing solutions (and coverage discovery associated) that would be quite an undertaking.

I'm working on such a thing in my spare time. Yep, it's a big time commitment.

http://bitbucket.org/djlyon/pypi-package-testbot/

See also http://pycheesecake.org/ Regards, Martin

David Lyon wrote:

On Fri, 13 Nov 2009 01:14:54 +0100, "Martin v. Löwis" <martin@v.loewis.de> wrote:

...

http://pycheesecake.org/

Ok, so what is the current status on it?

Not sure; you would have to ask Grig. 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. Regards, Martin

Hi All, What do people think about this idea? I've actually started writing something to try to to do this and create sn automated scoring system for the packages on pypi. It was started last week based on Guido's comments on the distutils mailing list.

Why not rate ( or auto-rate) packages on objective criteria?

E.g.: tests and test coverage, docs, installs on python version X, Y, Z, works on windows, etc?

Quality can be measured. Me being a total failure and not reading the docs, and failing to install something is subjective. I don't disagree with the goal of giving *users* a voice, but is PyPI the right place for that? How many moderators do we have to watch comments? Can other users down vote comments by people which are simply *wrong*?

Why can't we just disable it until we can come up with a better system that finds a balance between the rights of maintainers, and those of the user?

But you can bet your ass that if PyPI isn't made a good, neutral, central resource I'm going to leave for one that is. Do you really want a flood of package maintainers de-listing their packages just so that things work the way you think they should?

I should clarify that I'm speaking personally and not in any official "Django capacity." I don't have personal control over whether or not Django would de-list from PyPI. Django's run by a community process, and I'd listen to the voice of the community before doing anything unilaterally. It's a good idea, this community process. We might want to apply it to PyPI one of these days.

And indeed, I do: feel free to participate in the poll. Regards, Martin

On Fri, 13 Nov 2009 10:54:50 am Ben Finney wrote:

"Martin v. Löwis" <martin@v.loewis.de> writes:

...

PyPI is not just (and perhaps not even primarily) there for the package authors, but for the package users (and not surprisingly, it's primarily the package authors who ask for banning the user opinions).

No-one here is asking for “banning the user opinions”.

That's EXACTLY what people have asked for: the ability to ban user comments. Sure, some of them say they want to "opt-out", or "disable comments", but that's just a polite way of saying the same thing. Some of them -- 44% of the people who have responded to the poll as of a minute ago -- want to prohibit *all* comments, even for packages whose authors wants to receive comments. WTF? The original poster (Ludvig Ericson) started this thread insisting that there were only two acceptable options: prohibit all comments on PyPI, or make it opt-in. I quote: "As I see it, there are only two ways to fix these misguided steps of development: throw them out, or make them opt-in settings."

As already pointed out, users are not mute; there are plenty of places for them to have a voice.

Ben, you've been talking recently about the dangers of fragmenting the Python community into multiple forums, but that's what you're arguing for on PyPI. I'm a user, I'm interested in a package, so I look for it on PyPI. I want to know what others think about it, before I commit to downloading it, installing it and seeing if it meets my needs. Instead of looking in the One Obvious place, the PyPI page, you want me to go off looking for blogs, mailing lists, or other forums, which might not even exist. Part of the value of a centralised place for comments on a package is that I can see whether other users agree with the comment or not. If I see a comment "This doesn't even work", and ten other comments saying "No, this is great, but you need to transmogrify the phlogiston first to get it to work", I've learned something useful. But if I stumble across a single blog that says "This doesn't work", I've actually been given negative knowledge: I've learned something that just isn't so. What *actual* problem are we trying to solve here? Is there a problem with spam on PyPI? No. Is there a problem with the comments being wildly biased, either for or against? Apparently not. Is there a problem with people using the comment system as a help forum? No. So what's the problem we're trying to solve?

I understand the mood here to be, not that user feedback is not wanted, but rather that PyPI in particular should be a place for *objective* data about a package.

Who is responsible for gather this "objective" data? How do we decide what is objective and what isn't? People can't even agree on the validity of benchmarks! This is open source. The power of the bazaar, remember? I'm amazed at how many people are not just disinterested in, but actively hostile, to even *useful* comments from users. That's fine. If you, the package author, don't care about comments from users, don't read them. But they're not there for *your* benefit, they're there for the benefit of other users. -- Steven D'Aprano

On Fri, 13 Nov 2009 07:42:37 am Terry Reedy wrote:

Part of the pypi problem is a startup problem of initially low numbers. If the only people who bother to log in to rate are the disgruntled, then the ratings/reviews will be biased.

The package author who started this thread, Ludvig Ericson, had (as of last night) two comments, one positive, one negative. This admittedly tiny sample doesn't suggest to me that PyPI is suffering from the problem of biased ratings. -- Steven D'Aprano

Steven D'Aprano <steve@pearwood.info> writes:

On Fri, 13 Nov 2009 05:54:24 am Guido van Rossum wrote:

...

I agree that creating a good social app is not easy, and if we can't improve the social app embedded in PyPI quickly enough, we should at least give authors the option to disable comments. Of course, as a user, I might not trust a module that has no reviews or ratings.

As a user, I'd be more likely to trust a module with no reviews/ratings than one where the author disabled reviews/ratings. The first says "nobody hated it enough to complain", the second one says "the author is trying to hide something".

Agreed, that's how I'd feel (and it's important to note that this would be an emotional, not necessarily entirely rational, reaction) as a user also. Package maintainers who also see that users would feel that way, and who agree with the purpose of PyPI as a common repository of all third-party packages, but who *don't* want to deal with PyPI's implementation of comments (whatever that may be at any time), have a clear option: to avoid hosting the package at PyPI at all. That's harmful, and I don't want it; but I don't see an alternative for such a maintainer. -- \ “Dvorak users of the world flgkd!” —Kirsten Chevalier, | `\ rec.humor.oracle.d | _o__) | Ben Finney

On Thu, 2009-11-12 at 08:25 -0600, Barry Warsaw wrote:

That's distressing. For better or worse PyPI is the central repository of 3rd party packages. It should be easy, desirable, fun and socially encouraged to get your packages there.

Its already socially encouraged: heck, if package foo is not on PyPI, it doesn't exist. As an author who hosts code elsewhere, I really want to get feedback on my packages. I don't really see the point of having a comment system in PyPI ((*for me*), but I would really like to be able to have a link to the appropriate web page for folk that want to ask questions. To be clear, I mean a specific link, not just the 'link to a website'. -Rob

Barry Warsaw wrote:

I personally think a ratings system can be useful, but you should be able to opt-out of it if you want. Or just write such awesome software that the bogus bad reviews will be buried by an avalanche of kudos.

One of the problems I have with online rating/comment systems for software are I see them as inherently biased. Happy users are more likely to be busy coding, unhappy users are more likely to be frustrated and looking for somewhere to vent. If the package author can't even *respond* to mistaken or misguided comments then the review system is fundamentally broken. Better not to have one at all - let people vent on their own blogs and other sites, and let potential users let Google do its thing (and if Google turns up nothing, then that in itself is a data point). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On Thu, Nov 12, 2009 at 8:06 AM, Jesse Noller <jnoller@gmail.com> wrote:

On Thu, Nov 12, 2009 at 8:38 AM, Steven D'Aprano <steve@pearwood.info> wrote:

...

On Thu, 12 Nov 2009 08:44:32 pm Ludvig Ericson wrote:

...

Why are there comments on PyPI? Moreso, why are there comments which I cannot control as a package author on my very own packages? That's just absurd.

No, what's absurd is thinking that the act of publishing software somehow gives you the right to demand control over what others say about your software.

I don't suppose that this rant of yours has something to do with the comment posted today?

Frankly, I agree with him. As implemented, I *and others* think this is broken. I've taken the stance of not publishing things to PyPi until A> I find the time to contribute to make it better or B> It changes.

I'm not sure I see the utility of ratings, but I think comments can be useful as long as they don't carry over from release to release. For instance, suppose there's a bug in my package and someone leaves a comment about it. I don't want that comment still hanging around 3 years after I've already fixed the bug.

On Thu, Nov 12, 2009 at 11:02 AM, David Stanek <dstanek@dstanek.com> wrote:

Where is the code for PyPi? I took a quick look and didn't turn up anything.

https://svn.python.org/packages/trunk/pypi/ I've already started on a patch to make comments an option that package maintainers could turn on or off, but I don't want to waste any more time fighting this code unless I have some assurance it'll be checked in. Jacob

[Jacob Kaplan-Moss]

I've already started on a patch to make comments an option that package maintainers could turn on or off, but I don't want to waste any more time fighting this code unless I have some assurance it'll be checked in.

I support your efforts. Raymond

That's useful from a user perspective. Or is it? It's useful from a user perspective, until that issue is fixed. Then what? Is it still useful? Can the commenter remove it?

Yes.

Can they get notified it's changed?

Yes.

Can the maintainer say "this is fixed/changed?"

Yes.

I never look at the PyPI pages for stuff I create. Which means if someone is using it for support, they're wasting their time. (Why would I look at it? I know what the project is for and where to get it! :) (and also PyPI isn't the prime download for it either - so the download stats are irrelevant to me) I doubt I'm alone, so how many people's time are wasted asking questions there ?

You'll get an email when someone comments, so you don't have to look at the page.

I suppose, personally, I'm dubious about the idea of having unchanging comments and ratings associated with projects which are changing and improving - that feels like a mismatch.

That's why the comments are per-release.

If there's interest, and if there's a survey to be done, I could forward a link to a survey through that twitterfeed - which I suspect is a mix of users of PyPI and uploaders to PyPI.

Feel free to annouce it on Twitter - I don't use that system myself. Regards, Martin

On Thu, Nov 12, 2009 at 5:38 AM, Steven D'Aprano <steve@pearwood.info> wrote:

On Thu, 12 Nov 2009 08:44:32 pm Ludvig Ericson wrote:

...

Why are there comments on PyPI? Moreso, why are there comments which I cannot control as a package author on my very own packages? That's just absurd.

No, what's absurd is thinking that the act of publishing software somehow gives you the right to demand control over what others say about your software.

I don't suppose that this rant of yours has something to do with the comment posted today?

http://pypi.python.org/pypi/spypam/1.0

If you were to ask me, the people arguing against ratings and user comments are fighting a losing battle. If they had an iPhone or Android phone (or some other device with an "app store" kind of place to find downloads) they'd know the value (for prospective downloaders) of ratings and comments. Now, I think PyPI can use some (perhaps a lot of) improvement in the details of how it works, e.g. there should be a way to flag inappropriate messages (and users who post many inappropriate messages) and the software author should be able to talk back, but the general idea is here and won't go away by wishing it away. -- --Guido van Rossum (python.org/~guido)

On Thu, Nov 12, 2009 at 10:19 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:

(more seriously, the problem with a comment system is that once it takes off, you need a whole array of functionalities to maintain a good S/N ratio. Just allowing people to "comment" without any sort of moderation, filtering or community building doesn't work)

Why not allow ratings on comments as well?

On Thu, Nov 12, 2009 at 5:46 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:

...

(more seriously, the problem with a comment system is that once it takes off, you need a whole array of functionalities to maintain a good S/N ratio. Just allowing people to "comment" without any sort of moderation, filtering or community building doesn't work)

The current rate is roughly 1 comment per day (with peaks of 5 comments), so it takes of rather slowly.

Until spammers decide to attack... -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

On Thu, Nov 12, 2009 at 11:02 AM, Guido van Rossum <guido@python.org> wrote:

If you were to ask me, the people arguing against ratings and user comments are fighting a losing battle. If they had an iPhone or Android phone (or some other device with an "app store" kind of place to find downloads) they'd know the value (for prospective downloaders) of ratings and comments. Now, I think PyPI can use some (perhaps a lot of) improvement in the details of how it works, e.g. there should be a way to flag inappropriate messages (and users who post many inappropriate messages) and the software author should be able to talk back, but the general idea is here and won't go away by wishing it away.

-- --Guido van Rossum (python.org/~guido)

I don't want us to impersonate the mindless, sub-useful drivel found in App store/YouTube/etc comments 99% of the time or the broken "5 star ratings" systems, etc. It's too easy to game. I'm not arguing something like this *shouldn't* exist; but that the current implementation is a far cry from something actually *good and useful*. If we want forums, let's put in forums. If we want a real review system, then do that. But before we even did those; why not have mandatory links for entries to bug trackers, mailing lists, source repositories, etc? I'm saying saying this doesn't seem well thought out, and the current implementation is broken by design. Of course, as I said earlier; since I don't have time to patch it; I'll simply just not participate. jesse

Masklinn <masklinn@masklinn.net> writes:

...

But before we even did those; why not have mandatory links for entries to bug trackers, mailing lists, source repositories, etc? I'm saying saying this doesn't seem well thought out, and the current implementation is broken by design. Of course, as I said earlier; since I don't have time to patch it; I'll simply just not participate. I think having links to those is a very good idea and more important

On 12 Nov 2009, at 17:31 , Jesse Noller wrote: than a comment/notation system. They shouldn't be mandatory though, not every library has a mailing list, or even a (public anyway) bug tracker.

I think Jesse's point (or, if he's not willing to claim it, my point) is that, compared to the mandatory comment system, it makes much *more* sense to have a mandatory field for “URL to the BTS for this project”. At least it can be expected that in many cases project maintainers will *want* to use a conventional BTS, VCS, discussion forum, etc. So that route makes more sense than a mandatory comment system outside the project maintainer's control, while providing the user-participation that is the purported motivation. -- \ “Spam will be a thing of the past in two years' time.” —Bill | `\ Gates, 2004-01-24 | _o__) | Ben Finney

On 12 Nov 2009, at 22:53 , James Y Knight wrote:

On Nov 12, 2009, at 4:11 PM, Ben Finney wrote:

...

I think Jesse's point (or, if he's not willing to claim it, my point) is that, compared to the mandatory comment system, it makes much *more* sense to have a mandatory field for “URL to the BTS for this project”.

One might look at the "competition" for inspiration. Looking at CPAN. There's no "comments" feature There is, on search.cpan.org. See http://search.cpan.org/~petdance/ack/ for instance, the link leads to http://cpanratings.perl.org/ (a pretty interesting example of the "distributed" nature of cpan in fact).

On 12 Nov 2009, at 23:44 , James Y Knight wrote:

On Nov 12, 2009, at 5:23 PM, Masklinn wrote:

...

On 12 Nov 2009, at 22:53 , James Y Knight wrote:

...

On Nov 12, 2009, at 4:11 PM, Ben Finney wrote:

...

I think Jesse's point (or, if he's not willing to claim it, my point) is that, compared to the mandatory comment system, it makes much *more* sense to have a mandatory field for “URL to the BTS for this project”.

One might look at the "competition" for inspiration. Looking at CPAN. There's no "comments" feature There is, on search.cpan.org. See http://search.cpan.org/~petdance/ack/ for instance, the link leads to http://cpanratings.perl.org/ (a pretty interesting example of the "distributed" nature of cpan in fact).

Ah, I see. I totally managed to miss that...I guess that's an interesting example of a bad web ui. :) I'm not sure it's so bad, it's just that it's at the root of the "cpan package" rather than in the POD (just click on "BDB-mysql" in the breadcrumb trail, landing at http://search.cpan.org/~capttofu/DBD-mysql/).

Interestingly, the link to cpanratings from BDB-mysql is broken and yields a 404, even though its CPAN page lists 5 reviews and a score of ~3.5.

Martin v. Löwis <martin <at> v.loewis.de> writes:

I think you are missing the point of the commenting system: these comments are *not* directed towards the package author. Instead, they are directed towards fellow users of the package. For this kind of message, a bugtracker is completely inappropriate, as is a mailing list, or any other kind of support forum.

Then why not simply add a sentence or two before the comment form warning that the comment system is not meant to ask for help, support or debugging about the package? Regards Antoine.

Masklinn <masklinn <at> masklinn.net> writes:

On 13 Nov 2009, at 00:00 , Antoine Pitrou wrote:

...

Then why not simply add a sentence or two before the comment form warning

...

the comment system is not meant to ask for help, support or debugging about

that the

...

package? Because users don't read warnings.

I don't like assuming users are idiots.

The warning will therefore be promptly ignored, and then the aforementioned user will start ripping on the package because he didn't get help following his comment.

And then it's easy to point out that he was wrong if there was a warning in the first place.

On 13 Nov 2009, at 00:15 , Antoine Pitrou wrote:

Masklinn <masklinn <at> masklinn.net> writes:

...

On 13 Nov 2009, at 00:00 , Antoine Pitrou wrote:

...

Then why not simply add a sentence or two before the comment form warning

...

...

the comment system is not meant to ask for help, support or debugging about

that the

...

...

package? Because users don't read warnings. I don't like assuming users are idiots. You don't have to. It's about expediency and care (or lack thereof) rather than idiocy. User(*) wants a solution, user finds place where he could ask, user asks.

Users (which includes e.g. language users) tend to be lazy, rather than stupid.

...

The warning will therefore be promptly ignored, and then the aforementioned user will start ripping on the package because he didn't get help following his comment. And then it's easy to point out that he was wrong if there was a warning in the first place. And then user will probably ask why you're not answering the question since you're here anyway, or might go as far as telling you that if you're not going to help you might as well not answer.

*: not every user, but I believe a significant minority at least.

On 13 Nov 2009, at 00:35 , Antoine Pitrou wrote:

Masklinn <masklinn <at> masklinn.net> writes:

...

And then user will probably ask why you're not answering the question since you're here anyway, or might go as far as telling you that if you're not going to help you might as well not answer.

As I said, you are regarding the user as an idiot or as a troll. I don't think so, but we might disagree on either definition, or both.

On 13 Nov 2009, at 00:37 , 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. Fair point

On Thu, Nov 12, 2009 at 4:00 PM, Ben Finney <ben+python@benfinney.id.au> wrote:

I've found it useful to realise that, from the perspective of a program/website/feedback form, etc., the user has a tiny brain: [...]

Actually it's the other way around. It's the program that has the tiny brain. :-) -- --Guido van Rossum (python.org/~guido)

Antoine Pitrou wrote:

Martin v. Löwis <martin <at> v.loewis.de> writes:

...

I think you are missing the point of the commenting system: these comments are *not* directed towards the package author. Instead, they are directed towards fellow users of the package. For this kind of message, a bugtracker is completely inappropriate, as is a mailing list, or any other kind of support forum.

Then why not simply add a sentence or two before the comment form warning that the comment system is not meant to ask for help, support or debugging about the package?

Done! Martin

If you were to ask me, the people arguing against ratings and user comments are fighting a losing battle. If they had an iPhone or Android phone (or some other device with an "app store" kind of place to find downloads) they'd know the value (for prospective downloaders) of ratings and comments. Now, I think PyPI can use some (perhaps a lot of) improvement in the details of how it works, e.g. there should be a way to flag inappropriate messages (and users who post many inappropriate messages)

There is, although it's admittedly tedious: users can file a support request (follow the link "Get Help").

and the software author should be able to talk back

That is actually the case: the author *can* talk back.

but the general idea is here and won't go away by wishing it away.

I'm going to take a poll RSN, and see what the majority of users think (rather than their vocal fraction). Then we can see what to do about it. Regards, Martin

Martin v. Löwis wrote:

I'm going to take a poll RSN, and see what the majority of users think (rather than their vocal fraction). Then we can see what to do about it.

Yes please! I've been silently waiting for this and have (surprisingly for me!) managed to resist joining in the rant. I'm of the crowd who just wants to make comments (I don't care about ratings one way or another, and I can't, sadly, see anyone giving me access as to who-voted-less-than-5 so I can follow up with them and see what needs to be improved) optional. I'm quite okay with having a banner saying "This package has opted not to receive comments". I believe the software I release on PyPI is strong enough on its own merits that people will use it ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

Nick Coghlan wrote:

Chris Withers wrote:

...

I'm quite okay with having a banner saying "This package has opted not to receive comments".

Particularly if the developer is able to add a prominent link to the project's own support site or mailing list.

It's really puzzling that people always assume that people would use comments primarily to get help, or to report problems. It appears that nobody expects users to merely comment, voicing their opinion - yet the comment that triggered this particular thread was precisely that. Regards, Martin

Ben Finney wrote:

"Martin v. Löwis" <martin@v.loewis.de> writes:

...

...

Particularly if the developer is able to add a prominent link to the project's own support site or mailing list. It's really puzzling that people always assume that people would use comments primarily to get help, or to report problems. It appears that nobody expects users to merely comment, voicing their opinion - yet

Nick Coghlan wrote: the comment that triggered this particular thread was precisely that.

I'm reading “the project's own mailing list” as a fine place to do exactly that: discuss the project.

No no no: discuss with whom? The commenter may not want to discuss anything about the project, let alone with the package author. If it's a positive comment, you may likely only get "me too", anyway; if it's a negative comment, perhaps the commenter has already given up on the package, and just wants to warn other users. It's those other users that then will have problems finding reviews on the mailing list. Regards, Martin

Nobody is claiming right to censor what people say about their software. This is the Internet. There are blogs. Google and other search engines find blogs quickly, and people who agree with the viewpoints expressed link to them thus making the blog postings more visible. There are countless other social networks and outlets for people to flame and slander (or praise and promote, in a much less common case) software. It would be more useful to provide a PyPI mechanism to publish a link to file bugs on the project's own website and leave project ratings the work of other sites such as Ohloh. On Thu, Nov 12, 2009 at 8:38 AM, Steven D'Aprano <steve@pearwood.info>wrote:

No, what's absurd is thinking that the act of publishing software somehow gives you the right to demand control over what others say about your software.