From chris at simplistix.co.uk Tue Sep 8 20:34:34 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 08 Sep 2009 19:34:34 +0100
Subject: [Catalog-sig] How to delete docs uploaded to PyPI
Message-ID: <4AA6A3BA.8030606@simplistix.co.uk>
Hi All,
If I upload docs to http://packages.python.org/<somepackage> and decide
later on down the line that I don't want them anymore, can I delete them?
If so, how?
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
From jcea at jcea.es Tue Sep 8 23:36:17 2009
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 08 Sep 2009 23:36:17 +0200
Subject: [Catalog-sig] OpenID on PyPI
In-Reply-To: <4A9B3E00.1020402@v.loewis.de>
References: <4A9B3E00.1020402@v.loewis.de>
Message-ID: <4AA6CE51.6070907@jcea.es>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin v. L?wis wrote:
> PyPI users can now login with OpenID. For existing accounts, you can
> associate (claim) an OpenID on Your details page; new users can create
> an account by just trying to login.
/me very very happy.
- --
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/
iQCVAwUBSqbOUZlgi5GaxT1NAQIgCQQAhYmTm6lYXaEmzNJ5zz9c4wM5qOYGM2vl
5WvVdFmD4za00xogGLJgtLMfGAt9kmFdlO/Vg1lXiQM1exocOJ+UYWvQARMtcK77
Wcqs7vK57tG8qIt6XiG2Qq8b8c/bh8ndjIGgRzcWaUBZL8BzwMg2i0w8h9XYVDle
YvhCUU+6Qic=
=k1bR
-----END PGP SIGNATURE-----
From jcea at jcea.es Tue Sep 8 23:40:12 2009
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 08 Sep 2009 23:40:12 +0200
Subject: [Catalog-sig] OpenID on PyPI
In-Reply-To: <4A9B3E00.1020402@v.loewis.de>
References: <4A9B3E00.1020402@v.loewis.de>
Message-ID: <4AA6CF3C.7000001@jcea.es>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin v. L?wis wrote:
> PyPI users can now login with OpenID. For existing accounts, you can
> associate (claim) an OpenID on Your details page; new users can create
> an account by just trying to login.
Uhmmm.... I have my own OpenID provider. I only see OpenID support for
Google, MyOpenID and Launchpad.
I would suggest to add the possibility allowing a user to provide an
OpenID URL.
- --
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/
iQCVAwUBSqbPPJlgi5GaxT1NAQKmJQP+J4Ul/DTyKZw1lQ0VCXwwjBu5h3+DWB/P
3gyFxVEwgCKTgkH9k0QHHR7G1iagHz3YD7uAvt0JlSzLedeNk7UkJAhvGyhW6PJE
0w3E9smJs5rChQOl69HsucFtJAmccgaGuXc+pdy28pMUpZHTug7F4tThTzcD122O
iZAvDKpJteA=
=9VuS
-----END PGP SIGNATURE-----
From ianb at colorstudy.com Wed Sep 9 02:04:24 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 8 Sep 2009 19:04:24 -0500
Subject: [Catalog-sig] Tweaks to edit screen
Message-ID: <b654cd2e0909081704i74ee12c0ybc69ed7cc0f22aef@mail.gmail.com>
The edit screen (e.g.,
http://pypi.python.org/pypi?:action=submit_form&name=virtualenv&version=1.3.3)
uses wrap="HARD" in textareas, which causes corruption of otherwise OK
ReST (uploaded via setup.py register) by introducing unwanted
newlines. wrap="SOFT" would be better.
Also, it's tricky to updated ==dev links, because links from all
versions are displayed on /simple/<package>, and the last link is
used, which is the oldest link. Just inverting the order of the links
would fix this; or at least inverting the links that are scraped from
the descriptions.
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
From martin at v.loewis.de Wed Sep 9 09:50:33 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 09 Sep 2009 09:50:33 +0200
Subject: [Catalog-sig] How to delete docs uploaded to PyPI
In-Reply-To: <4AA6A3BA.8030606@simplistix.co.uk>
References: <4AA6A3BA.8030606@simplistix.co.uk>
Message-ID: <4AA75E49.4070607@v.loewis.de>
> If I upload docs to http://packages.python.org/<somepackage> and decide
> later on down the line that I don't want them anymore, can I delete them?
>
> If so, how?
Currently, you'll have to file a support request into the tracker.
Regards,
Martin
From chris at simplistix.co.uk Wed Sep 9 09:59:08 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 09 Sep 2009 08:59:08 +0100
Subject: [Catalog-sig] How to delete docs uploaded to PyPI
In-Reply-To: <4AA75E49.4070607@v.loewis.de>
References: <4AA6A3BA.8030606@simplistix.co.uk> <4AA75E49.4070607@v.loewis.de>
Message-ID: <4AA7604C.1080005@simplistix.co.uk>
Martin v. L?wis wrote:
>> If I upload docs to http://packages.python.org/<somepackage> and decide
>> later on down the line that I don't want them anymore, can I delete them?
>>
>> If so, how?
>
> Currently, you'll have to file a support request into the tracker.
Would uploading an empty .zip clear things out?
If not, then aren't you in danger of accumulating a lot of data that
isn't needed and just takes up space?
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
From martin at v.loewis.de Wed Sep 9 12:16:57 2009
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 09 Sep 2009 12:16:57 +0200
Subject: [Catalog-sig] OpenID on PyPI
In-Reply-To: <4AA6CF3C.7000001@jcea.es>
References: <4A9B3E00.1020402@v.loewis.de> <4AA6CF3C.7000001@jcea.es>
Message-ID: <4AA78099.7080403@v.loewis.de>
>> PyPI users can now login with OpenID. For existing accounts, you can
>> associate (claim) an OpenID on Your details page; new users can create
>> an account by just trying to login.
>
> Uhmmm.... I have my own OpenID provider. I only see OpenID support for
> Google, MyOpenID and Launchpad.
>
> I would suggest to add the possibility allowing a user to provide an
> OpenID URL.
I'm opposed. It would require users to enter OpenID URLs, which I don't
want to provide user interface for.
Regards,
Martin
From martin at v.loewis.de Wed Sep 9 12:24:36 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 09 Sep 2009 12:24:36 +0200
Subject: [Catalog-sig] How to delete docs uploaded to PyPI
In-Reply-To: <4AA7604C.1080005@simplistix.co.uk>
References: <4AA6A3BA.8030606@simplistix.co.uk> <4AA75E49.4070607@v.loewis.de>
<4AA7604C.1080005@simplistix.co.uk>
Message-ID: <4AA78264.7080809@v.loewis.de>
>> Currently, you'll have to file a support request into the tracker.
>
> Would uploading an empty .zip clear things out?
Yes, that should work. It will leave an empty top-level directory.
> If not, then aren't you in danger of accumulating a lot of data that
> isn't needed and just takes up space?
I don't see that as a danger. I hope that disk space will grow faster
than user demand.
If you see it as a problem, please contribute a patch. Notice that there
is an open bug report for that already.
Regards,
Martin
From martin at v.loewis.de Thu Sep 10 17:00:03 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 10 Sep 2009 17:00:03 +0200
Subject: [Catalog-sig] Tweaks to edit screen
In-Reply-To: <b654cd2e0909081704i74ee12c0ybc69ed7cc0f22aef@mail.gmail.com>
References: <b654cd2e0909081704i74ee12c0ybc69ed7cc0f22aef@mail.gmail.com>
Message-ID: <4AA91473.4010604@v.loewis.de>
> The edit screen (e.g.,
> http://pypi.python.org/pypi?:action=submit_form&name=virtualenv&version=1.3.3)
> uses wrap="HARD" in textareas, which causes corruption of otherwise OK
> ReST (uploaded via setup.py register) by introducing unwanted
> newlines. wrap="SOFT" would be better.
Would that have any negative consequences, e.g. when the text being
entered is not ReST?
> Also, it's tricky to updated ==dev links, because links from all
> versions are displayed on /simple/<package>, and the last link is
> used, which is the oldest link. Just inverting the order of the links
> would fix this; or at least inverting the links that are scraped from
> the descriptions.
I don't understand that request. Can you please provide a reference to
a package where things are not as they should be, and indicate how they
should be?
Notice that, in r598, I was asked specifically to change the order to
put file urls before the homepage url. So I'm hesitant to change
anything without an independent confirmation that this would be a good
change.
Regards,
Martin
From jcea at jcea.es Thu Sep 10 18:15:27 2009
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 10 Sep 2009 18:15:27 +0200
Subject: [Catalog-sig] OpenID on PyPI
In-Reply-To: <4AA78099.7080403@v.loewis.de>
References: <4A9B3E00.1020402@v.loewis.de> <4AA6CF3C.7000001@jcea.es>
<4AA78099.7080403@v.loewis.de>
Message-ID: <4AA9261F.8080307@jcea.es>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin v. L?wis wrote:
>> I would suggest to add the possibility allowing a user to provide an
>> OpenID URL.
>
> I'm opposed. It would require users to enter OpenID URLs, which I don't
> want to provide user interface for.
Then the OpenID support is very compromised. The point of OpenID is not
to depend of a centralized service. That is the reason I have my own
OpenID provider.
- --
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/
iQCVAwUBSqkmH5lgi5GaxT1NAQK9NgP/Wrir1CAi0D3W4iDs0EfpQwIMMoMmYOOl
KrE1unMup01v3gdttHvT4nF8+zLtLNWUhnHVKzAX1t55+HNf98iSoVdR+PJZEEJq
YxOBNw2WWTnF0uwIB90ZFezkrKk3Kl8jJjDLheIT5JpRX8uYt2rGSkliWijUiSFT
sdTBzFyRloc=
=t5rg
-----END PGP SIGNATURE-----
From martin at v.loewis.de Thu Sep 10 18:46:18 2009
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 10 Sep 2009 18:46:18 +0200
Subject: [Catalog-sig] OpenID on PyPI
In-Reply-To: <4AA9261F.8080307@jcea.es>
References: <4A9B3E00.1020402@v.loewis.de>
<4AA6CF3C.7000001@jcea.es> <4AA78099.7080403@v.loewis.de>
<4AA9261F.8080307@jcea.es>
Message-ID: <4AA92D5A.5000501@v.loewis.de>
> Then the OpenID support is very compromised.
That may well be the case.
> The point of OpenID is not
> to depend of a centralized service. That is the reason I have my own
> OpenID provider.
If that's the idea, then I think OpenID is severely flawed.
However, I disagree that this is the idea. Instead, the idea is
to have an open protocol, to allow for competition between providers.
Your provider will have to compete with the other providers to be
acceptable for PyPI, according to the criteria posted at
http://pypi.python.org/pypi?:action=openid
If it meets these criteria, I can happily add support for it. If not,
either strive for it to meet the requirements, switch to a provider that
does meet the requirements, or don't use it with PyPI (and likely, not
with the bug tracker and MoinMoin, when I implement that).
Regards,
Martin
From noah at coderanger.net Thu Sep 10 18:57:38 2009
From: noah at coderanger.net (Noah Kantrowitz)
Date: Thu, 10 Sep 2009 09:57:38 -0700
Subject: [Catalog-sig] OpenID on PyPI
In-Reply-To: <4AA92D5A.5000501@v.loewis.de>
References: <4A9B3E00.1020402@v.loewis.de> <4AA6CF3C.7000001@jcea.es> <4AA78099.7080403@v.loewis.de> <4AA9261F.8080307@jcea.es>
<4AA92D5A.5000501@v.loewis.de>
Message-ID: <014601ca3237$ce631330$6b293990$@net>
> -----Original Message-----
> From: catalog-sig-bounces+noah=coderanger.net at python.org
> [mailto:catalog-sig-bounces+noah=coderanger.net at python.org] On Behalf
> Of "Martin v. L?wis"
> Sent: Thursday, September 10, 2009 9:46 AM
> To: Jesus Cea
> Cc: catalog-sig
> Subject: Re: [Catalog-sig] OpenID on PyPI
>
>
> > Then the OpenID support is very compromised.
>
> That may well be the case.
>
> > The point of OpenID is not
> > to depend of a centralized service. That is the reason I have my own
> > OpenID provider.
>
> If that's the idea, then I think OpenID is severely flawed.
>
> However, I disagree that this is the idea. Instead, the idea is
> to have an open protocol, to allow for competition between providers.
>From http://openid.net/specs/openid-authentication-2_0.html:
"OpenID is decentralized. No central authority must approve or register
Relying Parties or OpenID Providers. An end user can freely choose which
OpenID Provider to use, and can preserve their Identifier if they switch
OpenID Providers."
Sounds pretty clear to me.
--Noah
From jcea at jcea.es Thu Sep 10 19:16:50 2009
From: jcea at jcea.es (Jesus Cea)
Date: Thu, 10 Sep 2009 19:16:50 +0200
Subject: [Catalog-sig] OpenID on PyPI
In-Reply-To: <4AA92D5A.5000501@v.loewis.de>
References: <4A9B3E00.1020402@v.loewis.de> <4AA6CF3C.7000001@jcea.es> <4AA78099.7080403@v.loewis.de> <4AA9261F.8080307@jcea.es>
<4AA92D5A.5000501@v.loewis.de>
Message-ID: <4AA93482.5040205@jcea.es>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin v. L?wis wrote:
>> The point of OpenID is not
>> to depend of a centralized service. That is the reason I have my own
>> OpenID provider.
>
> If that's the idea, then I think OpenID is severely flawed.
The point of OpenID is something like this:
* Create an account in your system.
* Link that account to an unforgeable, easy to use, "token".
* Everytime somebody can prove "token" ownership, the user is logged in.
The OpenID is the "token". If I link my account to an OpenID and only
*ME* can prove "ownership" of it when I try to login, then I can prove
my identity to your system.
In this aspect you don't need a "well known" OpenID provider. If fact,
depending of a "well known" OpenID provider is a risk if: that provider
goes down (let's say Gmail last week :-) ), it is hacked, it goes out of
business, or the OpenID admins are not to be trusted.
> Your provider will have to compete with the other providers to be
> acceptable for PyPI, according to the criteria posted at
>
> http://pypi.python.org/pypi?:action=openid
Of course you can require whatever you want, but I don't really see the
point. I could comply with all the requirements except the first: "must
be in wide use, using procedures that the community trusts".
If you don't require me to use a Gmail email address, for instance, I
don't see why you require I use a "widely used" OpenID provider. It is
the very same thing.
- --
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/
iQCVAwUBSqk0e5lgi5GaxT1NAQLwFwQAjwqwG0ENzzMZ1wF5gOZjR1CEXhyTxJcU
29rNiNIIgqO7Eu0IDDyVIPECR2v+bsLk7zBT4DO0IF2PdxSBGRBFfvnJ2GvyCJUD
a0u+fi5fYaMDfT/9FGkf6bSe/6MFCZluZZbsZJIP2xlvFWQCxSRM45BLM3strP9h
RXnOyvKurbI=
=Z6jw
-----END PGP SIGNATURE-----
From martin at v.loewis.de Fri Sep 11 09:12:05 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 11 Sep 2009 09:12:05 +0200
Subject: [Catalog-sig] OpenID on PyPI
In-Reply-To: <014601ca3237$ce631330$6b293990$@net>
References: <4A9B3E00.1020402@v.loewis.de> <4AA6CF3C.7000001@jcea.es> <4AA78099.7080403@v.loewis.de> <4AA9261F.8080307@jcea.es>
<4AA92D5A.5000501@v.loewis.de>
<014601ca3237$ce631330$6b293990$@net>
Message-ID: <4AA9F845.9020309@v.loewis.de>
>> However, I disagree that this is the idea. Instead, the idea is
>> to have an open protocol, to allow for competition between providers.
>
>>From http://openid.net/specs/openid-authentication-2_0.html:
>
> "OpenID is decentralized. No central authority must approve or register
> Relying Parties or OpenID Providers. An end user can freely choose which
> OpenID Provider to use, and can preserve their Identifier if they switch
> OpenID Providers."
>
> Sounds pretty clear to me.
To me as well. There is no need for a central authority to approve
providers - but for me, as a relying party, I certainly have the freedom
to rely on some providers, but not on others (not being a central
authority myself, in the OpenID world). Unfortunately, the OpenID
publicity always focuses on the freedom of end users, but not on the
freedom of relying parties.
Regards,
Martin
From martin at v.loewis.de Fri Sep 11 09:24:02 2009
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 11 Sep 2009 09:24:02 +0200
Subject: [Catalog-sig] OpenID on PyPI
In-Reply-To: <4AA93482.5040205@jcea.es>
References: <4A9B3E00.1020402@v.loewis.de> <4AA6CF3C.7000001@jcea.es> <4AA78099.7080403@v.loewis.de> <4AA9261F.8080307@jcea.es> <4AA92D5A.5000501@v.loewis.de>
<4AA93482.5040205@jcea.es>
Message-ID: <4AA9FB12.8000206@v.loewis.de>
> The point of OpenID is something like this:
>
> * Create an account in your system.
>
> * Link that account to an unforgeable, easy to use, "token".
>
> * Everytime somebody can prove "token" ownership, the user is logged in.
There is one more aspect to it: user registration. As a relying party,
I want to eliminate/reduce the effort of account management. As such,
the provider needs to provide me with an email address, and (ideally)
a real name.
> The OpenID is the "token". If I link my account to an OpenID and only
> *ME* can prove "ownership" of it when I try to login, then I can prove
> my identity to your system.
No, they can't (see below).
> In this aspect you don't need a "well known" OpenID provider.
I sure do. I have to trust that your local OpenID provider
creates unforgeable tokens. I don't trust that it does.
> If fact,
> depending of a "well known" OpenID provider is a risk if: that provider
> goes down (let's say Gmail last week :-) ), it is hacked, it goes out of
> business, or the OpenID admins are not to be trusted.
Right - that may happen. Therefore, I (as a relying party) have to
really trust the providers I rely on (as have my users). It's
called *relying* party for a reason.
> If you don't require me to use a Gmail email address, for instance, I
> don't see why you require I use a "widely used" OpenID provider. It is
> the very same thing.
No, it's not. Not only the users need to trust the provider, but also
(and more so) the relying party. Many relying parties don't care about
that trust (which is their choice), but I do.
Regards,
Martin
From martin at v.loewis.de Fri Sep 11 10:39:46 2009
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 11 Sep 2009 10:39:46 +0200
Subject: [Catalog-sig] Documentation upload on PyPI
Message-ID: <4AAA0CD2.8000706@v.loewis.de>
Somebody reminded me at the DZUG meeting that documentation
upload was still declared experimental. Since it seems to work
fine (except for the removal at package deletion time), I can
now declare it as an official permanent PyPI service.
Regards,
Martin
From renesd at gmail.com Fri Sep 11 10:47:28 2009
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Fri, 11 Sep 2009 09:47:28 +0100
Subject: [Catalog-sig] OpenID on PyPI
In-Reply-To: <4AA9FB12.8000206@v.loewis.de>
References: <4A9B3E00.1020402@v.loewis.de> <4AA6CF3C.7000001@jcea.es>
<4AA78099.7080403@v.loewis.de> <4AA9261F.8080307@jcea.es>
<4AA92D5A.5000501@v.loewis.de> <4AA93482.5040205@jcea.es>
<4AA9FB12.8000206@v.loewis.de>
Message-ID: <64ddb72c0909110147r528a65aao75bfb27a20a4e24c@mail.gmail.com>
Hello,
Why are random email providers trusted? In many systems large email
providers are not trusted.
Large email providers like google, and hotmail are the ones not
trusted. The reason being that you can more easily anonymously get
fake, or hacked gmail/hotmail accounts. Yet here we have the opposite
situation happening - with the large providers trusted, and the
smaller ones not trusted.
Just a funny observation. Cheese shop logic.
From ziade.tarek at gmail.com Fri Sep 11 15:13:29 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 15:13:29 +0200
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
Message-ID: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
Hello
Right now in a package registered at pypi, there are no distinction
between urls located in free text metadata (like description)
and metadata that are supposed to be urls.
This leads to some problems when scripts like easy_install scans the index page:
it might try to visit urls the author just put there in his
description text with no particular
intent of making it viewable.
Plus, old urls that don't work anymore are not removed, leading to
easy_install timeouts.
1. what's the purpose of having them in there ?
2. if there's a purpose, what about adding an attribute to each <a>
tag to identify from which metadata field it was extracted from ?
Cheers
Tarek
--
Tarek Ziad? | http://ziade.org |???????????
From martin at v.loewis.de Fri Sep 11 15:28:53 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 11 Sep 2009 15:28:53 +0200
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
Message-ID: <4AAA5095.8050906@v.loewis.de>
> Right now in a package registered at pypi, there are no distinction
> between urls located in free text metadata (like description)
> and metadata that are supposed to be urls.
I presume you are talking about the simple API?
Otherwise, I cannot understand your question: in the database, and in
the metadata, there is clearly such distinction, also accessible to any
clients who care to use it.
> Plus, old urls that don't work anymore are not removed, leading to
> easy_install timeouts.
>
> 1. what's the purpose of having them in there ?
Again, I presume you are talking about the simple API?
That's for compatibility with setuptools. When setuptools was parsing
the original pages, it would follow all URLs. In order to preserve
full compatibility in the simple pages, all URLs had to be extracted;
this was the specification given by Jim Fulton.
> 2. if there's a purpose, what about adding an attribute to each <a>
> tag to identify from which metadata field it was extracted from ?
Just make a specification. Notice that some links *already* have
a rel attribute which might be interesting to consider.
Regards,
Martin
From pje at telecommunity.com Fri Sep 11 15:32:59 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 11 Sep 2009 09:32:59 -0400
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.co
m>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
Message-ID: <20090911133300.996CC3A403D@sparrow.telecommunity.com>
At 03:13 PM 9/11/2009 +0200, Tarek Ziad? wrote:
>This leads to some problems when scripts like easy_install scans the
>index page: it might try to visit urls the author just put there in
>his description text with no particular intent of making it viewable.
Easy_install only visits pages marked as "home page" links or "download" links.
> Plus, old urls that don't work anymore are not removed, leading to
> easy_install timeouts. 1. what's the purpose of having them in there ?
To allow easy_install to find "dev" links and other identifiable
direct-download links.
>2. if there's a purpose, what about adding an attribute to each <a>
>tag to identify from which metadata field it was extracted from ?
The attribute already exists: rel="download" and rel="homepage"; if
there's no 'rel' it's from the description.
I'm rather surprised you don't know these things already, since
they're all rather prominently documented as part of easy_install's
"index API" here:
http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api
From pje at telecommunity.com Fri Sep 11 15:38:29 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 11 Sep 2009 09:38:29 -0400
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <4AAA5095.8050906@v.loewis.de>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<4AAA5095.8050906@v.loewis.de>
Message-ID: <20090911133829.CD93D3A403D@sparrow.telecommunity.com>
At 03:28 PM 9/11/2009 +0200, Martin v. L??wis wrote:
>That's for compatibility with setuptools. When setuptools was parsing
>the original pages, it would follow all URLs.
This is not true; setuptools has never followed all URLs. It merely
*parses* all URLs, in order to discover identifiable download links
(i.e. links to archive files, executables, SVN checkouts, etc.)
It only follows explicit "home page" and "download" links, to do the
same scanning for potential links. (In other words, for any given
package, no more than three pages are scanned: the PyPI index page,
the homepage, and the download URL, with the latter two only being
read if they are present and aren't discoverable download links themselves.)
The complete API specification is here, including notes on what was
done in earlier versions:
http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api
From chris at simplistix.co.uk Fri Sep 11 16:11:58 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 11 Sep 2009 15:11:58 +0100
Subject: [Catalog-sig] Documentation upload on PyPI
In-Reply-To: <4AAA0CD2.8000706@v.loewis.de>
References: <4AAA0CD2.8000706@v.loewis.de>
Message-ID: <4AAA5AAE.3080406@simplistix.co.uk>
Martin v. L?wis wrote:
> Somebody reminded me at the DZUG meeting that documentation
> upload was still declared experimental. Since it seems to work
> fine (except for the removal at package deletion time), I can
> now declare it as an official permanent PyPI service.
Any chance you could update the text in the UI to say that? ;-)
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
From ziade.tarek at gmail.com Fri Sep 11 15:50:13 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 15:50:13 +0200
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <20090911133300.996CC3A403D@sparrow.telecommunity.com>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<20090911133300.996CC3A403D@sparrow.telecommunity.com>
Message-ID: <94bdd2610909110650m57453143n44183732bd8bea14@mail.gmail.com>
2009/9/11 P.J. Eby <pje at telecommunity.com>:
>
> The attribute already exists: rel="download" and rel="homepage"; if there's
> no 'rel' it's from the description.
>
> I'm rather surprised you don't know these things already, since they're all
> rather prominently documented as part of easy_install's "index API" here:
>
> ? http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api
Because that's setuptools documentation, not PyPI's.
Let's move this small section to docs.python.org if PyPI implements
it. (or a variation if Jim's specification differs)
I propose to add a PyPI documentation page in distutils docs,
containing this specification,
unless Martin thinks it should be located somewhere else.
From ziade.tarek at gmail.com Fri Sep 11 15:39:40 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 15:39:40 +0200
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <4AAA5095.8050906@v.loewis.de>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<4AAA5095.8050906@v.loewis.de>
Message-ID: <94bdd2610909110639y5b8163f8g2c02c822eadf512f@mail.gmail.com>
2009/9/11 "Martin v. L?wis" <martin at v.loewis.de>:
>> Right now in a package registered at pypi, there are no distinction
>> between urls located in free text metadata (like description)
>> and metadata that are supposed to be urls.
>
> I presume you are talking about the simple API?
yes,
> Just make a specification. Notice that some links *already* have
> a rel attribute which might be interesting to consider.
OK.
Any idea how we coud handle the dead links ?
Regards
Tarek
From renesd at gmail.com Fri Sep 11 16:57:07 2009
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Fri, 11 Sep 2009 15:57:07 +0100
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <94bdd2610909110650m57453143n44183732bd8bea14@mail.gmail.com>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<20090911133300.996CC3A403D@sparrow.telecommunity.com>
<94bdd2610909110650m57453143n44183732bd8bea14@mail.gmail.com>
Message-ID: <64ddb72c0909110757h7e0c7b28n2be1c870aad6c25f@mail.gmail.com>
hi,
I think the use of pgp is missing from that description.
- using the pgp signatures to verify files. This is already part of
pypi... just not used by applications for verification... (I think?)
Also, maybe md5 should be replaced with sha2 use?
- md5 was broken as a useful hash for file integrity in 2004. See
http://en.wikipedia.org/wiki/MD5 for details. SHA2 is the current
replacement... but is aimed to be replaced itself. So pgp signatures
are a better alternative. md5 is still better than nothing of course
:) Just that using sha2 and signed files is better.
cheers,
On Fri, Sep 11, 2009 at 2:50 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> 2009/9/11 P.J. Eby <pje at telecommunity.com>:
>>
>> The attribute already exists: rel="download" and rel="homepage"; if there's
>> no 'rel' it's from the description.
>>
>> I'm rather surprised you don't know these things already, since they're all
>> rather prominently documented as part of easy_install's "index API" here:
>>
>> ? http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api
>
> Because that's setuptools documentation, not PyPI's.
>
> Let's move this small section to docs.python.org if PyPI implements
> it. (or a variation if Jim's specification differs)
>
> I propose to add a PyPI documentation page in distutils docs,
> containing this specification,
> unless Martin thinks it should be located somewhere else.
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
From pje at telecommunity.com Fri Sep 11 23:21:08 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 11 Sep 2009 17:21:08 -0400
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <94bdd2610909110650m57453143n44183732bd8bea14@mail.gmail.co
m>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<20090911133300.996CC3A403D@sparrow.telecommunity.com>
<94bdd2610909110650m57453143n44183732bd8bea14@mail.gmail.com>
Message-ID: <20090911212104.D578E3A403D@sparrow.telecommunity.com>
At 03:50 PM 9/11/2009 +0200, Tarek Ziad? wrote:
>2009/9/11 P.J. Eby <pje at telecommunity.com>:
> >
> > The attribute already exists: rel="download" and rel="homepage"; if there's
> > no 'rel' it's from the description.
> >
> > I'm rather surprised you don't know these things already, since they're all
> > rather prominently documented as part of easy_install's "index API" here:
> >
> > http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api
>
>Because that's setuptools documentation, not PyPI's.
Which is why I was (and am still) surprised you haven't read it.
From ziade.tarek at gmail.com Fri Sep 11 23:47:30 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 23:47:30 +0200
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <20090911212104.D578E3A403D@sparrow.telecommunity.com>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<20090911133300.996CC3A403D@sparrow.telecommunity.com>
<94bdd2610909110650m57453143n44183732bd8bea14@mail.gmail.com>
<20090911212104.D578E3A403D@sparrow.telecommunity.com>
Message-ID: <94bdd2610909111447n3c737b65nee300377eb36266@mail.gmail.com>
On Fri, Sep 11, 2009 at 11:21 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 03:50 PM 9/11/2009 +0200, Tarek Ziad? wrote:
>>
>> 2009/9/11 P.J. Eby <pje at telecommunity.com>:
>> >
>> > The attribute already exists: rel="download" and rel="homepage"; if
>> > there's
>> > no 'rel' it's from the description.
>> >
>> > I'm rather surprised you don't know these things already, since they're
>> > all
>> > rather prominently documented as part of easy_install's "index API"
>> > here:
>> >
>> > ? http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api
>>
>> Because that's setuptools documentation, not PyPI's.
>
> Which is why I was (and am still) surprised you haven't read it.
I don't know who told you I didn't read it. (unless you're making a
joke of course ;) )
That's a "PEAK Developer center" website page that was not
updated for years AFAIK. I have read that page many times, but that
doesn't means that
PyPI still complies exactly like what this page says. (and nothing says so)
PyPI continues to evolve, unlike the Peak developer center (and the
code it documents),
so the only valid source of information about how PyPI works is this
Mailing list and its
current maintainer Martin.
And having it documented in the python.org documentation is, ihmo,
something we need to do, so it can evolve with it.
I hope you're OK if I copy (and add the missing bits) this text
section into distutils
documentation in a PyPI page ?
From pje at telecommunity.com Sat Sep 12 02:43:46 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 11 Sep 2009 20:43:46 -0400
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <94bdd2610909111447n3c737b65nee300377eb36266@mail.gmail.com
>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<20090911133300.996CC3A403D@sparrow.telecommunity.com>
<94bdd2610909110650m57453143n44183732bd8bea14@mail.gmail.com>
<20090911212104.D578E3A403D@sparrow.telecommunity.com>
<94bdd2610909111447n3c737b65nee300377eb36266@mail.gmail.com>
Message-ID: <20090912004340.F07593A403D@sparrow.telecommunity.com>
At 11:47 PM 9/11/2009 +0200, Tarek Ziad? wrote:
>On Fri, Sep 11, 2009 at 11:21 PM, P.J. Eby <pje at telecommunity.com> wrote:
> > At 03:50 PM 9/11/2009 +0200, Tarek Ziad? wrote:
> >>
> >> 2009/9/11 P.J. Eby <pje at telecommunity.com>:
> >> >
> >> > The attribute already exists: rel="download" and rel="homepage"; if
> >> > there's
> >> > no 'rel' it's from the description.
> >> >
> >> > I'm rather surprised you don't know these things already, since they're
> >> > all
> >> > rather prominently documented as part of easy_install's "index API"
> >> > here:
> >> >
> >> > http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api
> >>
> >> Because that's setuptools documentation, not PyPI's.
> >
> > Which is why I was (and am still) surprised you haven't read it.
>
>I don't know who told you I didn't read it. (unless you're making a
>joke of course ;) )
You earlier stated that easy_install "might try to visit urls the
author just put there in his description text". This is not a
statement of someone who has read and understood EasyInstall's documentation.
>That's a "PEAK Developer center" website page that was not
>updated for years AFAIK.
It's also an SVN-controlled text file, EasyInstall.txt, which is
found in the root of both the setuptools trunk and branch - a file
that is automatically updated on the wiki whenever an 0.6 branch
release is cut -- as you would know if you'd read the release.sh
script before it was deleted from your fork of setuptools.
>I have read that page many times, but that
>doesn't means that
>PyPI still complies exactly like what this page says.
My comments have not been about PyPI; they've been about incorrect
statements made regarding the behavior of easy_install. That being
said, you didn't ask Martin whether PyPI still complied with that
API, implying that you were entirely unaware of it.
>(and nothing says so)
That's not actually true, either; see:
http://wiki.python.org/moin/CheeseShopDev
where you will find a link to the PEAK page... and a history that
indicates Martin has at least read the page once or twice. ;-) (At
any rate, he's edited it before.)
>I hope you're OK if I copy (and add the missing bits) this text
>section into distutils
>documentation in a PyPI page ?
I suspect that what you actually want is to document the API provided
by PyPI, rather than the API expected by easy_install, but if it
helps you as a starting point, go for it.
From ziade.tarek at gmail.com Sat Sep 12 03:17:25 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 12 Sep 2009 03:17:25 +0200
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <20090912004340.F07593A403D@sparrow.telecommunity.com>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<20090911133300.996CC3A403D@sparrow.telecommunity.com>
<94bdd2610909110650m57453143n44183732bd8bea14@mail.gmail.com>
<20090911212104.D578E3A403D@sparrow.telecommunity.com>
<94bdd2610909111447n3c737b65nee300377eb36266@mail.gmail.com>
<20090912004340.F07593A403D@sparrow.telecommunity.com>
Message-ID: <94bdd2610909111817h78e1fd26n33a7af7457648900@mail.gmail.com>
On Sat, Sep 12, 2009 at 2:43 AM, P.J. Eby <pje at telecommunity.com> wrote:
>> That's a "PEAK Developer center" website page that was not
>> updated for years AFAIK.
>
> It's also an SVN-controlled text file, EasyInstall.txt, which is found in
> the root of both the setuptools trunk and branch - a file that is
> automatically updated on the wiki whenever an 0.6 branch release is cut --
Ok sorry, not years, 11 months for this particular file (and for the
whole setuptools project)
http://svn.python.org/view/sandbox/branches/setuptools-0.6/EasyInstall.txt?view=log
> as you would know if you'd read the release.sh script before it was deleted
> from your fork of setuptools.
IIRC the first line of this file says : "if your initials are not PJE
don't run it"
http://svn.python.org/view/sandbox/branches/setuptools-0.6/release.sh?view=markup
So I removed it because my initials are T.Z.
Well, our fork is not a one-man-project, so we don't put initials like
that, our release.sh
can be run by anyone that is in the project. It's a community project.
>
>> I have read that page many times, but that
>> doesn't means that
>> PyPI still complies exactly like what this page says.
>
> My comments have not been about PyPI; they've been about incorrect
> statements made regarding the behavior of easy_install. ?That being said,
> you didn't ask Martin whether PyPI still complied with that API, implying
> that you were entirely unaware of it.
Yes, you made a point, I am a bit of a stupid guy, I keep on forgetting things
and I made an incorrect statement here.
But fortunately, you are promptly replying when someone makes
incorrect statements
about this tool, and enlight us.
We can't have you maintaining setuptools, but at least we have your help here.
Thanks Phillip,
>
>
>> (and nothing says so)
>
> That's not actually true, either; see:
>
> ?http://wiki.python.org/moin/CheeseShopDev
>
> where you will find a link to the PEAK page... ?and a history that indicates
> Martin has at least read the page once or twice. ?;-) ?(At any rate, he's
> edited it before.)
>
>
>> I hope you're OK if I copy (and add the missing bits) this text
>> section into distutils
>> documentation in a PyPI page ?
>
> I suspect that what you actually want is to document the API provided by
> PyPI, rather than the API expected by easy_install, but if it helps you as a
> starting point, go for it.
ok then.
thanks for your help
From pje at telecommunity.com Sat Sep 12 03:44:13 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 11 Sep 2009 21:44:13 -0400
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <94bdd2610909111817h78e1fd26n33a7af7457648900@mail.gmail.co
m>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<20090911133300.996CC3A403D@sparrow.telecommunity.com>
<94bdd2610909110650m57453143n44183732bd8bea14@mail.gmail.com>
<20090911212104.D578E3A403D@sparrow.telecommunity.com>
<94bdd2610909111447n3c737b65nee300377eb36266@mail.gmail.com>
<20090912004340.F07593A403D@sparrow.telecommunity.com>
<94bdd2610909111817h78e1fd26n33a7af7457648900@mail.gmail.com>
Message-ID: <20090912014407.9AB3B3A403D@sparrow.telecommunity.com>
At 03:17 AM 9/12/2009 +0200, Tarek Ziad? wrote:
>IIRC the first line of this file says : "if your initials are not PJE
>don't run it"
Yes, but it didn't say not to *read* it. ;-) In effect, it was the
release procedure documentation, it's just that some bits were
dependent on where the procedure was run (i.e., on the machine where
ez_setup.py is distributed from.)
From martin at v.loewis.de Sat Sep 12 15:35:14 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 12 Sep 2009 15:35:14 +0200
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <94bdd2610909110639y5b8163f8g2c02c822eadf512f@mail.gmail.com>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<4AAA5095.8050906@v.loewis.de>
<94bdd2610909110639y5b8163f8g2c02c822eadf512f@mail.gmail.com>
Message-ID: <4AABA392.5030903@v.loewis.de>
>> Just make a specification. Notice that some links *already* have
>> a rel attribute which might be interesting to consider.
>
> OK.
>
> Any idea how we coud handle the dead links ?
IIUC, you don't have to follow them, right? If you want to download
the package, just follow the download links.
Regards,
Martin
From ziade.tarek at gmail.com Sun Sep 13 02:00:16 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 13 Sep 2009 02:00:16 +0200
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <4AABA392.5030903@v.loewis.de>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<4AAA5095.8050906@v.loewis.de>
<94bdd2610909110639y5b8163f8g2c02c822eadf512f@mail.gmail.com>
<4AABA392.5030903@v.loewis.de>
Message-ID: <94bdd2610909121700y17ef34d3yd3fe00bcd8a1777c@mail.gmail.com>
2009/9/12 "Martin v. L?wis" <martin at v.loewis.de>:
>>> Just make a specification. Notice that some links *already* have
>>> a rel attribute which might be interesting to consider.
>>
>> OK.
>>
>> Any idea how we coud handle the dead links ?
>
> IIUC, you don't have to follow them, right? If you want to download
> the package, just follow the download links.
>
easy_install will try to find the "best version" if you don't specify
the version.
So it will visit all the links (among the selected links with the
'rel' attribute, etc..) before
picking the one that it will download.
Just try this one:
$ easy_install hachoir-core
Searching for hachoir-core
Reading http://pypi.python.org/simple/hachoir-core/
Reading http://hachoir.org/wiki/hachoir-core <- this page doesn't
exists anymore that's an old home url
page, you're blocked for a while !!
If we keep this behavior, the client-side should be more smart.
We are adding timeout handling in Distribute, and we will probably add
a special option so it doesn't follow
external links if some distributions were found at PyPI.
But we should find a way to remove dead links from PyPI imho.
Maybe by providing a proxy for all links ? So PyPI can fallback to an
empty page if the link is dead ?
> Regards,
> Martin
>
--
Tarek Ziad? | http://ziade.org |???????????
From adam at therobots.org Sun Sep 13 03:14:00 2009
From: adam at therobots.org (Adam Lowry)
Date: Sat, 12 Sep 2009 18:14:00 -0700
Subject: [Catalog-sig] OpenID on PyPI
Message-ID: <BF82B074-346F-4AEE-89D6-E5B01DD3EDED@therobots.org>
I was pointed to this thread by some people on our local user group,
and since I've done some OpenID implementation work in the past (on
the RP and OP side), they asked me to chime in.
The criteria for inclusion into the whitelist posted is:
> must be in wide use, using procedures that the community trusts
> must support OpenID 2.0
> must support provider-driven identifier selection
> must provide a validated email address, either through AX or SREG
> must support direct communication over https
I wanted to note in particular that
> must provide a validated email address, either through AX or SREG
is not very useful for this sort of system. Keep in mind that Google
and MyOpenID, two of the providers on the whitelist, can return email
addresses, they are optional. It's just as likely that a Google user
will opt not to return an email address. And I believe (although I'm
not sure right now) that with MyOpenID you can return any email
address you want.
In short, you still have to verify the email address through
traditional means.
As another point, I do use MyOpenID as my provider, but I do so
through delegation from my personal site; that way I don't have to do
the work of maintaining a provider but I can use one that I trust.
With this whitelist I cannot use my chosen identifier.
Finally, the other respondents are correct in that trusting an OpenID
provider (as an RP) is the same as trusting an email address provider
if you have a reset password link (as PyPI does).
Please reconsider allowing a user-chosen identifier, even if you do
keep the identifier-select buttons.
Adam
From martin at v.loewis.de Sun Sep 13 07:40:01 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 13 Sep 2009 07:40:01 +0200
Subject: [Catalog-sig] OpenID on PyPI
In-Reply-To: <BF82B074-346F-4AEE-89D6-E5B01DD3EDED@therobots.org>
References: <BF82B074-346F-4AEE-89D6-E5B01DD3EDED@therobots.org>
Message-ID: <4AAC85B1.3070402@v.loewis.de>
> I wanted to note in particular that
>> must provide a validated email address, either through AX or SREG
>
> is not very useful for this sort of system. Keep in mind that Google and
> MyOpenID, two of the providers on the whitelist, can return email
> addresses, they are optional.
That's perfectly fine. If the user choses to not provide an email
address, PyPI will refuse to register them.
> It's just as likely that a Google user
> will opt not to return an email address. And I believe (although I'm not
> sure right now) that with MyOpenID you can return any email address you
> want.
That would be unfortunate. If that's possible, and becomes a problem in
practice, I will need to disable MyOpenID (for new users).
> In short, you still have to verify the email address through traditional
> means.
If that was the case, the whole OpenID process would be pointless for
a relying party.
However, I don't think that's actually the case. It is certainly
possible for a provider to spare me the work of verifying the user
information. It's just that I have to be selective in trusting
providers.
> As another point, I do use MyOpenID as my provider, but I do so through
> delegation from my personal site; that way I don't have to do the work
> of maintaining a provider but I can use one that I trust. With this
> whitelist I cannot use my chosen identifier.
But you don't have to. Just follow the OpenID link and be done.
> Please reconsider allowing a user-chosen identifier, even if you do keep
> the identifier-select buttons.
Sorry, I'm fundamentally opposed to integating a text box into the user
interface.
Regards,
Martin
From martin at v.loewis.de Sun Sep 13 12:05:13 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sun, 13 Sep 2009 12:05:13 +0200
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <94bdd2610909121700y17ef34d3yd3fe00bcd8a1777c@mail.gmail.com>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<4AAA5095.8050906@v.loewis.de>
<94bdd2610909110639y5b8163f8g2c02c822eadf512f@mail.gmail.com>
<4AABA392.5030903@v.loewis.de>
<94bdd2610909121700y17ef34d3yd3fe00bcd8a1777c@mail.gmail.com>
Message-ID: <4AACC3D9.6050605@v.loewis.de>
> $ easy_install hachoir-core
> Searching for hachoir-core
> Reading http://pypi.python.org/simple/hachoir-core/
> Reading http://hachoir.org/wiki/hachoir-core <- this page doesn't
> exists anymore that's an old home url
>
> page, you're blocked for a while !!
>
> If we keep this behavior, the client-side should be more smart.
I disagree. It's the package maintainer's task to make sure the
published URLs actually work.
The maintainer failing to do so, I think users should be more smart
and stop using an unmaintained package. Failing to do so, they should
specify an explicit version. Failing to do so, they deserve waiting for
the timeout.
> We are adding timeout handling in Distribute, and we will probably add
> a special option so it doesn't follow
> external links if some distributions were found at PyPI.
>
> But we should find a way to remove dead links from PyPI imho.
There is: ask the maintainer of the package to fix the page.
> Maybe by providing a proxy for all links ? So PyPI can fallback to an
> empty page if the link is dead ?
I really fail to see why this is a problem.
Regards,
Martin
From ziade.tarek at gmail.com Sun Sep 13 14:21:55 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 13 Sep 2009 14:21:55 +0200
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <4AACC3D9.6050605@v.loewis.de>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<4AAA5095.8050906@v.loewis.de>
<94bdd2610909110639y5b8163f8g2c02c822eadf512f@mail.gmail.com>
<4AABA392.5030903@v.loewis.de>
<94bdd2610909121700y17ef34d3yd3fe00bcd8a1777c@mail.gmail.com>
<4AACC3D9.6050605@v.loewis.de>
Message-ID: <94bdd2610909130521p78fbd4fqef734bd52ff86c2a@mail.gmail.com>
2009/9/13 "Martin v. L?wis" <martin at v.loewis.de>:
>> $ easy_install hachoir-core
>> Searching for hachoir-core
>> Reading http://pypi.python.org/simple/hachoir-core/
>> Reading http://hachoir.org/wiki/hachoir-core ? <- this page doesn't
>> exists anymore that's an old home url
>>
>> ? ? ?page, you're blocked for a while !!
>>
>> If we keep this behavior, the client-side should be more smart.
>
> I disagree. It's the package maintainer's task to make sure the
> published URLs actually work.
>
They do as a matter of fact. But once an url is published, it's
published "forever".
Take the hachoir-core as an example. The home URL was changed in
1.2.1 to :
"http://bitbucket.org/haypo/hachoir/wiki/hachoir-core"
the 1.2 version home url was:
"http://bitbucket.org/haypo/hachoir/wiki/hachoir-core"
But the PyPI simple API will keep track of both:
http://pypi.python.org/simple/hachoir-core
Leading to the problem described (because the script visits all urls
before it decides
what tarball to pick)
So what the maintainer should do ?
Recreate a new version of an old release so the old URL is removed
from PyPI ? Just register the metadata, knowing that the one contained in
the tarball is not the same ?
I mean, if I change my home url at the 25th version of my distribution,
I need to release again the 24 previous versions of the distribution ?
We can handle timeouts on client-side of course,
but I don't understand why you don't see the consistency problem
in the simple API I am describing here.
Maybe the solution would be to add in that page only the latest home URL link..
Tarek
From gerry.lowry at abilitybusinesscomputerservices.com Sun Sep 13 03:40:50 2009
From: gerry.lowry at abilitybusinesscomputerservices.com (gerry_lowry (alliston ontario canada (705) 250-0112))
Date: Sat, 12 Sep 2009 21:40:50 -0400
Subject: [Catalog-sig] OpenID on PyPI
References: <BF82B074-346F-4AEE-89D6-E5B01DD3EDED@therobots.org>
Message-ID: <4630F919E9DD415F981BADC8D45A02A3@zentrumvegan>
my 2 cents worth on OpenID ... bad idea ...
if a site supports it ... so be it
but also, have a unique site only login
because it is not secure to trust one provider
with one's password ... it's a pain but better
to have many unique passwords ... imagine
if someone successfully hacks an OpenID
site ... scary thought ... simple consequences
could be spam ... if OpenID user uses same
password for online banking ... ????
anyway ... that's my 2 cents worth
one site that uses OpenID suggested
I just make through away unique ids ...
for me, that does not work ... I do not
need to hide ... so I have same id and
different passwords ... works for me.
OpenID is delegation of far too much trust to a security void.
Gerry
__________________________________
Gerry Lowry, Principal
Ability Business Computer Services ~~ Because it's your Business, our Experience Counts!
68 John W. Taylor Avenue
Alliston ? Ontario ? Canada ? L9R 0E1 ? 705.250.0112
gerry.lowry at abilitybusinesscomputerservices.com http://abilitybusinesscomputerservices.com
From martin at v.loewis.de Sun Sep 13 15:53:36 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 13 Sep 2009 15:53:36 +0200
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <94bdd2610909130521p78fbd4fqef734bd52ff86c2a@mail.gmail.com>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<4AAA5095.8050906@v.loewis.de>
<94bdd2610909110639y5b8163f8g2c02c822eadf512f@mail.gmail.com>
<4AABA392.5030903@v.loewis.de>
<94bdd2610909121700y17ef34d3yd3fe00bcd8a1777c@mail.gmail.com>
<4AACC3D9.6050605@v.loewis.de>
<94bdd2610909130521p78fbd4fqef734bd52ff86c2a@mail.gmail.com>
Message-ID: <4AACF960.5060307@v.loewis.de>
> Take the hachoir-core as an example. The home URL was changed in
> 1.2.1 to :
>
> "http://bitbucket.org/haypo/hachoir/wiki/hachoir-core"
>
> the 1.2 version home url was:
>
> "http://bitbucket.org/haypo/hachoir/wiki/hachoir-core"
>
> But the PyPI simple API will keep track of both:
>
> http://pypi.python.org/simple/hachoir-core
>
> Leading to the problem described (because the script visits all urls
> before it decides
> what tarball to pick)
>
> So what the maintainer should do ?
One option would be to delete releases that point to versions which no
longer work. Another way would be to make sure that, despite the URLs
not pointing to actual data anymore, they still give a quick meaningful
error message (such as "connection refused"). In the very specific case,
deleting the DNS entry for hachoir.org, or pointing it to, say,
127.0.0.1.
> Recreate a new version of an old release so the old URL is removed
> from PyPI ? Just register the metadata, knowing that the one contained in
> the tarball is not the same ?
The latter would also fix this problem in a convenient way, ISTM.
> Maybe the solution would be to add in that page only the latest home URL link..
That would solve this specific problem. I'm not so sure it would solve
the general problem: what if some package *wishes* to provide different
homepage URLs for different releases, and has them all working
simultaneously?
Regards,
Martin
From adam at therobots.org Sun Sep 13 19:52:20 2009
From: adam at therobots.org (Adam Lowry)
Date: Sun, 13 Sep 2009 10:52:20 -0700
Subject: [Catalog-sig] OpenID on PyPI
In-Reply-To: <4AAC85B1.3070402@v.loewis.de>
References: <BF82B074-346F-4AEE-89D6-E5B01DD3EDED@therobots.org>
<4AAC85B1.3070402@v.loewis.de>
Message-ID: <FA6FEECB-57C6-4942-85B3-76DE643279BD@therobots.org>
On Sep 12, 2009, at 10:40 PM, Martin v. L?wis wrote:
> However, I don't think that's actually the case. It is certainly
> possible for a provider to spare me the work of verifying the user
> information. It's just that I have to be selective in trusting
> providers.
I think if you do some reading on discussions of SREG/AX and verified
email you'll find that this is truly in its nascent stages; only a
very few RPs have made the leap to trusting any email addresses, and
PyPI is the only one I've heard of that requires it, since it
restricts usage to a tiny minority of OpenID users.
And please consider the case where I have an existing PyPI account,
with a verified email address, but for convenience and security I wish
to use my OpenID. You don't need any email address from the provider.
And the PyPI login uses basic auth over an unencrypted channel, so any
OpenID provider is more secure from my end.
> Sorry, I'm fundamentally opposed to integating a text box into the
> user
> interface.
Why is that? Technical audiences like those of PyPI's userbase have no
trouble with optional OpenID fields for login. If it's an aesthetic
issue, there are many ways to highlight your preferred providers while
maintaining choice. I can provide examples for both cases or put you
in touch with other implementers, if you'd like.
I won't bother you much longer, as you obviously feel very strongly
about it, but as far as I can see the majority of the OpenID
Foundation leadership itself wouldn't be able to use OpenID on PyPI,
as a great many delegate or run their own providers and many of those
that don't use other major providers.
Adam
From pje at telecommunity.com Sun Sep 13 20:35:08 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 13 Sep 2009 14:35:08 -0400
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <4AACF960.5060307@v.loewis.de>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<4AAA5095.8050906@v.loewis.de>
<94bdd2610909110639y5b8163f8g2c02c822eadf512f@mail.gmail.com>
<4AABA392.5030903@v.loewis.de>
<94bdd2610909121700y17ef34d3yd3fe00bcd8a1777c@mail.gmail.com>
<4AACC3D9.6050605@v.loewis.de>
<94bdd2610909130521p78fbd4fqef734bd52ff86c2a@mail.gmail.com>
<4AACF960.5060307@v.loewis.de>
Message-ID: <20090913183505.79F3B3A403D@sparrow.telecommunity.com>
At 03:53 PM 9/13/2009 +0200, Martin v. L?wis wrote:
> > Maybe the solution would be to add in that page only the latest
> home URL link..
>
>That would solve this specific problem. I'm not so sure it would solve
>the general problem: what if some package *wishes* to provide different
>homepage URLs for different releases, and has them all working
>simultaneously?
When easy_install was written, the only links it could find were
those to "unhidden" versions, and older versions were hidden by default.
IIRC, the URLs of "hidden" versions were added to the "simple" API
after user complaints about not being able to access non-current
versions... thus creating the current problem.
Basically, one is stuck with either timeouts or un-findable old
versions in the case where a maintainer is not keeping their links tidy.
From ianb at colorstudy.com Mon Sep 14 18:40:29 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 14 Sep 2009 09:40:29 -0700
Subject: [Catalog-sig] Tweaks to edit screen
In-Reply-To: <4AA91473.4010604@v.loewis.de>
References: <b654cd2e0909081704i74ee12c0ybc69ed7cc0f22aef@mail.gmail.com>
<4AA91473.4010604@v.loewis.de>
Message-ID: <b654cd2e0909140940l7546e60eife6b1770218314ed@mail.gmail.com>
On Thu, Sep 10, 2009 at 8:00 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> The edit screen (e.g.,
>> http://pypi.python.org/pypi?:action=submit_form&name=virtualenv&version=1.3.3)
>> uses wrap="HARD" in textareas, which causes corruption of otherwise OK
>> ReST (uploaded via setup.py register) by introducing unwanted
>> newlines. ?wrap="SOFT" would be better.
>
> Would that have any negative consequences, e.g. when the text being
> entered is not ReST?
At first I would say not.. but then it occurred to me that if the text
is formatted as <pre> with no wrapping then you could get really long
lines.
Huh, I notice now that PyPI is treating non-ReST as markup. That is,
when I have `link <http://foobar.com>`_, and it's not valid ReST, it
gets rewritten as `link <HTTP://FOOBAR.COM>`_. That doesn't seem
right at all, and it seems like a cross-site-scripting attack could be
done this way (I haven't attempted one, though; it might be tricky to
make use of). It would be better to quote, i.e., `link
<http://foobar.com>`_
Anyway, I did a test on a local file, and found if you change:
<PRE>text...</PRE>
to:
<PRE style="white-space: pre-wrap">text</PRE>
Then long lines will get wrapped, while maintaining other
pre/whitespace formatting. I think that would resolve any issues with
not wrapping text on input.
>> Also, it's tricky to updated ==dev links, because links from all
>> versions are displayed on /simple/<package>, and the last link is
>> used, which is the oldest link. ?Just inverting the order of the links
>> would fix this; or at least inverting the links that are scraped from
>> the descriptions.
>
> I don't understand that request. Can you please provide a reference to
> a package where things are not as they should be, and indicate how they
> should be?
>
> Notice that, in r598, I was asked specifically to change the order to
> put file urls before the homepage url. So I'm hesitant to change
> anything without an independent confirmation that this would be a good
> change.
This happened to me when I was moving around the virtualenv
repository. The old links were like:
http://svn.colorstudy.com/virtualenv/trunk#egg=virtualenv-dev
I wanted to put in a new link:
http://bitbucket.org/ianb/virtualenv/get/tip.gz#egg=virtualenv-dev
Unfortunately when I do that, then both links appear on the simple
index, and the one that easy_install selects is to svn.
These are the links in the body of the text, not any structured field.
I believe these links are generally put last anyway. If you look at
the page now, I've used virtualeng-hg for the new tip because of this
problem:
http://pypi.python.org/simple/virtualenv/
Though damn, I realize I actually got it wrong -- easy_install is
selecting the last link, not the first one. Bah. Maybe the right fix
in this case is in easy_install and pip.
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
From jcea at jcea.es Wed Sep 16 08:09:07 2009
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 16 Sep 2009 08:09:07 +0200
Subject: [Catalog-sig] OpenID on PyPI
In-Reply-To: <4630F919E9DD415F981BADC8D45A02A3@zentrumvegan>
References: <BF82B074-346F-4AEE-89D6-E5B01DD3EDED@therobots.org>
<4630F919E9DD415F981BADC8D45A02A3@zentrumvegan>
Message-ID: <4AB08103.20303@jcea.es>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
gerry_lowry (alliston ontario canada (705) 250-0112) wrote:
> OpenID is delegation of far too much trust to a security void.
You can have your own OpenID provider, like me. Or, maybe, tomorrow you
can have OpenID support in the browser.
- --
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/
iQCVAwUBSrCBA5lgi5GaxT1NAQKisAP7BjdE796D+/ziN2+JfGiGQiAblloHMCo9
CAYDgxOO5Hfsld8Jk+t3ZKa/PhnLyUmfNfA4/uK2Fm76Kznr6fwdrIZSdjYemGyn
KCKGzrp3DmE25NLQvTo6hsnSDdRptBESBeKWUddyZi8OnULQ/DL2UNSQYNcKFcCZ
SOYQo7weKLo=
=+HqX
-----END PGP SIGNATURE-----
From martin at v.loewis.de Wed Sep 16 22:08:45 2009
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 16 Sep 2009 22:08:45 +0200
Subject: [Catalog-sig] Rating feature
Message-ID: <4AB145CD.900@v.loewis.de>
As per multiple requests, I have now added a feature where users
can rate packages. If you have any comments, please let me know
(if they are change requests, preferably by means of bug reports).
Regards,
Martin
From sridharr at activestate.com Wed Sep 16 23:12:49 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Wed, 16 Sep 2009 14:12:49 -0700
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB145CD.900@v.loewis.de>
References: <4AB145CD.900@v.loewis.de>
Message-ID: <op.u0dbvnz81q4jlt@whymac.activestate.com>
Are the ratings specific to a package or its release? I ask because rating
description reads: "Rate this release". Ok, playing with it for a while
suggests that the ratings are release-specific .. for
http://pypi.python.org/pypi/Pygments/1.1 and
http://pypi.python.org/pypi/Pygments/1.1.1 have different ratings.
I am not sure how release ratings are useful.
-srid
On Wed, 16 Sep 2009 13:08:45 -0700, Martin v. L?wis <martin at v.loewis.de>
wrote:
> As per multiple requests, I have now added a feature where users
> can rate packages. If you have any comments, please let me know
> (if they are change requests, preferably by means of bug reports).
>
> Regards,
> Martin
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
From chris at simplistix.co.uk Wed Sep 16 23:24:16 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 16 Sep 2009 22:24:16 +0100
Subject: [Catalog-sig] Rating feature
In-Reply-To: <op.u0dbvnz81q4jlt@whymac.activestate.com>
References: <4AB145CD.900@v.loewis.de>
<op.u0dbvnz81q4jlt@whymac.activestate.com>
Message-ID: <4AB15780.7070309@simplistix.co.uk>
Sridhar Ratnakumar wrote:
> Are the ratings specific to a package or its release? I ask because
> rating description reads: "Rate this release". Ok, playing with it for a
> while suggests that the ratings are release-specific .. for
> http://pypi.python.org/pypi/Pygments/1.1 and
> http://pypi.python.org/pypi/Pygments/1.1.1 have different ratings.
>
> I am not sure how release ratings are useful.
I think release specific is a good idea.
If a package has many brown bag releases, you might consider not using
it. If it only has one or two in a long line of releases, and all the
other ratings are high, then it should be fine :-)
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
From sridharr at activestate.com Wed Sep 16 23:28:05 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Wed, 16 Sep 2009 14:28:05 -0700
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB15780.7070309@simplistix.co.uk>
References: <4AB145CD.900@v.loewis.de>
<op.u0dbvnz81q4jlt@whymac.activestate.com>
<4AB15780.7070309@simplistix.co.uk>
Message-ID: <op.u0dck3is1q4jlt@whymac.activestate.com>
On Wed, 16 Sep 2009 14:24:16 -0700, Chris Withers <chris at simplistix.co.uk>
wrote:
> Sridhar Ratnakumar wrote:
> Are the ratings specific to a package or its release? I ask because
> rating description reads: "Rate this release". Ok, playing with it for a
> while suggests that the ratings are release-specific .. for
> http://pypi.python.org/pypi/Pygments/1.1 and
> http://pypi.python.org/pypi/Pygments/1.1.1 have different ratings.
> I am not sure how release ratings are useful.
> I think release specific is a good idea.
> If a package has many brown bag releases, you might consider not using
> it. If it only has one or two in a long line of releases, and all the
> other ratings are high, then it should be fine
I suppose by 'long line of releases' you are referring to, for instance,
CherryPy-2.x and CherryPy-3.x? This means, however, we would get ratings
for all the minor releases ... and looking at PyPI CherryPy has several of
them:
CherryPy 3.1.2
CherryPy 3.1.1
CherryPy 3.1.0
CherryPy 3.0.3
CherryPy 3.0.2
CherryPy 3.0.1
CherryPy 3.0.0
CherryPy 2.3.0
CherryPy 2.2.1
CherryPy 2.2.0
CherryPy 2.1.1
CherryPy 2.1.0
CherryPy 2.0.0-final
CherryPy 0.10
http://pypi.python.org/pypi/CherryPy
1) Why would one be interested in knowing different ratings for each and
every minor version?
2) If I want to find the rating of CherryPy - as a whole - where should I
go?
-srid
From chris at simplistix.co.uk Wed Sep 16 23:29:31 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 16 Sep 2009 22:29:31 +0100
Subject: [Catalog-sig] Rating feature
In-Reply-To: <op.u0dck3is1q4jlt@whymac.activestate.com>
References: <4AB145CD.900@v.loewis.de>
<op.u0dbvnz81q4jlt@whymac.activestate.com>
<4AB15780.7070309@simplistix.co.uk>
<op.u0dck3is1q4jlt@whymac.activestate.com>
Message-ID: <4AB158BB.9000302@simplistix.co.uk>
Sridhar Ratnakumar wrote:
> 1) Why would one be interested in knowing different ratings for each and
> every minor version?
Because some release are better than others.
> 2) If I want to find the rating of CherryPy - as a whole - where should
> I go?
An overview of the ratings for the current and past releases compared
*would* be a nice-to-have...
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
From sridharr at activestate.com Wed Sep 16 23:35:06 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Wed, 16 Sep 2009 14:35:06 -0700
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB158BB.9000302@simplistix.co.uk>
References: <4AB145CD.900@v.loewis.de>
<op.u0dbvnz81q4jlt@whymac.activestate.com>
<4AB15780.7070309@simplistix.co.uk>
<op.u0dck3is1q4jlt@whymac.activestate.com>
<4AB158BB.9000302@simplistix.co.uk>
Message-ID: <op.u0dcwsf71q4jlt@whymac.activestate.com>
On Wed, 16 Sep 2009 14:29:31 -0700, Chris Withers <chris at simplistix.co.uk>
wrote:
> Sridhar Ratnakumar wrote:
> 1) Why would one be interested in knowing different ratings for each and
> every minor version?
> Because some release are better than others.
Yet, the various minor versions may not differ (and thus not significantly
better or worse than on another) much, do they? I mean .. CherryPy-2.x and
CherryPy-3.x do have a lot of differences (like Jinja and Jinja2), but
there may not be much different in CherryPy-3.1.1 and CherryPy-3.1.2.
> 2) If I want to find the rating of CherryPy - as a whole - where should
> I go?
> An overview of the ratings for the current and past releases compared
> *would* be a nice-to-have...
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)
The feature in overall is nice .. and can have some UI help from
http://www.fyneworks.com/jquery/star-rating/
-srid
From chris at simplistix.co.uk Wed Sep 16 23:36:15 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 16 Sep 2009 22:36:15 +0100
Subject: [Catalog-sig] Rating feature
In-Reply-To: <op.u0dcwsf71q4jlt@whymac.activestate.com>
References: <4AB145CD.900@v.loewis.de>
<op.u0dbvnz81q4jlt@whymac.activestate.com>
<4AB15780.7070309@simplistix.co.uk>
<op.u0dck3is1q4jlt@whymac.activestate.com>
<4AB158BB.9000302@simplistix.co.uk>
<op.u0dcwsf71q4jlt@whymac.activestate.com>
Message-ID: <4AB15A4F.4090406@simplistix.co.uk>
Sridhar Ratnakumar wrote:
>> 2) If I want to find the rating of CherryPy - as a whole - where
>> should I go?
>> An overview of the ratings for the current and past releases compared
>> *would* be a nice-to-have...
>
> 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)
>
> The feature in overall is nice .. and can have some UI help from
> http://www.fyneworks.com/jquery/star-rating/
I'm sure Martin is looking forward to your submitted patches...
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
From martin at v.loewis.de Thu Sep 17 09:45:13 2009
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 17 Sep 2009 09:45:13 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <op.u0dbvnz81q4jlt@whymac.activestate.com>
References: <4AB145CD.900@v.loewis.de>
<op.u0dbvnz81q4jlt@whymac.activestate.com>
Message-ID: <4AB1E909.3040606@v.loewis.de>
Sridhar Ratnakumar schrieb:
> Are the ratings specific to a package or its release? I ask because
> rating description reads: "Rate this release". Ok, playing with it for a
> while suggests that the ratings are release-specific .. for
> http://pypi.python.org/pypi/Pygments/1.1 and
> http://pypi.python.org/pypi/Pygments/1.1.1 have different ratings.
Good: you figured it out on your own.
> I am not sure how release ratings are useful.
I think they are the only choice. Comments may apply only to a single
release, and ratings may not carry over from one version to another.
If users are actually able to make statements about a new release,
they will have to do so explicitly.
Regards,
Martin
From g.brandl at gmx.net Thu Sep 17 09:48:38 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 17 Sep 2009 09:48:38 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB145CD.900@v.loewis.de>
References: <4AB145CD.900@v.loewis.de>
Message-ID: <h8spok$k4d$1@ger.gmane.org>
Martin v. L?wis schrieb:
> As per multiple requests, I have now added a feature where users
> can rate packages. If you have any comments, please let me know
> (if they are change requests, preferably by means of bug reports).
What do you do with the comments that can optionally be given?
Will they be mailed to the project owners, or collected and displayed
on some admin page?
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 Thu Sep 17 10:08:48 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 17 Sep 2009 10:08:48 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <h8spok$k4d$1@ger.gmane.org>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
Message-ID: <4AB1EE90.9000607@v.loewis.de>
> What do you do with the comments that can optionally be given?
> Will they be mailed to the project owners, or collected and displayed
> on some admin page?
They don't get mailed. As for rendering them: see
http://pypi.python.org/pypi/xlrd
http://pypi.python.org/pypi/hgsvn
This is modelled very closely after the Amazon rating feature.
Regards,
Martin
From renesd at gmail.com Thu Sep 17 10:29:56 2009
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Thu, 17 Sep 2009 09:29:56 +0100
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB145CD.900@v.loewis.de>
References: <4AB145CD.900@v.loewis.de>
Message-ID: <64ddb72c0909170129m1b5a70efu3344c3e03df2cc60@mail.gmail.com>
awesome! nice work.
On Wed, Sep 16, 2009 at 9:08 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> As per multiple requests, I have now added a feature where users
> can rate packages. If you have any comments, please let me know
> (if they are change requests, preferably by means of bug reports).
>
> Regards,
> Martin
From g.brandl at gmx.net Thu Sep 17 11:30:33 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 17 Sep 2009 11:30:33 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB1EE90.9000607@v.loewis.de>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de>
Message-ID: <h8svnn$754$1@ger.gmane.org>
Martin v. L?wis schrieb:
>> What do you do with the comments that can optionally be given?
>> Will they be mailed to the project owners, or collected and displayed
>> on some admin page?
>
> They don't get mailed. As for rendering them: see
>
> http://pypi.python.org/pypi/xlrd
> http://pypi.python.org/pypi/hgsvn
>
> This is modelled very closely after the Amazon rating feature.
Okay, great. Thanks for the nice feature!
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 pje at telecommunity.com Thu Sep 17 16:00:41 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 17 Sep 2009 10:00:41 -0400
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB1EE90.9000607@v.loewis.de>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de>
Message-ID: <20090917140044.0611E3A4069@sparrow.telecommunity.com>
At 10:08 AM 9/17/2009 +0200, Martin v. L?wis wrote:
> > What do you do with the comments that can optionally be given?
> > Will they be mailed to the project owners, or collected and displayed
> > on some admin page?
>
>They don't get mailed. As for rendering them: see
>
>http://pypi.python.org/pypi/xlrd
>http://pypi.python.org/pypi/hgsvn
>
>This is modelled very closely after the Amazon rating feature.
Amazon ratings, however, show the names of the people leaving
feedback -- their real names, if available. This allows people
reading the reviews to know whether the reviewer is someone whose
reviews they usually agree or disagree with.
From martin at v.loewis.de Thu Sep 17 17:07:35 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 17 Sep 2009 17:07:35 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <20090917140044.0611E3A4069@sparrow.telecommunity.com>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de>
<20090917140044.0611E3A4069@sparrow.telecommunity.com>
Message-ID: <4AB250B7.8040203@v.loewis.de>
>> This is modelled very closely after the Amazon rating feature.
>
> Amazon ratings, however, show the names of the people leaving feedback
> -- their real names, if available. This allows people reading the
> reviews to know whether the reviewer is someone whose reviews they
> usually agree or disagree with.
So should I publish the account name (and real name if available) as well?
Regards,
Martin
From ziade.tarek at gmail.com Thu Sep 17 17:51:51 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 17 Sep 2009 17:51:51 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB250B7.8040203@v.loewis.de>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de>
<20090917140044.0611E3A4069@sparrow.telecommunity.com>
<4AB250B7.8040203@v.loewis.de>
Message-ID: <94bdd2610909170851k3cdc5c27v40a1847eff2d601a@mail.gmail.com>
On Thu, Sep 17, 2009 at 5:07 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
>>> This is modelled very closely after the Amazon rating feature.
>>
>> Amazon ratings, however, show the names of the people leaving feedback
>> -- their real names, if available. ?This allows people reading the
>> reviews to know whether the reviewer is someone whose reviews they
>> usually agree or disagree with.
>
> So should I publish the account name (and real name if available) as well?
>
+1
That will also raise the quality of the comments because as soon as
the commenter
name is displayed besides the comment, he will (hopefully) avoid fuzzy
comments like "crappy code"
and will make an effort into providing a better feedback.
--
Tarek Ziad? | http://ziade.org |????????????!
From g.brandl at gmx.net Thu Sep 17 17:52:24 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 17 Sep 2009 17:52:24 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <94bdd2610909170851k3cdc5c27v40a1847eff2d601a@mail.gmail.com>
References: <4AB145CD.900@v.loewis.de>
<h8spok$k4d$1@ger.gmane.org> <4AB1EE90.9000607@v.loewis.de> <20090917140044.0611E3A4069@sparrow.telecommunity.com> <4AB250B7.8040203@v.loewis.de>
<94bdd2610909170851k3cdc5c27v40a1847eff2d601a@mail.gmail.com>
Message-ID: <h8tm3n$k4g$1@ger.gmane.org>
Tarek Ziad? schrieb:
> On Thu, Sep 17, 2009 at 5:07 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>
>>>> This is modelled very closely after the Amazon rating feature.
>>>
>>> Amazon ratings, however, show the names of the people leaving feedback
>>> -- their real names, if available. This allows people reading the
>>> reviews to know whether the reviewer is someone whose reviews they
>>> usually agree or disagree with.
>>
>> So should I publish the account name (and real name if available) as well?
>>
>
> +1
>
> That will also raise the quality of the comments because as soon as
> the commenter
> name is displayed besides the comment, he will (hopefully) avoid fuzzy
> comments like "crappy code"
> and will make an effort into providing a better feedback.
Yep. +1. BTW, is there an XMLRPC API to query the rating?
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 ziade.tarek at gmail.com Thu Sep 17 18:04:25 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 17 Sep 2009 18:04:25 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB250B7.8040203@v.loewis.de>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de>
<20090917140044.0611E3A4069@sparrow.telecommunity.com>
<4AB250B7.8040203@v.loewis.de>
Message-ID: <94bdd2610909170904i28ed00c8kd695de21a52cbca7@mail.gmail.com>
On Thu, Sep 17, 2009 at 5:07 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
>>> This is modelled very closely after the Amazon rating feature.
>>
>> Amazon ratings, however, show the names of the people leaving feedback
>> -- their real names, if available. ?This allows people reading the
>> reviews to know whether the reviewer is someone whose reviews they
>> usually agree or disagree with.
>
> So should I publish the account name (and real name if available) as well?
By the way,
I suggest that the release rating and maybe a link to the form at the
bottom should be
placed or repeated on the top of the page because you can't expect
people to see it or fill it in some packages that
have long pages
example : http://pypi.python.org/pypi/zc.buildout
>
> Regards,
> Martin
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
--
Tarek Ziad? | http://ziade.org |????????????!
From g.brandl at gmx.net Thu Sep 17 18:11:17 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 17 Sep 2009 18:11:17 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <94bdd2610909170904i28ed00c8kd695de21a52cbca7@mail.gmail.com>
References: <4AB145CD.900@v.loewis.de>
<h8spok$k4d$1@ger.gmane.org> <4AB1EE90.9000607@v.loewis.de> <20090917140044.0611E3A4069@sparrow.telecommunity.com> <4AB250B7.8040203@v.loewis.de>
<94bdd2610909170904i28ed00c8kd695de21a52cbca7@mail.gmail.com>
Message-ID: <h8tn74$osu$1@ger.gmane.org>
Tarek Ziad? schrieb:
> On Thu, Sep 17, 2009 at 5:07 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>
>>>> This is modelled very closely after the Amazon rating feature.
>>>
>>> Amazon ratings, however, show the names of the people leaving feedback
>>> -- their real names, if available. This allows people reading the
>>> reviews to know whether the reviewer is someone whose reviews they
>>> usually agree or disagree with.
>>
>> So should I publish the account name (and real name if available) as well?
>
> By the way,
>
> I suggest that the release rating and maybe a link to the form at the
> bottom should be
> placed or repeated on the top of the page because you can't expect
> people to see it or fill it in some packages that
> have long pages
Do you think it's that important?
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 ziade.tarek at gmail.com Thu Sep 17 18:26:10 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 17 Sep 2009 18:26:10 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <h8tn74$osu$1@ger.gmane.org>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de>
<20090917140044.0611E3A4069@sparrow.telecommunity.com>
<4AB250B7.8040203@v.loewis.de>
<94bdd2610909170904i28ed00c8kd695de21a52cbca7@mail.gmail.com>
<h8tn74$osu$1@ger.gmane.org>
Message-ID: <94bdd2610909170926q2eb74367qd008a9c91f831ecd@mail.gmail.com>
On Thu, Sep 17, 2009 at 6:11 PM, Georg Brandl <g.brandl at gmx.net> wrote:
>> By the way,
>>
>> I suggest that the release rating and maybe a link to the form at the
>> bottom should be
>> placed or repeated on the top of the page because you can't expect
>> people to see it or fill it in some packages that
>> have long pages
>
> Do you think it's that important?
"important" no, better yes ;)
If you want people to *see* the rating of packages like zc.buildout,
you have to make it visible when the page loads.
that's a basic principle of ergonomics and its doesn't cost anything.
That's basically because it's the only part of a release screen that is going
to change often (the rating of a given release) shouldn't require scrolling.
Look at Sphinx page. Where's the rating ? I don't see it unless I scroll
(in my regular macbook)
That's no big deal of course, but having at the left of the package
name at the top
would be nicer to check the rating at a glimpse.
From martin at v.loewis.de Fri Sep 18 09:24:33 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 18 Sep 2009 09:24:33 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <94bdd2610909170851k3cdc5c27v40a1847eff2d601a@mail.gmail.com>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de>
<20090917140044.0611E3A4069@sparrow.telecommunity.com>
<4AB250B7.8040203@v.loewis.de>
<94bdd2610909170851k3cdc5c27v40a1847eff2d601a@mail.gmail.com>
Message-ID: <4AB335B1.7060103@v.loewis.de>
>> So should I publish the account name (and real name if available) as well?
>>
>
> +1
Done. Notice that PyPI doesn't store real names, so only account names
are displayed.
Regards,
Martin
From martin at v.loewis.de Fri Sep 18 09:25:42 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 18 Sep 2009 09:25:42 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <h8tm3n$k4g$1@ger.gmane.org>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org> <4AB1EE90.9000607@v.loewis.de> <20090917140044.0611E3A4069@sparrow.telecommunity.com> <4AB250B7.8040203@v.loewis.de> <94bdd2610909170851k3cdc5c27v40a1847eff2d601a@mail.gmail.com>
<h8tm3n$k4g$1@ger.gmane.org>
Message-ID: <4AB335F6.7060306@v.loewis.de>
> Yep. +1. BTW, is there an XMLRPC API to query the rating?
No. If you are interested in that, please submit a bug report
(preferably with a precise specification), or, better, submit
a patch.
Regards,
Martin
From martin at v.loewis.de Fri Sep 18 09:27:53 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 18 Sep 2009 09:27:53 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <94bdd2610909170904i28ed00c8kd695de21a52cbca7@mail.gmail.com>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de>
<20090917140044.0611E3A4069@sparrow.telecommunity.com>
<4AB250B7.8040203@v.loewis.de>
<94bdd2610909170904i28ed00c8kd695de21a52cbca7@mail.gmail.com>
Message-ID: <4AB33679.8080401@v.loewis.de>
> By the way,
>
> I suggest that the release rating and maybe a link to the form at the
> bottom should be
> placed or repeated on the top of the page because you can't expect
> people to see it or fill it in some packages that
> have long pages
>
> example : http://pypi.python.org/pypi/zc.buildout
Hmm. You seem to suggest that the rating is more important than the
information about the package provided by the package author. I think
I disagree.
Regards,
Martin
From martin at v.loewis.de Fri Sep 18 09:33:07 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 18 Sep 2009 09:33:07 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <94bdd2610909170926q2eb74367qd008a9c91f831ecd@mail.gmail.com>
References: <4AB145CD.900@v.loewis.de>
<h8spok$k4d$1@ger.gmane.org> <4AB1EE90.9000607@v.loewis.de> <20090917140044.0611E3A4069@sparrow.telecommunity.com> <4AB250B7.8040203@v.loewis.de> <94bdd2610909170904i28ed00c8kd695de21a52cbca7@mail.gmail.com> <h8tn74$osu$1@ger.gmane.org>
<94bdd2610909170926q2eb74367qd008a9c91f831ecd@mail.gmail.com>
Message-ID: <4AB337B3.50303@v.loewis.de>
> "important" no, better yes ;)
>
> If you want people to *see* the rating of packages like zc.buildout,
> you have to make it visible when the page loads.
>
> that's a basic principle of ergonomics and its doesn't cost anything.
It does cost something, in terms of ergonomics: it costs valuable page
space.
> That's basically because it's the only part of a release screen that is going
> to change often (the rating of a given release) shouldn't require scrolling.
I think that theory (that the rating will change often) still needs to
be proven in practice.
> Look at Sphinx page. Where's the rating ? I don't see it unless I scroll
> (in my regular macbook)
>
> That's no big deal of course, but having at the left of the package
> name at the top
> would be nicer to check the rating at a glimpse.
Ah - so that is the rationale - this is about self-esteem (so that you
as a package author can see how your rating evolves).
I'm waiting for other people to comment on this question. So far, it
is one in favor of top posting (you), and two against (Georg and me).
Regards,
Martin
From g.brandl at gmx.net Fri Sep 18 10:28:36 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 18 Sep 2009 10:28:36 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB335F6.7060306@v.loewis.de>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org> <4AB1EE90.9000607@v.loewis.de> <20090917140044.0611E3A4069@sparrow.telecommunity.com> <4AB250B7.8040203@v.loewis.de> <94bdd2610909170851k3cdc5c27v40a1847eff2d601a@mail.gmail.com> <h8tm3n$k4g$1@ger.gmane.org>
<4AB335F6.7060306@v.loewis.de>
Message-ID: <h8vgfl$5eh$1@ger.gmane.org>
Martin v. L?wis schrieb:
>> Yep. +1. BTW, is there an XMLRPC API to query the rating?
>
> No. If you are interested in that, please submit a bug report
> (preferably with a precise specification), or, better, submit
> a patch.
Very well, I'll look at it when I find some use for it :)
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 g.brandl at gmx.net Fri Sep 18 10:32:43 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 18 Sep 2009 10:32:43 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB337B3.50303@v.loewis.de>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org> <4AB1EE90.9000607@v.loewis.de> <20090917140044.0611E3A4069@sparrow.telecommunity.com> <4AB250B7.8040203@v.loewis.de> <94bdd2610909170904i28ed00c8kd695de21a52cbca7@mail.gmail.com> <h8tn74$osu$1@ger.gmane.org> <94bdd2610909170926q2eb74367qd008a9c91f831ecd@mail.gmail.com>
<4AB337B3.50303@v.loewis.de>
Message-ID: <h8vgnc$669$1@ger.gmane.org>
Martin v. L?wis schrieb:
>> "important" no, better yes ;)
>>
>> If you want people to *see* the rating of packages like zc.buildout,
>> you have to make it visible when the page loads.
>>
>> that's a basic principle of ergonomics and its doesn't cost anything.
>
> It does cost something, in terms of ergonomics: it costs valuable page
> space.
It wouldn't cost space if a short (graphical stars or somesuch)
representation of the rating was put right-aligned somewhere at the top.
However, I don't think it is necessary, and in any case, I would wait
for a time to see how well the feature is received.
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 chris at simplistix.co.uk Fri Sep 18 11:31:27 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 18 Sep 2009 10:31:27 +0100
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB1EE90.9000607@v.loewis.de>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de>
Message-ID: <4AB3536F.2040600@simplistix.co.uk>
Martin v. L?wis wrote:
> They don't get mailed. As for rendering them: see
>
> http://pypi.python.org/pypi/hgsvn
This raises an interesting question:
- how do I, as a package owner, delete spam comments when they
eventually turn up? (they will turn up, be very sure of that...)
- more subtle, how do I delete comments that belong elsewhere?
The hgsvn comment that's there feels like it belongs on a mailing list
and is not a "review comment". What I'd be looking for is a way to
delete the comment, reply to its author but leave the rating there.
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
From chris at simplistix.co.uk Fri Sep 18 11:33:03 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 18 Sep 2009 10:33:03 +0100
Subject: [Catalog-sig] Rating feature
In-Reply-To: <94bdd2610909170904i28ed00c8kd695de21a52cbca7@mail.gmail.com>
References: <4AB145CD.900@v.loewis.de>
<h8spok$k4d$1@ger.gmane.org> <4AB1EE90.9000607@v.loewis.de> <20090917140044.0611E3A4069@sparrow.telecommunity.com> <4AB250B7.8040203@v.loewis.de>
<94bdd2610909170904i28ed00c8kd695de21a52cbca7@mail.gmail.com>
Message-ID: <4AB353CF.6020001@simplistix.co.uk>
Tarek Ziad? wrote:
> I suggest that the release rating and maybe a link to the form at the
> bottom should be
> placed or repeated on the top of the page because you can't expect
> people to see it or fill it in some packages that
> have long pages
-1 to all of the above, the ratings are fine where they are...
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
From renesd at gmail.com Fri Sep 18 11:33:39 2009
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Fri, 18 Sep 2009 10:33:39 +0100
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB3536F.2040600@simplistix.co.uk>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de> <4AB3536F.2040600@simplistix.co.uk>
Message-ID: <64ddb72c0909180233r6b7cbc47qea32c0284744975b@mail.gmail.com>
On Fri, Sep 18, 2009 at 10:31 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> Martin v. L?wis wrote:
>>
>> They don't get mailed. As for rendering them: see
>>
>> http://pypi.python.org/pypi/hgsvn
>
> This raises an interesting question:
>
> - how do I, as a package owner, delete spam comments when they eventually
> turn up? (they will turn up, be very sure of that...)
>
> - more subtle, how do I delete comments that belong elsewhere?
> ?The hgsvn comment that's there feels like it belongs on a mailing list
> ?and is not a "review comment". What I'd be looking for is a way to
> ?delete the comment, reply to its author but leave the rating there.
>
> cheers,
>
Just leave them there? I don't think authors should be able to delete
bad reviews. Any feedback is valuable (to some people). A bug report
like that is a kind of review in a way. Better than 'Does not work
for me'.
From chris at simplistix.co.uk Fri Sep 18 11:37:16 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 18 Sep 2009 10:37:16 +0100
Subject: [Catalog-sig] Rating feature
In-Reply-To: <64ddb72c0909180233r6b7cbc47qea32c0284744975b@mail.gmail.com>
References: <4AB145CD.900@v.loewis.de>
<h8spok$k4d$1@ger.gmane.org> <4AB1EE90.9000607@v.loewis.de>
<4AB3536F.2040600@simplistix.co.uk>
<64ddb72c0909180233r6b7cbc47qea32c0284744975b@mail.gmail.com>
Message-ID: <4AB354CC.80504@simplistix.co.uk>
Ren? Dudfield wrote:
> Just leave them there? I don't think authors should be able to delete
> bad reviews.
That's not the point, the point is spam and crappy comments, both of
which are much more likely than a reviewer deleting a review they don't
like...
The last thing I want is to have all the package pages on PyPI become
semi-blogs with long threads of comments where people end up answering
other peoples comments, etc, etc.
Ratings I like, comments I don't. I can tolerate comments if I can at
least hoover them off my own packages.
Maybe a per-package option to disable comments? I would be fine to have
something shown that says "This evil package doesn't want to let you
comment on it" is that would make you happier ;-)
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
From renesd at gmail.com Fri Sep 18 11:48:11 2009
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Fri, 18 Sep 2009 10:48:11 +0100
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB354CC.80504@simplistix.co.uk>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de> <4AB3536F.2040600@simplistix.co.uk>
<64ddb72c0909180233r6b7cbc47qea32c0284744975b@mail.gmail.com>
<4AB354CC.80504@simplistix.co.uk>
Message-ID: <64ddb72c0909180248l3a982769hea74d587d7acb6d4@mail.gmail.com>
On Fri, Sep 18, 2009 at 10:37 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> Ren? Dudfield wrote:
>>
>> Just leave them there? ?I don't think authors should be able to delete
>> bad reviews.
>
> That's not the point, the point is spam and crappy comments, both of which
> are much more likely than a reviewer deleting a review they don't like...
>
> The last thing I want is to have all the package pages on PyPI become
> semi-blogs with long threads of comments where people end up answering other
> peoples comments, etc, etc.
>
> Ratings I like, comments I don't. I can tolerate comments if I can at least
> hoover them off my own packages.
>
> Maybe a per-package option to disable comments? I would be fine to have
> something shown that says "This evil package doesn't want to let you comment
> on it" is that would make you happier ;-)
>
> Chris
>
hi,
Calling packages evil does make me happier :) hehe. Well, I have no
objection about disabling comments if the author wants it.
People getting their questions answered is a good thing, so is
allowing authors to connect to users. Comments on the packages make
both of those easier.
Perhaps bug report links, and mailing list links would be good, so as
to get people commenting in the right place? However not all packages
have mailing lists or issue trackers.
cu,
From chris at simplistix.co.uk Fri Sep 18 11:57:23 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 18 Sep 2009 10:57:23 +0100
Subject: [Catalog-sig] Rating feature
In-Reply-To: <64ddb72c0909180248l3a982769hea74d587d7acb6d4@mail.gmail.com>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de> <4AB3536F.2040600@simplistix.co.uk>
<64ddb72c0909180233r6b7cbc47qea32c0284744975b@mail.gmail.com>
<4AB354CC.80504@simplistix.co.uk>
<64ddb72c0909180248l3a982769hea74d587d7acb6d4@mail.gmail.com>
Message-ID: <4AB35983.4010804@simplistix.co.uk>
Ren? Dudfield wrote:
> People getting their questions answered is a good thing, so is
> allowing authors to connect to users. Comments on the packages make
> both of those easier.
Not really, they make yet another avenue that a package maintainer who
wants to be responsible has to check every so often to make sure he or
she hasn't missed anything.
Mailing lists are for discussions and comments, I'd prefer to use those
excellent mature tools already rather than having to worry about the
development of yet another tool that will have to overcome the same
pitfalls (most notably misuse and, in particular, spam)
> Perhaps bug report links, and mailing list links would be good, so as
> to get people commenting in the right place?
Yes, I'm still waiting for the variously discussed metadata enhancements
;-) In the meantime, I provide all these for my own packages, for
example, here:
http://www.simplistix.co.uk/software/python/mailinglogger
> However not all packages
> have mailing lists or issue trackers.
I'd argue that it's easier for people to use the plethora of already
existing tools out there and provide links from PyPI rather than trying
to badger Martin into developing these on PyPI ;-)
In short, for me, ratings great, comments bad, wish I could turn them
off before they become a problem...
A slight ironic note: we can *only* vote for specific releases, with no
possibility of voting for the package as a whole or seeing the package's
rating once a new release is made, and yet we can *only* upload
documentation for the package as a whole, rather than per release, even
though there may be great differences between releases? Feels the wrong
way round to me ;-)
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
From ziade.tarek at gmail.com Fri Sep 18 10:46:46 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 18 Sep 2009 10:46:46 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB337B3.50303@v.loewis.de>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de>
<20090917140044.0611E3A4069@sparrow.telecommunity.com>
<4AB250B7.8040203@v.loewis.de>
<94bdd2610909170904i28ed00c8kd695de21a52cbca7@mail.gmail.com>
<h8tn74$osu$1@ger.gmane.org>
<94bdd2610909170926q2eb74367qd008a9c91f831ecd@mail.gmail.com>
<4AB337B3.50303@v.loewis.de>
Message-ID: <94bdd2610909180146h52f47a2aq1bf93dd3a69a720d@mail.gmail.com>
2009/9/18 "Martin v. L?wis" <martin at v.loewis.de>:
> It does cost something, in terms of ergonomics: it costs valuable page
> space.
That's not true. look at the mockups I am including.
- version_1 : the current system
- version_2: the rating on the top (just remove "customer")
>> That's no big deal of course, but having at the left of the package
>> name at the top
>> would be nicer to check the rating at a glimpse.
>
> Ah - so that is the rationale - this is about self-esteem (so that you
> as a package author can see how your rating evolves).
*sigh* No, that's not the rationale.
Again: if you want people to rate packages, this feature has to be visible.
at a glimpse. If it's on the bottom of a 100 miles long page, they
won't use it.
If you ask for feedback, you have to make it visible.
Just look at the two mockups I have included. There's the current system
and there's a mockup with the rating feature on the top right corner.
(like most rating systems, it's always near the title, just open
amazon for instance)
>
> I'm waiting for other people to comment on this question. So far, it
> is one in favor of top posting (you), and two against (Georg and me).
Well, I won't argue any longer. I've shown that page to some people
yesterday (all are web designers, like I am too) and I told them there was
a new rating system on pypi, and no one saw it. I had to explain where it was.
I doubt you will get a lot of feedback on some packages.
They all agreed with me, but they won't register in this ML just to do a +1.
I was just trying to give some hints on ergonomics, I won't fight
for this change.
Thanks for the feature,
Tarek
--
Tarek Ziad? | http://ziade.org |????????????!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: version_1.png
Type: image/png
Size: 154055 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20090918/4cbabd94/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: version_2.png
Type: image/png
Size: 171342 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20090918/4cbabd94/attachment-0003.png>
From martin at v.loewis.de Fri Sep 18 21:33:44 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 18 Sep 2009 21:33:44 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB3536F.2040600@simplistix.co.uk>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de> <4AB3536F.2040600@simplistix.co.uk>
Message-ID: <4AB3E098.3090001@v.loewis.de>
>> They don't get mailed. As for rendering them: see
>>
>> http://pypi.python.org/pypi/hgsvn
>
> This raises an interesting question:
>
> - how do I, as a package owner, delete spam comments when they
> eventually turn up? (they will turn up, be very sure of that...)
If it's proper spam, by filing a support request.
> - more subtle, how do I delete comments that belong elsewhere?
> The hgsvn comment that's there feels like it belongs on a mailing list
> and is not a "review comment". What I'd be looking for is a way to
> delete the comment, reply to its author but leave the rating there.
That sounds very complicated to implement. If you know the person who
posted the comment, you can ask her to remove the comment, and file it
elsewhere.
Regards,
Martin
From chris at simplistix.co.uk Mon Sep 21 12:37:00 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 21 Sep 2009 11:37:00 +0100
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB3E098.3090001@v.loewis.de>
References: <4AB145CD.900@v.loewis.de> <h8spok$k4d$1@ger.gmane.org>
<4AB1EE90.9000607@v.loewis.de> <4AB3536F.2040600@simplistix.co.uk>
<4AB3E098.3090001@v.loewis.de>
Message-ID: <4AB7574C.8010403@simplistix.co.uk>
Martin v. L?wis wrote:
>>> They don't get mailed. As for rendering them: see
>>>
>>> http://pypi.python.org/pypi/hgsvn
>> This raises an interesting question:
>>
>> - how do I, as a package owner, delete spam comments when they
>> eventually turn up? (they will turn up, be very sure of that...)
>
> If it's proper spam, by filing a support request.
What if it's just misplaced, but where the person posting the comment
refuses to remove it?
>> - more subtle, how do I delete comments that belong elsewhere?
>> The hgsvn comment that's there feels like it belongs on a mailing list
>> and is not a "review comment". What I'd be looking for is a way to
>> delete the comment, reply to its author but leave the rating there.
>
> That sounds very complicated to implement. If you know the person who
> posted the comment, you can ask her to remove the comment, and file it
> elsewhere.
Can I please beg for the ability for package maintainers to say "no
comments" (but leave ratings working!) even if that means something like
"This package has elected not to receive comments" on it?
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
From josh at bartletts.id.au Sun Sep 20 03:38:57 2009
From: josh at bartletts.id.au (Joshua Bartlett)
Date: Sun, 20 Sep 2009 11:38:57 +1000
Subject: [Catalog-sig] Category classifier request
Message-ID: <5023e5b80909191838o51af3e3bu8db9b84059dad9ea@mail.gmail.com>
Hi,
I've just been writing a setup.py for an application I've been working on
and I was just wondering whether it's possible to get a classifier for
"Framework :: Pygame".
Regards,
Josh Bartlett.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20090920/b614c521/attachment.htm>
From renesd at gmail.com Tue Sep 22 14:19:31 2009
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Tue, 22 Sep 2009 13:19:31 +0100
Subject: [Catalog-sig] Category classifier request
In-Reply-To: <5023e5b80909191838o51af3e3bu8db9b84059dad9ea@mail.gmail.com>
References: <5023e5b80909191838o51af3e3bu8db9b84059dad9ea@mail.gmail.com>
Message-ID: <64ddb72c0909220519r5916b723k7efc02599fc071da@mail.gmail.com>
On Sun, Sep 20, 2009 at 2:38 AM, Joshua Bartlett <josh at bartletts.id.au> wrote:
> Hi,
>
> I've just been writing a setup.py for an application I've been working on
> and I was just wondering whether it's possible to get a classifier for
> "Framework :: Pygame".
>
> Regards,
>
> Josh Bartlett.
>
yes please :)
see my previous request for it to be added here:
http://mail.python.org/pipermail/catalog-sig/2009-March/002017.html
Although probably better to add it as "Library :: pygame". Note the
lower case pygame... trying to keep it all lowercase now for pygame
where possible as that's the package name. Also, Library rather than
Framework as it's more a library (you call it, rather than it calls
you).
cheers!
From martin at v.loewis.de Tue Sep 22 15:21:08 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 22 Sep 2009 15:21:08 +0200
Subject: [Catalog-sig] Category classifier request
In-Reply-To: <64ddb72c0909220519r5916b723k7efc02599fc071da@mail.gmail.com>
References: <5023e5b80909191838o51af3e3bu8db9b84059dad9ea@mail.gmail.com>
<64ddb72c0909220519r5916b723k7efc02599fc071da@mail.gmail.com>
Message-ID: <4AB8CF44.2040602@v.loewis.de>
>> I've just been writing a setup.py for an application I've been working on
>> and I was just wondering whether it's possible to get a classifier for
>> "Framework :: Pygame".
>>
>> Regards,
>>
>> Josh Bartlett.
>>
>
>
> yes please :)
>
> see my previous request for it to be added here:
> http://mail.python.org/pipermail/catalog-sig/2009-March/002017.html
>
> Although probably better to add it as "Library :: pygame". Note the
> lower case pygame... trying to keep it all lowercase now for pygame
> where possible as that's the package name. Also, Library rather than
> Framework as it's more a library (you call it, rather than it calls
> you).
So can you two please agree on a spelling?
Regards,
Martin
From g.brandl at gmx.net Thu Sep 24 18:48:20 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 24 Sep 2009 18:48:20 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB145CD.900@v.loewis.de>
References: <4AB145CD.900@v.loewis.de>
Message-ID: <h9g7qo$1rd$1@ger.gmane.org>
Martin v. L?wis schrieb:
> As per multiple requests, I have now added a feature where users
> can rate packages. If you have any comments, please let me know
> (if they are change requests, preferably by means of bug reports).
As we can see from the rating on
http://pypi.python.org/pypi/hgsvn
people are not using the rating feature correctly -- PyPI's not a bug
tracker after all. (I can't comment on whether the traceback is a
real bug or a usage problem.)
Also, several people (like Jacob from Django) expressed a strong dislike
for the rating system in the current form. It is perhaps best to disable
rating again until the system is developed further and gets more features,
like admin of ratings. (I'm not suggesting you do it, Martin, if someone
cares enough they should.)
Georg
From lists at zopyx.com Thu Sep 24 18:52:48 2009
From: lists at zopyx.com (Andreas Jung)
Date: Thu, 24 Sep 2009 18:52:48 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <h9g7qo$1rd$1@ger.gmane.org>
References: <4AB145CD.900@v.loewis.de> <h9g7qo$1rd$1@ger.gmane.org>
Message-ID: <4ABBA3E0.70504@zopyx.com>
Am 24.09.09 18:48, schrieb Georg Brandl:
> Martin v. L?wis schrieb:
>
>> As per multiple requests, I have now added a feature where users
>> can rate packages. If you have any comments, please let me know
>> (if they are change requests, preferably by means of bug reports).
>>
> As we can see from the rating on
>
> http://pypi.python.org/pypi/hgsvn
>
> people are not using the rating feature correctly -- PyPI's not a bug
> tracker after all. (I can't comment on whether the traceback is a
> real bug or a usage problem.)
A clear underlined bold text with 50px font-height stating that the
comment box
should not be used for bugreports will help :)
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20090924/3a145dd8/attachment.vcf>
From jannis at leidel.info Thu Sep 24 19:40:07 2009
From: jannis at leidel.info (Jannis Leidel)
Date: Thu, 24 Sep 2009 19:40:07 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4ABBA3E0.70504@zopyx.com>
References: <4AB145CD.900@v.loewis.de> <h9g7qo$1rd$1@ger.gmane.org>
<4ABBA3E0.70504@zopyx.com>
Message-ID: <C392E3E5-B990-4BBB-A265-97A7C55B629D@leidel.info>
Am 24.09.2009 um 18:52 schrieb Andreas Jung:
> Am 24.09.09 18:48, schrieb Georg Brandl:
>> Martin v. L?wis schrieb:
>>
>>> As per multiple requests, I have now added a feature where users
>>> can rate packages. If you have any comments, please let me know
>>> (if they are change requests, preferably by means of bug reports).
>>>
>> As we can see from the rating on
>>
>> http://pypi.python.org/pypi/hgsvn
>>
>> people are not using the rating feature correctly -- PyPI's not a bug
>> tracker after all. (I can't comment on whether the traceback is a
>> real bug or a usage problem.)
>
> A clear underlined bold text with 50px font-height stating that the
> comment box
> should not be used for bugreports will help :)
I wish that would be true, spammers and trolls won't stop abusing the
feature just because they are asked to.
Will there be someone moderating/maintaining the comments and rating
on the long run?
Best,
Jannis
From ianb at colorstudy.com Thu Sep 24 21:24:37 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 24 Sep 2009 14:24:37 -0500
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4AB145CD.900@v.loewis.de>
References: <4AB145CD.900@v.loewis.de>
Message-ID: <b654cd2e0909241224k20f20549yb0ebc3a580597d81@mail.gmail.com>
A few thoughts:
* On hgsvn I see some points, but no indication on the scale. That is,
there's 1 and 2 points, but out of... 5? Once I'm logged in I can see the
scale, but not until then.
* There's a bunch of different ideas on how to average scores. I don't have
an opinions at the moment, except that we keep enough data to change the
algorithm in the future. Specifically the score, user, date (i.e., not just
aggregate information).
* I expect the comment/rating activity to be relatively low, so throwing
everything away on every release seems problematic. For comments
specifically it would be nice if they remained, though maybe old comments
could be hid by the maintainer (or by anyone?) Hiding might just put them
in a place where they were hidden (visible with a Javascript control).
Scoring I'm less sure about; you could weight scores according to their
distance from the current release. Or throw them away as you are doing now;
I'm generally less concerned with scoring than comments.
* Since people can and will report problems (like with hgsvn), it would be
nice if the comments were threaded so that problems could be responded to.
* Because people report problems anyplace they can, this is going to be hard
for some maintainers, because there will be unanswered questions the
maintainer won't be aware of. Emailing new comments would be really helpful
(maybe as a user preference).
* Comments on Trove classifiers would be nice. Though right now the
classifiers are too hard to find and the actual categories not well used or
complete enough. But if they *were* well used, this would be a place for
people to put comparative comments (e.g., on this page for XML:
http://pypi.python.org/pypi?:action=browse&show=all&c=500 -- but getting to
that page was really hard).
* Generally I think it would be a lot more useful to people finding packages
if there were topic guides, which would have a description of a class of
tasks (like parsing XML) and a user-curated list of packages that apply. In
theory the wiki could be used for this, and people try to use it for this,
but it's not very successful (e.g.,
http://wiki.python.org/moin/WebFrameworks -- which is a lot better than it
has been at many points in the past). Having a list of packages with the
age of the last release, the score of the package, Development Status trove
classifier, the short description from PyPI, etc. would make a much nicer
list. But it has to be curated -- package maintainers don't consistently
use package metadata well enough to make this work.
* Can you not comment on your own packages? Not scoring is fine, but
comments should be available.
* It would be nice to have a field that links to an issue tracker or forum
of some sorts, and display that right next to the comment box, like "If you
have an issue use <project's issue tracker>". hgsvn is an example of when
that isn't used. Alternately a field that would render right next to the
comment box (ReST) where the project can give instructions (like: if you
need help, jump on #project on irc.freenode.net, or `submit a bug <...>`_ or
`search our mailing list <...>`_). Free text would probably be better, as
it gives full flexibility.
* Less flexibly, a default message about what should go in comments would be
helpful. I'm not sure what the description should be, but just "comment"
isn't enough IMHO.
--
Ian Bicking | http://blog.ianbicking.org |
http://topplabs.org/civichacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20090924/94b45906/attachment.htm>
From martin at v.loewis.de Thu Sep 24 21:32:28 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 24 Sep 2009 21:32:28 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <h9g7qo$1rd$1@ger.gmane.org>
References: <4AB145CD.900@v.loewis.de> <h9g7qo$1rd$1@ger.gmane.org>
Message-ID: <4ABBC94C.8010302@v.loewis.de>
>> As per multiple requests, I have now added a feature where users
>> can rate packages. If you have any comments, please let me know
>> (if they are change requests, preferably by means of bug reports).
>
> As we can see from the rating on
>
> http://pypi.python.org/pypi/hgsvn
>
> people are not using the rating feature correctly -- PyPI's not a bug
> tracker after all. (I can't comment on whether the traceback is a
> real bug or a usage problem.)
I'm not so sure it is incorrect usage. The hgsvn page doesn't provide
a home page or bug tracker URL.
> Also, several people (like Jacob from Django) expressed a strong dislike
> for the rating system in the current form.
Where can I read about that?
> It is perhaps best to disable
> rating again until the system is developed further and gets more features,
> like admin of ratings. (I'm not suggesting you do it, Martin, if someone
> cares enough they should.)
I implemented the feature after multiple requests, and it took me some
time, so I'm not really willing to give up so easily.
So far, no feature requests or bug reports against that feature have
been made in the PyPI bug tracker. So people apparently don't see
a pressing need for change.
Regards,
Martin
From martin at v.loewis.de Thu Sep 24 21:34:17 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 24 Sep 2009 21:34:17 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <C392E3E5-B990-4BBB-A265-97A7C55B629D@leidel.info>
References: <4AB145CD.900@v.loewis.de>
<h9g7qo$1rd$1@ger.gmane.org> <4ABBA3E0.70504@zopyx.com>
<C392E3E5-B990-4BBB-A265-97A7C55B629D@leidel.info>
Message-ID: <4ABBC9B9.504@v.loewis.de>
> I wish that would be true, spammers and trolls won't stop abusing the
> feature just because they are asked to.
>
> Will there be someone moderating/maintaining the comments and rating on
> the long run?
People who observe spam or other abuse should report to the PyPI bug
tracker as a support request. I haven't seen a case of abuse or
trolling, yet.
Regards,
Martin
From ianb at colorstudy.com Thu Sep 24 21:37:19 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 24 Sep 2009 14:37:19 -0500
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <94bdd2610909130521p78fbd4fqef734bd52ff86c2a@mail.gmail.com>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<4AAA5095.8050906@v.loewis.de>
<94bdd2610909110639y5b8163f8g2c02c822eadf512f@mail.gmail.com>
<4AABA392.5030903@v.loewis.de>
<94bdd2610909121700y17ef34d3yd3fe00bcd8a1777c@mail.gmail.com>
<4AACC3D9.6050605@v.loewis.de>
<94bdd2610909130521p78fbd4fqef734bd52ff86c2a@mail.gmail.com>
Message-ID: <b654cd2e0909241237i29281722x87d1c9f03e54f75d@mail.gmail.com>
2009/9/13 Tarek Ziad? <ziade.tarek at gmail.com>
> 2009/9/13 "Martin v. L?wis" <martin at v.loewis.de>:
> >> $ easy_install hachoir-core
> >> Searching for hachoir-core
> >> Reading http://pypi.python.org/simple/hachoir-core/
> >> Reading http://hachoir.org/wiki/hachoir-core <- this page doesn't
> >> exists anymore that's an old home url
> >>
> >> page, you're blocked for a while !!
> >>
> >> If we keep this behavior, the client-side should be more smart.
> >
> > I disagree. It's the package maintainer's task to make sure the
> > published URLs actually work.
> >
>
> They do as a matter of fact. But once an url is published, it's
> published "forever".
>
> Take the hachoir-core as an example. The home URL was changed in
> 1.2.1 to :
>
> "http://bitbucket.org/haypo/hachoir/wiki/hachoir-core"
>
> the 1.2 version home url was:
>
> "http://bitbucket.org/haypo/hachoir/wiki/hachoir-core"
>
> But the PyPI simple API will keep track of both:
>
> http://pypi.python.org/simple/hachoir-core
>
> Leading to the problem described (because the script visits all urls
> before it decides
> what tarball to pick)
>
> So what the maintainer should do ?
>
> Recreate a new version of an old release so the old URL is removed
> from PyPI ? Just register the metadata, knowing that the one contained in
> the tarball is not the same ?
>
> I mean, if I change my home url at the 25th version of my distribution,
> I need to release again the 24 previous versions of the distribution ?
>
Another related problem is links like, say,
http://svn.colorstudy.com/virtualenv/trunk#egg=virtualenv-dev -- I have a
bunch of these links in old versions, I'd like to move the repository
somewhere else, and so of course update that link and magically everyone can
still install virtualenv==dev. Except the link remains unless I edit all
old versions of the packages to change or remove that link.
Is there a reason the simple version of the API needs to include links from
the descriptions of any old versions of the package? Eliminating links from
all old/hidden package descriptions would I think solve this (except for
links explicitly for downloads, which are generally versioned and okay).
--
Ian Bicking | http://blog.ianbicking.org |
http://topplabs.org/civichacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20090924/5f8cc8c2/attachment.htm>
From ianb at colorstudy.com Thu Sep 24 21:39:28 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 24 Sep 2009 14:39:28 -0500
Subject: [Catalog-sig] Tweaks to edit screen
In-Reply-To: <b654cd2e0909140940l7546e60eife6b1770218314ed@mail.gmail.com>
References: <b654cd2e0909081704i74ee12c0ybc69ed7cc0f22aef@mail.gmail.com>
<4AA91473.4010604@v.loewis.de>
<b654cd2e0909140940l7546e60eife6b1770218314ed@mail.gmail.com>
Message-ID: <b654cd2e0909241239l2a359982gae7c4caedee4ff8d@mail.gmail.com>
Since you are in this code for other PyPI changes, can this be fixed too?
The concise request at this point:
Change wrap="HARD" to wrap="SOFT" in edit textareas.
When displaying non-ReST package descriptions, change <PRE> to <PRE
style="white-space: pre-wrap">
On Mon, Sep 14, 2009 at 11:40 AM, Ian Bicking <ianb at colorstudy.com> wrote:
> On Thu, Sep 10, 2009 at 8:00 AM, "Martin v. L?wis" <martin at v.loewis.de>
> wrote:
> >> The edit screen (e.g.,
> >>
> http://pypi.python.org/pypi?:action=submit_form&name=virtualenv&version=1.3.3
> )
> >> uses wrap="HARD" in textareas, which causes corruption of otherwise OK
> >> ReST (uploaded via setup.py register) by introducing unwanted
> >> newlines. wrap="SOFT" would be better.
> >
> > Would that have any negative consequences, e.g. when the text being
> > entered is not ReST?
>
> At first I would say not.. but then it occurred to me that if the text
> is formatted as <pre> with no wrapping then you could get really long
> lines.
>
> Huh, I notice now that PyPI is treating non-ReST as markup. That is,
> when I have `link <http://foobar.com>`_, and it's not valid ReST, it
> gets rewritten as `link <HTTP://FOOBAR.COM>`_. That doesn't seem
> right at all, and it seems like a cross-site-scripting attack could be
> done this way (I haven't attempted one, though; it might be tricky to
> make use of). It would be better to quote, i.e., `link
> <http://foobar.com>`_
>
> Anyway, I did a test on a local file, and found if you change:
>
> <PRE>text...</PRE>
>
> to:
>
> <PRE style="white-space: pre-wrap">text</PRE>
>
> Then long lines will get wrapped, while maintaining other
> pre/whitespace formatting. I think that would resolve any issues with
> not wrapping text on input.
>
> >> Also, it's tricky to updated ==dev links, because links from all
> >> versions are displayed on /simple/<package>, and the last link is
> >> used, which is the oldest link. Just inverting the order of the links
> >> would fix this; or at least inverting the links that are scraped from
> >> the descriptions.
> >
> > I don't understand that request. Can you please provide a reference to
> > a package where things are not as they should be, and indicate how they
> > should be?
> >
> > Notice that, in r598, I was asked specifically to change the order to
> > put file urls before the homepage url. So I'm hesitant to change
> > anything without an independent confirmation that this would be a good
> > change.
>
> This happened to me when I was moving around the virtualenv
> repository. The old links were like:
>
> http://svn.colorstudy.com/virtualenv/trunk#egg=virtualenv-dev
>
> I wanted to put in a new link:
>
> http://bitbucket.org/ianb/virtualenv/get/tip.gz#egg=virtualenv-dev
>
> Unfortunately when I do that, then both links appear on the simple
> index, and the one that easy_install selects is to svn.
>
> These are the links in the body of the text, not any structured field.
> I believe these links are generally put last anyway. If you look at
> the page now, I've used virtualeng-hg for the new tip because of this
> problem:
>
> http://pypi.python.org/simple/virtualenv/
>
> Though damn, I realize I actually got it wrong -- easy_install is
> selecting the last link, not the first one. Bah. Maybe the right fix
> in this case is in easy_install and pip.
>
> --
> Ian Bicking | http://blog.ianbicking.org |
> http://topplabs.org/civichacker
>
--
Ian Bicking | http://blog.ianbicking.org |
http://topplabs.org/civichacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20090924/ec5111f2/attachment.htm>
From doug.hellmann at gmail.com Thu Sep 24 21:48:31 2009
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Thu, 24 Sep 2009 15:48:31 -0400
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4ABBC94C.8010302@v.loewis.de>
References: <4AB145CD.900@v.loewis.de> <h9g7qo$1rd$1@ger.gmane.org>
<4ABBC94C.8010302@v.loewis.de>
Message-ID: <58F8BD41-CBA9-40C6-A1C9-D943D5AC18C8@gmail.com>
On Sep 24, 2009, at 3:32 PM, Martin v. L?wis wrote:
> So far, no feature requests or bug reports against that feature have
> been made in the PyPI bug tracker. So people apparently don't see
> a pressing need for change.
This is a good example of a limitation of having comments in the
"wrong" place. Just as you want feedback through the bug tracker
instead of on this mailing list, I don't want yet another place I have
to look for bug reports and support requests against the packages I
maintain.
I interact with PyPI mostly through distutils (i.e., not the web
interface). I'm not likely to see questions or bug reports in
comments on the PyPI pages for my packages unless the system pushes
them to me. On the other hand, since I wrote most of the content on
those pages readers are likely to assume I do have control over all
aspects of the page and *will* see their requests for help.
I'm +0 on the numerical rankings, but I'm worried that appearing to be
unresponsive to written user feedback is going to have a negative
impact on the image for any projects I list on PyPI (note: that's
"list" not "host" -- I host my own projects elsewhere, complete with
comments, bug trackers, and sometimes mailing lists).
Can we have a compromise solution that allows a project owner to
optionally close comments but leaves the numerical ranking in place?
Doug
From martin at v.loewis.de Thu Sep 24 22:17:44 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 24 Sep 2009 22:17:44 +0200
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <b654cd2e0909241237i29281722x87d1c9f03e54f75d@mail.gmail.com>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<4AAA5095.8050906@v.loewis.de>
<94bdd2610909110639y5b8163f8g2c02c822eadf512f@mail.gmail.com>
<4AABA392.5030903@v.loewis.de>
<94bdd2610909121700y17ef34d3yd3fe00bcd8a1777c@mail.gmail.com>
<4AACC3D9.6050605@v.loewis.de>
<94bdd2610909130521p78fbd4fqef734bd52ff86c2a@mail.gmail.com>
<b654cd2e0909241237i29281722x87d1c9f03e54f75d@mail.gmail.com>
Message-ID: <4ABBD3E8.2020507@v.loewis.de>
> Is there a reason the simple version of the API needs to include links
> from the descriptions of any old versions of the package? Eliminating
> links from all old/hidden package descriptions would I think solve this
> (except for links explicitly for downloads, which are generally
> versioned and okay).
They are included because Jim Fulton said they ought to be included.
More precisely, the spec for the simple API was this:
- place all links on a single page, for all versions, to reduce the
number of roundtrips
- per version, include the links from the metadata, plus any links from
the description.
I'm not sure what would break if I change not, nor do I understand what
"#egg=virtualenv-dev" does.
I fail to see your problem, though: if you move the source repository
to a different URL, and just break the old URLs to return an HTTP error,
wouldn't that be sufficient?
Regards,
Martin
From ianb at colorstudy.com Thu Sep 24 22:28:30 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 24 Sep 2009 15:28:30 -0500
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <4ABBD3E8.2020507@v.loewis.de>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<4AAA5095.8050906@v.loewis.de>
<94bdd2610909110639y5b8163f8g2c02c822eadf512f@mail.gmail.com>
<4AABA392.5030903@v.loewis.de>
<94bdd2610909121700y17ef34d3yd3fe00bcd8a1777c@mail.gmail.com>
<4AACC3D9.6050605@v.loewis.de>
<94bdd2610909130521p78fbd4fqef734bd52ff86c2a@mail.gmail.com>
<b654cd2e0909241237i29281722x87d1c9f03e54f75d@mail.gmail.com>
<4ABBD3E8.2020507@v.loewis.de>
Message-ID: <b654cd2e0909241328tb7f515avd29c06ac2624c0eb@mail.gmail.com>
2009/9/24 "Martin v. L?wis" <martin at v.loewis.de>
> > Is there a reason the simple version of the API needs to include links
> > from the descriptions of any old versions of the package? Eliminating
> > links from all old/hidden package descriptions would I think solve this
> > (except for links explicitly for downloads, which are generally
> > versioned and okay).
>
> They are included because Jim Fulton said they ought to be included.
> More precisely, the spec for the simple API was this:
> - place all links on a single page, for all versions, to reduce the
> number of roundtrips
> - per version, include the links from the metadata, plus any links from
> the description.
>
> I'm not sure what would break if I change not, nor do I understand what
> "#egg=virtualenv-dev" does.
>
It tells easy_install (and pip) that the URL points to a location that
contains the virtualenv package, version "dev". For most tarballs, the URL
of the tarball can be parsed to get the package and version number, but this
isn't the case for repositories (or things like a tarball created on demand,
like you get from most hg and git repositories).
> I fail to see your problem, though: if you move the source repository
> to a different URL, and just break the old URLs to return an HTTP error,
> wouldn't that be sufficient?
>
I'm pretty sure something like this is happening:
versions = {}
for url, version in find_all_the_links():
versions[version] = url
So it's just wiping over the new URL with the old one.
--
Ian Bicking | http://blog.ianbicking.org |
http://topplabs.org/civichacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20090924/13ffd5bd/attachment.htm>
From martin at v.loewis.de Thu Sep 24 22:50:19 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 24 Sep 2009 22:50:19 +0200
Subject: [Catalog-sig] simple index and urls exracted from metadata text
fields
In-Reply-To: <b654cd2e0909241328tb7f515avd29c06ac2624c0eb@mail.gmail.com>
References: <94bdd2610909110613t71ac0251kb490c0d847e2ef89@mail.gmail.com>
<4AAA5095.8050906@v.loewis.de>
<94bdd2610909110639y5b8163f8g2c02c822eadf512f@mail.gmail.com>
<4AABA392.5030903@v.loewis.de>
<94bdd2610909121700y17ef34d3yd3fe00bcd8a1777c@mail.gmail.com>
<4AACC3D9.6050605@v.loewis.de>
<94bdd2610909130521p78fbd4fqef734bd52ff86c2a@mail.gmail.com>
<b654cd2e0909241237i29281722x87d1c9f03e54f75d@mail.gmail.com>
<4ABBD3E8.2020507@v.loewis.de>
<b654cd2e0909241328tb7f515avd29c06ac2624c0eb@mail.gmail.com>
Message-ID: <4ABBDB8B.7030300@v.loewis.de>
> I'm pretty sure something like this is happening:
>
> versions = {}
> for url, version in find_all_the_links():
> versions[version] = url
>
> So it's just wiping over the new URL with the old one.
So that's a bug in setuptools, right? It shouldn't use
a broken URL if a good one is available as well.
I suppose you can work around by putting a redirect HTTP
response onto the old URL that points to the new location.
Regards,
Martin
From martin at v.loewis.de Thu Sep 24 22:52:39 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 24 Sep 2009 22:52:39 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <58F8BD41-CBA9-40C6-A1C9-D943D5AC18C8@gmail.com>
References: <4AB145CD.900@v.loewis.de> <h9g7qo$1rd$1@ger.gmane.org>
<4ABBC94C.8010302@v.loewis.de>
<58F8BD41-CBA9-40C6-A1C9-D943D5AC18C8@gmail.com>
Message-ID: <4ABBDC17.80809@v.loewis.de>
> Can we have a compromise solution that allows a project owner to
> optionally close comments but leaves the numerical ranking in place?
Not sure what exactly you are asking for; contributions are welcome.
Please use the PyPI bug tracker for feature requests or bug reports
on PyPI.
Regards,
Martin
From doug.hellmann at gmail.com Thu Sep 24 23:01:56 2009
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Thu, 24 Sep 2009 17:01:56 -0400
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4ABBDC17.80809@v.loewis.de>
References: <4AB145CD.900@v.loewis.de> <h9g7qo$1rd$1@ger.gmane.org>
<4ABBC94C.8010302@v.loewis.de>
<58F8BD41-CBA9-40C6-A1C9-D943D5AC18C8@gmail.com>
<4ABBDC17.80809@v.loewis.de>
Message-ID: <C47DC54A-F000-4E63-97FE-6F7C78A174D9@gmail.com>
On Sep 24, 2009, at 4:52 PM, Martin v. L?wis wrote:
>> Can we have a compromise solution that allows a project owner to
>> optionally close comments but leaves the numerical ranking in place?
>
> Not sure what exactly you are asking for; contributions are welcome.
I'm asking for you to turn off comments, or give me a way to do it
myself on my own projects, because I don't want my users mad at me
when I don't see their questions on a web site over which I have
little control.
Learning all of the existing code well enough to modify it would be a
big investment of time on my part, and not one I care to make without
a minimal indication from you that the change would have the least
chance of being accepted. I would at least like to reach the point
where we can agree on the *idea* of a feature before I go digging
around in a bunch of code trying to implement it.
> Please use the PyPI bug tracker for feature requests or bug reports
> on PyPI.
Sorry, I learned about this change on this mailing list, so I thought
it was appropriate to discuss it here. Where is the bug tracker?
Doug
From martin at v.loewis.de Thu Sep 24 23:11:26 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 24 Sep 2009 23:11:26 +0200
Subject: [Catalog-sig] Rating feature
In-Reply-To: <C47DC54A-F000-4E63-97FE-6F7C78A174D9@gmail.com>
References: <4AB145CD.900@v.loewis.de> <h9g7qo$1rd$1@ger.gmane.org>
<4ABBC94C.8010302@v.loewis.de>
<58F8BD41-CBA9-40C6-A1C9-D943D5AC18C8@gmail.com>
<4ABBDC17.80809@v.loewis.de>
<C47DC54A-F000-4E63-97FE-6F7C78A174D9@gmail.com>
Message-ID: <4ABBE07E.50602@v.loewis.de>
> Sorry, I learned about this change on this mailing list, so I thought it
> was appropriate to discuss it here. Where is the bug tracker?
It's linked on each PyPI web page, and lives at
https://sourceforge.net/projects/pypi/
http://sourceforge.net/tracker/?group_id=66150&atid=513503
Regards,
Martin
From renesd at gmail.com Fri Sep 25 12:25:00 2009
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Fri, 25 Sep 2009 11:25:00 +0100
Subject: [Catalog-sig] Category classifier request
In-Reply-To: <4AB8CF44.2040602@v.loewis.de>
References: <5023e5b80909191838o51af3e3bu8db9b84059dad9ea@mail.gmail.com>
<64ddb72c0909220519r5916b723k7efc02599fc071da@mail.gmail.com>
<4AB8CF44.2040602@v.loewis.de>
Message-ID: <64ddb72c0909250325g60863f4frb605169412592c84@mail.gmail.com>
hi,
Josh, do you have any objections to 'Library :: pygame' ?
cheers,
On Tue, Sep 22, 2009 at 2:21 PM, "Martin v. L?wis" <martin at v.loewis.de>wrote:
> >> I've just been writing a setup.py for an application I've been working
> on
> >> and I was just wondering whether it's possible to get a classifier for
> >> "Framework :: Pygame".
> >>
> >> Regards,
> >>
> >> Josh Bartlett.
> >>
> >
> >
> > yes please :)
> >
> > see my previous request for it to be added here:
> > http://mail.python.org/pipermail/catalog-sig/2009-March/002017.html
> >
> > Although probably better to add it as "Library :: pygame". Note the
> > lower case pygame... trying to keep it all lowercase now for pygame
> > where possible as that's the package name. Also, Library rather than
> > Framework as it's more a library (you call it, rather than it calls
> > you).
>
>
> So can you two please agree on a spelling?
>
> Regards,
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20090925/aea44eb6/attachment.htm>
From doug.hellmann at gmail.com Sun Sep 27 19:49:38 2009
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Sun, 27 Sep 2009 13:49:38 -0400
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4ABBE07E.50602@v.loewis.de>
References: <4AB145CD.900@v.loewis.de> <h9g7qo$1rd$1@ger.gmane.org>
<4ABBC94C.8010302@v.loewis.de>
<58F8BD41-CBA9-40C6-A1C9-D943D5AC18C8@gmail.com>
<4ABBDC17.80809@v.loewis.de>
<C47DC54A-F000-4E63-97FE-6F7C78A174D9@gmail.com>
<4ABBE07E.50602@v.loewis.de>
Message-ID: <345BA8DC-021E-47F9-8339-D89DAB6005BA@gmail.com>
On Sep 24, 2009, at 5:11 PM, Martin v. L?wis wrote:
>> Sorry, I learned about this change on this mailing list, so I
>> thought it
>> was appropriate to discuss it here. Where is the bug tracker?
>
> It's linked on each PyPI web page, and lives at
>
> https://sourceforge.net/projects/pypi/
> http://sourceforge.net/tracker/?group_id=66150&atid=513503
Please see https://sourceforge.net/tracker/?func=detail&aid=2866081&group_id=66150&atid=513503
From lists at zopyx.com Mon Sep 28 10:57:55 2009
From: lists at zopyx.com (Andreas Jung)
Date: Mon, 28 Sep 2009 10:57:55 +0200
Subject: [Catalog-sig] Uploaded packages not appearing
Message-ID: <4AC07A93.6010109@zopyx.com>
Hi,
I created
http://pypi.python.org/pypi/haufe.zdaemonizer/0.5.6.1
and upload a sdist file.
The files appears in the simple index
http://pypi.python.org/simple/haufe.zdaemonizer/
but it is no visible from the URL above.
Why?
Andreas
--
ZOPYX Ltd. & Co KG \ ZOPYX & Friends
Charlottenstr. 37/1 \ The experts for your Python, Zope and
D-72070 T?bingen \ Plone projects
www.zopyx.com, info at zopyx.com \ www.zopyx.de/friends, friends at zopyx.de
------------------------------------------------------------------------
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: <http://mail.python.org/pipermail/catalog-sig/attachments/20090928/25b426bc/attachment.vcf>
From chris at simplistix.co.uk Wed Sep 30 15:18:28 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 30 Sep 2009 14:18:28 +0100
Subject: [Catalog-sig] Rating feature
In-Reply-To: <4ABBDC17.80809@v.loewis.de>
References: <4AB145CD.900@v.loewis.de>
<h9g7qo$1rd$1@ger.gmane.org> <4ABBC94C.8010302@v.loewis.de> <58F8BD41-CBA9-40C6-A1C9-D943D5AC18C8@gmail.com>
<4ABBDC17.80809@v.loewis.de>
Message-ID: <4AC35AA4.5060509@simplistix.co.uk>
Martin v. L?wis wrote:
>> Can we have a compromise solution that allows a project owner to
>> optionally close comments but leaves the numerical ranking in place?
>
> Not sure what exactly you are asking for; contributions are welcome.
Exactly the same thing I asked for ;-)
I've added links to my comments to Doug's issue in the Tracker.
I also think Ian made some very valid points in his mail. I certainly
appreciate the work required to take the implementation this far, but
I'm with Doug: learning the PyPI implementation will take time, and that
time would be wasted for me if I ended up implementing something that
was then not accepted...
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk