From robertc at robertcollins.net Sun Nov 6 20:21:43 2011 From: robertc at robertcollins.net (Robert Collins) Date: Mon, 7 Nov 2011 08:21:43 +1300 Subject: [Catalog-sig] group maintenance of packages? Message-ID: Hi, over at https://launchpad.net/launchpad-project we've got a group of nearly 20 developers writing and maintaining the various bits of python code involved in developing running and scripting Launchpad. Approximately all of it is open source, and much of that we publish on PyPI. (Some bits are not Python, so not suitable for PyPI :P). We've got a bit of a maintenance issue though: we have to maintain the list of folk that can do releases manually for all of these packages. At the moment we try to make sure there are at least two folk from the team listed on every package, and if/when one of them leaves the team we go around and manually add another person (and remove the person that left the team if they are no longer interested in maintaining stuff). I'm wondering if there is an existing way to reduce that overhead (e.g. there is an API that would let us script a syncronisation with our team list from Launchpad), or whether we need to (or it would be better to) extend PyPI to understand the concept of 'team' or 'group' and let such a team or group be placed in a role. Your thoughts desired :) Cheers, Rob From martin at v.loewis.de Sun Nov 6 22:20:41 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 06 Nov 2011 22:20:41 +0100 Subject: [Catalog-sig] group maintenance of packages? In-Reply-To: References: Message-ID: <4EB6FA29.4060501@v.loewis.de> > I'm wondering if there is an existing way to reduce that overhead > (e.g. there is an API that would let us script a syncronisation with > our team list from Launchpad) There certainly is an API: the role_form URL is fairly stable, and we are fairly committed to keep the forms "fixed". So just write a script that posts to that URL. That said, we may unintentionally break stuff from time to time, if that happens, speak up (and we just introduce a new URL for the new form, or make new fields optional). To figure out the current roles, use the package_roles RPC. > or whether we need to (or it would be > better to) extend PyPI to understand the concept of 'team' or 'group' > and let such a team or group be placed in a role. Not sure how common that request is to justify the effort. If done, I think I'd favor a transitive group membership, similar to Postgres roles (users and groups live in the same space, and logging in transitively logs you into all your groups. A group might have a regular password, if you know the password, you can change group membership). Regards, Martin From ralph.bean at gmail.com Wed Nov 9 19:20:10 2011 From: ralph.bean at gmail.com (Ralph Bean) Date: Wed, 09 Nov 2011 13:20:10 -0500 Subject: [Catalog-sig] Registering http://pypi.rit.edu/ as http://X.pypi.python.org/ Message-ID: <1320862783-sup-9195@grossman.rc.rit.edu> Hello, I have just setup http://pypi.rit.edu and would like to begin the process of reviewing it and registering it as a X.pypi.python.org mirror. I have not yet found any documentation on how to start that process, other than emailing this list. Yours- -Ralph From martin at v.loewis.de Wed Nov 9 21:35:59 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 09 Nov 2011 21:35:59 +0100 Subject: [Catalog-sig] Registering http://pypi.rit.edu/ as http://X.pypi.python.org/ In-Reply-To: <1320862783-sup-9195@grossman.rc.rit.edu> References: <1320862783-sup-9195@grossman.rc.rit.edu> Message-ID: <4EBAE42F.108@v.loewis.de> Am 09.11.2011 19:20, schrieb Ralph Bean: > Hello, > I have just setup http://pypi.rit.edu and would like to begin the process of > reviewing it and registering it as a X.pypi.python.org mirror. > > I have not yet found any documentation on how to start that process, other > than emailing this list. Sending it to this list is fine. Please let me know (best in private) whether this host has a fixed address; I'd rather register that instead of a CNAME. If we can use a fixed IP address, your server will be g.pypi.python.org, and shall then respond to that name as well (otherwise, I'll probably make it e.pypi.python.org). I'll also need an email contact address for this service. If the system has an IPv6 address, let me know that as well. I think I like this process of posting new proposed mirrors to catalog-sig: the community needs to gain trust into the mirror operators (at least into their ability to operate the service; data integrity is provided with cryptographic protection as well). Having the operator introduce themselves (as you did), sounds about right. Regards, Martin From ralph.bean at gmail.com Wed Nov 9 19:07:08 2011 From: ralph.bean at gmail.com (Ralph Bean) Date: Wed, 09 Nov 2011 13:07:08 -0500 Subject: [Catalog-sig] http://pypi.rit.edu Message-ID: <1320861937-sup-7614@grossman.rc.rit.edu> Hello, I have just setup http://pypi.rit.edu and would like to begin the process of reviewing it and registering it as a X.pypi.python.org mirror. I have not yet found any documentation on how to start that process, other than emailing this list. Yours- -Ralph From martin at v.loewis.de Sat Nov 12 18:53:01 2011 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 12 Nov 2011 18:53:01 +0100 Subject: [Catalog-sig] New mirror Message-ID: <4EBEB27D.60406@v.loewis.de> We now have a new PyPI mirror, g.pypi.python.org. It's located in North America (RIT, Rochester, NY, USA), so for those of you living on that continent, it might be the fastest one. Thanks for providing it go to Ralph Bean. Regards, Martin From robertc at robertcollins.net Sun Nov 13 22:06:54 2011 From: robertc at robertcollins.net (Robert Collins) Date: Mon, 14 Nov 2011 10:06:54 +1300 Subject: [Catalog-sig] trove - LGPL v3 not recognised? Message-ID: I tried to publish a package with License :: OSI Approved :: GNU lesser General Public License v3 but its rejected - there is a Library or Lesser category, but no discrimination between v2 and v3 - as v3 is incompatible with v2, I figure users will want to know. Whats the 'right way' of handling this? -Rob From martin at v.loewis.de Sun Nov 13 22:25:16 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 13 Nov 2011 22:25:16 +0100 Subject: [Catalog-sig] trove - LGPL v3 not recognised? In-Reply-To: References: Message-ID: <4EC035BC.2040905@v.loewis.de> Am 13.11.2011 22:06, schrieb Robert Collins: > I tried to publish a package with > License :: OSI Approved :: GNU lesser General Public License v3 > > but its rejected - there is a Library or Lesser category, but no > discrimination between v2 and v3 - as v3 is incompatible with v2, I > figure users will want to know. > > Whats the 'right way' of handling this? You should request a new classifier here; I take your message that you actually do request License :: OSI Approved :: GNU lesser General Public License v3 I'll let this request sit for some time for people to object, and then add this classifier. Remind me if I forget. Regards, Martin From robertc at robertcollins.net Sun Nov 13 22:36:45 2011 From: robertc at robertcollins.net (Robert Collins) Date: Mon, 14 Nov 2011 10:36:45 +1300 Subject: [Catalog-sig] trove - LGPL v3 not recognised? In-Reply-To: <4EC035BC.2040905@v.loewis.de> References: <4EC035BC.2040905@v.loewis.de> Message-ID: On Mon, Nov 14, 2011 at 10:25 AM, "Martin v. L?wis" wrote: > Am 13.11.2011 22:06, schrieb Robert Collins: >> I tried to publish a package with >> License :: OSI Approved :: GNU lesser General Public License v3 >> >> but its rejected - there is a Library or Lesser category, but no >> discrimination between v2 and v3 - as v3 is incompatible with v2, I >> figure users will want to know. >> >> Whats the 'right way' of handling this? > > You should request a new classifier here; I take your message that > you actually do request > > License :: OSI Approved :: GNU lesser General Public License v3 > > I'll let this request sit for some time for people to object, > and then add this classifier. Remind me if I forget. That would be great!. Uhm I made a typo - lower case l should be upper: License :: OSI Approved :: GNU Lesser General Public License v3 Cheers, Rob From a.badger at gmail.com Mon Nov 14 01:37:47 2011 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 13 Nov 2011 16:37:47 -0800 Subject: [Catalog-sig] trove - LGPL v3 not recognised? In-Reply-To: References: <4EC035BC.2040905@v.loewis.de> Message-ID: <20111114003747.GG2861@unaka.lan> On Mon, Nov 14, 2011 at 10:36:45AM +1300, Robert Collins wrote: > On Mon, Nov 14, 2011 at 10:25 AM, "Martin v. L?wis" wrote: > > Am 13.11.2011 22:06, schrieb Robert Collins: > >> I tried to publish a package with > >> License :: OSI Approved :: GNU lesser General Public License v3 > >> > >> but its rejected - there is a Library or Lesser category, but no > >> discrimination between v2 and v3 - as v3 is incompatible with v2, I > >> figure users will want to know. > >> > >> Whats the 'right way' of handling this? > > > > You should request a new classifier here; I take your message that > > you actually do request > > > > License :: OSI Approved :: GNU lesser General Public License v3 > > > > I'll let this request sit for some time for people to object, > > and then add this classifier. Remind me if I forget. > > That would be great!. Uhm I made a typo - lower case l should be upper: > License :: OSI Approved :: GNU Lesser General Public License v3 So actually, the GNU licensing classifiers could do with a bit of a thought. We definitely could use more than we currently have. How many and the wording to use could use a bit of discussion: The GNU licenses all have clauses similar to the following (This particular wording is the one used in the GPLv2): """ Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. """ This has lead to some very common scenarios by code authors and has also lead to some scenarios that are most likely not what the author intended. Common Scenarios ================ I would propose the following classifiers based on the common scenarios I see everyday: License :: OSI Approved :: GNU Lesser General Public License v2 (LGPLv2) License :: OSI Approved :: GNU Lesser General Public License v3 (LGPLv3) License :: OSI Approved :: GNU Lesser General Public License v2 or later (LGPLv2+) License :: OSI Approved :: GNU Lesser General Public License v3 or later (LGPLv3+) License :: OSI Approved :: GNU General Public License v2 (GPLv2) License :: OSI Approved :: GNU General Public License v3 (GPLv3) License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+) License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+) The version 2 and version 3 classifiers are for when the code specifies a specific version. The "or later" variants cover authors who choose to give the users of their code the freedom to choose a later version of the license published by the Free Software Foundation as quoted in the above clause. .. note:: At the moment, people do publish code under the (L)GPLv3 or later but since there is no later version of the (L)GPL it doesn't have any immediate difference from the plain (L)GPLv3 but it could in the future. A GPLv1 but not LGPL did exist at one time but it is specifically used so infrequently (I have never seen software that seemed to intentionally use the GPLv1) that it only affects this analysis in the last section of this message. Usually Unintended Licensing ============================ The last sentence in the license clause I quoted says "If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation." This is often something that people who use (or redistribute) the code notice but an author does not. The author may put a copy of the GPLv2 in their software package and note that their software is "Licensed under the terms of the GPL". The author assumes that using the GPLv2 (or GPLv3) text is sufficient to show that they intend to use that version of the GPL. Because the license specifically states that in this case, the software is under any version of the GPL, the software may actually be used under the terms of the GPLv1, v2, or v3 (at this time). How does this bear upon pypi? If we expect that the author of a piece of code is the one who maintains the pypi listing, then we probably do not need to worry about it too much (unless one of the authors really intends "any version of the GPL" rather than GPLv2 or later). The author will see the available classifiers and make a choice of which version of the license they intend. If we expect that people who are not upstream are making pypi listings on behalf of upstream, then there's a case to be made for having classifiers that represents "GNU General Public License, any version" and "GNU Lesser General Public License, and version" as they should be adding classifiers that reflect the actual license of the code. This case could be covered with the current classifiers as they do not specify any version but see below for the inadequacies of the current classifier in this role. Comparison to Current Classifier ================================ In pypi, we currently have the following license classifiers: License :: OSI Approved :: GNU General Public License (GPL) License :: OSI Approved :: GNU Library or Lesser General Public License (LGPL) These are different than the originally proposed classifier above in two ways -- lack of version specification and the use of the common short form. Common short form is easy to add (as I did in my examples above). The question of whether to add version specifiers to these classifiers is more complex. I think we should add the classifiers for (L)GPLv2 as well as the ones for (L)GPLv3 as those are explicit expressions of the code's licenses. But that doesnt mean that the current classifiers should go away. If they do go away, we'll need to change the classifiers that are currently on packages to something else which will be wrong in some cases (unless we read all.the code that these modules belong to to determine what the classifier needs to be). If they don't go away, module authors will be able to continue to upload new modules with these classifiers. This is undesirable because the classification does not give enough information to consumers of the code to tell if there will be license conflicts in their projects. (example: If I'm writing Apache licensed software, I need to know whether the module I'm thinking of using is GPLv2 or GPLv3 as version 3 is compatible but version 2 is not. If I'm writing GPLv3 code I need to know if the code is licensed GPLv2. GPLv2+, or GPLv3 as the two versions are incompatible with each other). This is no worse than the current case -- it would just be nice to be able to deprecate the unversioned classifiers in some way. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From martin at v.loewis.de Mon Nov 14 08:44:00 2011 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 14 Nov 2011 08:44:00 +0100 Subject: [Catalog-sig] trove - LGPL v3 not recognised? In-Reply-To: <20111114003747.GG2861@unaka.lan> References: <4EC035BC.2040905@v.loewis.de> <20111114003747.GG2861@unaka.lan> Message-ID: <4EC0C6C0.4080107@v.loewis.de> > In pypi, we currently have the following license classifiers: > > License :: OSI Approved :: GNU General Public License (GPL) > License :: OSI Approved :: GNU Library or Lesser General Public License (LGPL) > > These are different than the originally proposed classifier above in two > ways -- lack of version specification and the use of the common short form. > Common short form is easy to add (as I did in my examples above). What's the "common short form"? If it's the abbreviation (i.e. "GPL"), they already have it, no? > The question of whether to add version specifiers to these classifiers is > more complex. I think we should add the classifiers for (L)GPLv2 as well as > the ones for (L)GPLv3 as those are explicit expressions of the code's > licenses. Fine with me. > But that doesnt mean that the current classifiers should go away. Most certainly not. Once a classifier has been added, it can *never* go away. That's why I ask people really think carefully whether they really need a classifier, in exactly that spelling, before it's added. > If they don't go away, module authors will be able to continue to upload new > modules with these classifiers. This is undesirable because the > classification does not give enough information to consumers of the code to > tell if there will be license conflicts in their projects. I don't see that as a problem. Hopefully, the code itself gives enough information. So if people can't know for sure, and if they need to know (which they often don't), they need to check the source. The trove classifier shouldn't be considered legally binding. People like you (i.e. distribution packagers) can start going around and ask authors to update their classifiers. Over time, all current packages would use the correct classifiers. Regards, Martin From ralph.bean at gmail.com Mon Nov 14 14:53:03 2011 From: ralph.bean at gmail.com (Ralph Bean) Date: Mon, 14 Nov 2011 08:53:03 -0500 Subject: [Catalog-sig] New mirror In-Reply-To: <4EBEB27D.60406@v.loewis.de> References: <4EBEB27D.60406@v.loewis.de> Message-ID: <1321278382-sup-1625@grossman.rc.rit.edu> There's one small problem, if you went to http://last.pypi.python.org/ it actually redirected you http://mirror.rit.edu/ (our linux mirror) instead of http://g.pypi.python.org/ -- fixed that just now! Just so everyone knows, the box that hosts g.pypi.python.org also hosts our linux mirrors and is the highest-traffic service at RIT. There's a neat webapp I wrote (in python) that visualizes server traffic in "real time" (using COMET+orbited+moksha+turbogears2). You can see it here at http://narcissus.rc.rit.edu Cheers- -Ralph From a.badger at gmail.com Mon Nov 14 20:40:55 2011 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 14 Nov 2011 11:40:55 -0800 Subject: [Catalog-sig] trove - LGPL v3 not recognised? In-Reply-To: <4EC0C6C0.4080107@v.loewis.de> References: <4EC035BC.2040905@v.loewis.de> <20111114003747.GG2861@unaka.lan> <4EC0C6C0.4080107@v.loewis.de> Message-ID: <20111114194055.GI2861@unaka.lan> On Mon, Nov 14, 2011 at 08:44:00AM +0100, "Martin v. L?wis" wrote: > > In pypi, we currently have the following license classifiers: > > > > License :: OSI Approved :: GNU General Public License (GPL) > > License :: OSI Approved :: GNU Library or Lesser General Public License (LGPL) > > > > These are different than the originally proposed classifier above in two > > ways -- lack of version specification and the use of the common short form. > > Common short form is easy to add (as I did in my examples above). > > What's the "common short form"? If it's the abbreviation (i.e. "GPL"), > they already have it, no? > I was referring to Robert Collins's proposed:: License :: OSI Approved :: GNU Lesser General Public License v3 Instead, I proposed it include the short form like the current GPL licenses: License :: OSI Approved :: GNU Lesser General Public License v3 (LGPLv3) > > But that doesnt mean that the current classifiers should go away. > > Most certainly not. Once a classifier has been added, it can *never* go > away. That's why I ask people really think carefully whether they > really need a classifier, in exactly that spelling, before it's added. > Fully understood. I wanted to be explicit about the pros and cons of each strategy (and agree that keeping classifiers forever seems better). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From martin at v.loewis.de Mon Nov 14 22:08:30 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 14 Nov 2011 22:08:30 +0100 Subject: [Catalog-sig] New mirror In-Reply-To: <1321278382-sup-1625@grossman.rc.rit.edu> References: <4EBEB27D.60406@v.loewis.de> <1321278382-sup-1625@grossman.rc.rit.edu> Message-ID: <4EC1834E.2090002@v.loewis.de> Am 14.11.2011 14:53, schrieb Ralph Bean: > There's one small problem, if you went to http://last.pypi.python.org/ it > actually redirected you http://mirror.rit.edu/ (our linux mirror) instead of > http://g.pypi.python.org/ -- fixed that just now! Thanks! This shouldn't have caused problems, since last should have been used only to find out which the last mirror is, without actually accessing it. But having it work anyway is certainly better. Regards, Martin From tjreedy at udel.edu Tue Nov 15 02:06:12 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 14 Nov 2011 20:06:12 -0500 Subject: [Catalog-sig] trove - LGPL v3 not recognised? In-Reply-To: <20111114003747.GG2861@unaka.lan> References: <4EC035BC.2040905@v.loewis.de> <20111114003747.GG2861@unaka.lan> Message-ID: On 11/13/2011 7:37 PM, Toshio Kuratomi wrote: > I would propose the following classifiers based on the common scenarios > I see everyday: > > License :: OSI Approved :: GNU Lesser General Public License v2 (LGPLv2) > License :: OSI Approved :: GNU Lesser General Public License v3 (LGPLv3) > License :: OSI Approved :: GNU Lesser General Public License v2 or later (LGPLv2+) > License :: OSI Approved :: GNU Lesser General Public License v3 or later (LGPLv3+) > License :: OSI Approved :: GNU General Public License v2 (GPLv2) > License :: OSI Approved :: GNU General Public License v3 (GPLv3) > License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+) > License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+) Is the classifier depth limited to 3, or can we do instead add optional fourth level classifiers :: v2, :: v2 or later, :: v3, and :: v3 or later to the current three level classifiers. License :: OSI Approved :: GNU General Public License (GPL) License :: OSI Approved :: GNU Library or Lesser General Public License (LGPL) I am presuming that one can now search for 'OSI Approved', in which case this alternative would make it possible to search for GPL or LGPL without the fourth specifier. -- Terry Jan Reedy From a.badger at gmail.com Tue Nov 15 02:28:28 2011 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 14 Nov 2011 17:28:28 -0800 Subject: [Catalog-sig] trove - LGPL v3 not recognised? In-Reply-To: References: <4EC035BC.2040905@v.loewis.de> <20111114003747.GG2861@unaka.lan> Message-ID: <20111115012828.GK2861@unaka.lan> On Mon, Nov 14, 2011 at 08:06:12PM -0500, Terry Reedy wrote: > On 11/13/2011 7:37 PM, Toshio Kuratomi wrote: > > >I would propose the following classifiers based on the common scenarios > >I see everyday: > > > >License :: OSI Approved :: GNU Lesser General Public License v2 (LGPLv2) > >License :: OSI Approved :: GNU Lesser General Public License v3 (LGPLv3) > >License :: OSI Approved :: GNU Lesser General Public License v2 or later (LGPLv2+) > >License :: OSI Approved :: GNU Lesser General Public License v3 or later (LGPLv3+) > >License :: OSI Approved :: GNU General Public License v2 (GPLv2) > >License :: OSI Approved :: GNU General Public License v3 (GPLv3) > >License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+) > >License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+) > > Is the classifier depth limited to 3, or can we do instead add > optional fourth level classifiers :: v2, :: v2 or later, :: v3, and > :: v3 or later to the current three level classifiers. > License :: OSI Approved :: GNU General Public License (GPL) > License :: OSI Approved :: GNU Library or Lesser General Public > License (LGPL) > > I am presuming that one can now search for 'OSI Approved', in which > case this alternative would make it possible to search for GPL or > LGPL without the fourth specifier. > I don't know about the technical possibility but I did consider proposing something along those lines instead of expanding the third level. The reasons I didn't were: 1) The other licenses which have versions attached to them do not place the version into a fourth level 2) The utility of searching like that is limited. If I'm searching for particular licenses, it's typically because I need to know whether the license is compatible with some other license. The GPL v2 and versoin 3 licenses are not compatible with each other. GPLv2+ would be compatible with both. GPLv3+, once again would not. With this in mind, it seemed like code which used the trove license categories would need to operate on each license+version independently, even if we grouped them that way in the categorization scheme. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From martin at v.loewis.de Tue Nov 15 07:38:42 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 15 Nov 2011 07:38:42 +0100 Subject: [Catalog-sig] trove - LGPL v3 not recognised? In-Reply-To: References: <4EC035BC.2040905@v.loewis.de> <20111114003747.GG2861@unaka.lan> Message-ID: <4EC208F2.1040109@v.loewis.de> > Is the classifier depth limited to 3, or can we do instead add optional > fourth level classifiers :: v2, :: v2 or later, :: v3, and :: v3 or > later to the current three level classifiers. The current implementation supports 5 levels, the longest classifiers are like Topic :: System :: Networking :: Monitoring :: Hardware Watchdog Topic :: System :: Systems Administration :: Authentication/Directory :: NIS Topic :: Multimedia :: Graphics :: Capture :: Digital Camera Topic :: Desktop Environment :: Window Managers :: Enlightenment :: Epplets Topic :: Desktop Environment :: Window Managers :: Sawfish :: Themes 0.30 Topic :: Desktop Environment :: Window Managers :: Sawfish :: Themes pre-0.30 So using versions as a sublevel would be entirely appropriate; the top-level classifier is then understood as leaving the sublevel "unspecified". Regards, Martin From martin at v.loewis.de Tue Nov 15 07:46:54 2011 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 15 Nov 2011 07:46:54 +0100 Subject: [Catalog-sig] trove - LGPL v3 not recognised? In-Reply-To: <20111115012828.GK2861@unaka.lan> References: <4EC035BC.2040905@v.loewis.de> <20111114003747.GG2861@unaka.lan> <20111115012828.GK2861@unaka.lan> Message-ID: <4EC20ADE.80500@v.loewis.de> > 1) The other licenses which have versions attached to them do not place the > version into a fourth level That's probably because nobody thought of it. > 2) The utility of searching like that is limited. Why do you say that? You have full search capabilities either way. In fact, sub-classifiers improve the search capabilities. > If I'm searching for > particular licenses, it's typically because I need to know whether the > license is compatible with some other license. I'm not really sure what the common case for searching for a license is. One reason might also be that people want to know what the most popular licenses are, and would there want to aggregate GPL (any version). But let's assume that people actually search for licenses to find software that is compatible with their needs (whether that is their license, their company policies, or their personal preferences). > The GPL v2 and versoin 3 licenses are not compatible with each other. Then you search for either one by subclassifier (as you would for a flat classification). However, there are also cases where the license in question is compatible with both GPL versions, so you would want to search for GPL "any version". > With this in mind, it seemed like code which used the trove license > categories would need to operate on each license+version independently, > even if we grouped them that way in the categorization scheme. In the use cases you cited. I think there are also use cases where you would want to entire supercategory. Regards, Martin From a.badger at gmail.com Tue Nov 15 23:28:50 2011 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 15 Nov 2011 14:28:50 -0800 Subject: [Catalog-sig] trove - LGPL v3 not recognised? In-Reply-To: <4EC20ADE.80500@v.loewis.de> References: <4EC035BC.2040905@v.loewis.de> <20111114003747.GG2861@unaka.lan> <20111115012828.GK2861@unaka.lan> <4EC20ADE.80500@v.loewis.de> Message-ID: <20111115222849.GN2861@unaka.lan> On Tue, Nov 15, 2011 at 07:46:54AM +0100, "Martin v. L?wis" wrote: > > 1) The other licenses which have versions attached to them do not place the > > version into a fourth level > > That's probably because nobody thought of it. > But consistency in the classifiers is a nice thing. If your goal as a consumer of the data is really trying to isolate the version from the rest of the license name, for instance, you already have to parse the version off the end of some strings. Making new classifiers that use another level for a version means you have to maintain parsing of the version as a separate field as an additional case. Note that one of those other licenses is a GNU license: License :: OSI Approved :: GNU Affero General Public License v3 > > 2) The utility of searching like that is limited. > > Why do you say that? You have full search capabilities either way. In > fact, sub-classifiers improve the search capabilities. > I say this because in this case the different versions are simply ways of naming different licenses. The licenses have different terms and conditions and in and of themselves are not even compatible. The value of categorizing the GPLv2 and GPLv3 license together is rather slim. The value of categorizing the MIT and new BSD licenses together would be higher than the value of categorizing the GPLv2 and GPLv3 licenses together. Wishing to categorize the GPLv2 and GPLv3 together is only a superficial goal based on the fact that they share the common substring "GNU General Public License" in their name. > > If I'm searching for > > particular licenses, it's typically because I need to know whether the > > license is compatible with some other license. > > I'm not really sure what the common case for searching for a license is. > One reason might also be that people want to know what the most popular > licenses are, and would there want to aggregate GPL (any version). > Commonly people would not want to aggregate the GPL licenses here because the GPL licenses are incompatible with each other and have different terms and conditions. If you want to know about popular licenses, you would want to keep the GPLv2 and GPLv3 licenses separate in your count. Or put another way, if you are counting the GPLv2 and GPLv3 together, you likely aren't really looking for a count of popular licenses. You're likely looking for a count of types of licenses. These are some of the ways that people might like to categorize licenses: * Copyleft, non-copyleft, proprietary * GPLv2-compatible, GPLv3-compatible, non-GPL compatible open source, proprietary * Backed by a legal team, analyzed by a legal team, not rigorously analyzed These are somewhat helped by having the version separated but they all have issues as separating the version portion of the license name from the rest is only an imperfect match for what you really want. In the end, you have to maintain lists of licenses that meet your categorizing criteria. Having the version as a separate field doesn't help as the textual portion of the license name and the version portion have to be considered together to determine which terms and condions need to be evaluated in your context. The only thing that the raw name without version really brings to the table is brand identification. Here's a different example of this -- Let's say we were designing categories for people who might want to classify software by which programming language they were written in. Would we want to group perl, python, and php together because someone might want to search out popularity of languages according to which begin with "p"? Do we want to group Visual Basic and C# together because both originated with Microsoft? These groupings may fit with what someone wants to accomplish but they're superficial groupings based on things that have nothing to do with what the subject matter is actually about. Similarly, grouping the licenses based on the existence of a common substring in the name is basing it on a superficial characteristic of the license. Instead, determine which attributes of the license are important and you want to optimize for then optimize for that. > But let's assume that people actually search for licenses to find > software that is compatible with their needs (whether that is their > license, their company policies, or their personal preferences). > > > The GPL v2 and versoin 3 licenses are not compatible with each other. > > Then you search for either one by subclassifier (as you would for > a flat classification). However, there are also cases where the > license in question is compatible with both GPL versions, so you would > want to search for GPL "any version". > This is lawyerly-debatable. Since the GPLv2 and GPLv3 are incompatible and since they are strong copylefts, the FSF's position has been that you cannot license code in such a way that it can use both GPLv2 and GPLv3 licensed code. This has not been tested in court yet so lawyers continue to debate the validity of this and the applicability in different situations (for instance, is dynamic linkage different from shared? Are scripting languages different than compiled?) but anyone who doesn't want to risk having to go to court over this needs to keep it in mind. > > With this in mind, it seemed like code which used the trove license > > categories would need to operate on each license+version independently, > > even if we grouped them that way in the categorization scheme. > > In the use cases you cited. I think there are also use cases where you > would want to entire supercategory. > I could see *other* supercategories which could be of benefit but I don't see that there is a case to be made for this particular separation. A license's version is a part of its name as the terms and conditions between versions can change dramatically (and in the case of GPLv2 and GPLv3, LGPLv2 and LGPLv3; they did). Here's some examples of other supercategories that could be considered: ::FSF :: GNU General Public License v3 :: Apache :: Apache Software License v2 This scheme would highlight the body that created a license. Not all licenses have a traceable or well known originator, though. But for the ones that do, this helps to answer the question of what legal team created it or stands behind it/can explain the intent when it was drafed. :: GNU Lesser General Public License v2 (LGPLv2) :: 2.0 :: GNU Lesser General Public License v2 (LGPLv2) :: 2.1 :: GNU Lesser General Public License v3 (LGPLv3) :: 3.0 This scheme would highlight when minor changes are made vs incompatible changes. This particular example is problematic, however, because the particular change incorporated between v2.0 and v2.1 was a rename. The 2.0 version is actually the GNU Library General Public License. The concept is problematic as deciding what's an incompatible change and what isn't is debatable. In the GPL context, version 2 and version 3 are incompatible with each other so it's clear that they are different licenses. On the other hand, you have licenses like Old BSD (aka BSD with advertising) versus the New BSD license. The two are compatible with each other and the common name for each is the same but externally, the new BSD license is compatible with the GPL while the old one is not which is a major difference. Talking about supercategories for licenses, though, points me in the direction that really we're talking about wanting to add attributes to describe the license itself, not attributes to describe the software. That seems out of scope for the trove categories being used on pypi. (pypi already sorta does this with the OSI Approved supercategory marking the licenses as open source... but I'm wondering if that wasn't a mistake. After all, the FSF maintains a similar list of licenses and the two lists are not super/subsets of each other.) Limiting it to the license name (of which the version is a part as the version + textual portion of the name together reference the set of terms and conditions which make up the license) might be better. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From fuzzyman at gmail.com Tue Nov 15 23:53:44 2011 From: fuzzyman at gmail.com (Michael Foord) Date: Tue, 15 Nov 2011 22:53:44 +0000 Subject: [Catalog-sig] PyPI trove classifiers for alternate language implementations In-Reply-To: References: <4E70AA85.6090700@v.loewis.de> <4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com> <4E7287CA.6070900@egenix.com> Message-ID: Whilst we're considering new classifiers - any word on this one? Michael On 16 October 2011 16:06, Michael Foord wrote: > > > On 16 September 2011 00:18, M.-A. Lemburg wrote: > >> Michael Foord wrote: >> > On 15 September 2011 15:24, M.-A. Lemburg wrote: >> > >> >> "Martin v. L?wis" wrote: >> >>> >> >>>> Programming Language - Python - Implementation - CPython >> >>>> Programming Language - Python - Implementation - pypy >> >>>> Programming Language - Python - Implementation - jython >> >>>> Programming Language - Python - Implementation - IronPython >> >>> >> >>> Opinions on this proposal? (including the specific spelling, >> >>> leaving alone that the separator is ::, not -) >> >> >> >> Better user CPython, PyPy and Jython for consistency with the >> >> other Trove spellings. >> >> >> >> I'm -0 on the "Implementation" part. Do we really need this ? >> >> >> > >> > >> > Jython, PyPy and CPython are not "programming languages" they're >> > implementations of the Python programming language - so I would prefer >> to >> > differentiate like this. >> >> Well, yes, but if you look at the OS section of the Trove list >> you also find different implementations of BSD under the >> BSD category: >> >> Operating System :: POSIX :: BSD >> Operating System :: POSIX :: BSD :: BSD/OS >> Operating System :: POSIX :: BSD :: FreeBSD >> Operating System :: POSIX :: BSD :: NetBSD >> Operating System :: POSIX :: BSD :: OpenBSD >> >> > Well, they're BSD variants whereas pypy (and other implementations) aim > very much not to be variants. I'd still rather see them listed under a > Python implementation sub-classifier but it isn't a big deal. > > >> (just to take one exmaple) >> >> See http://pypi.python.org/pypi?%3Aaction=list_classifiers for the full >> list. >> >> Also note that Cython is listed as: >> >> Programming Language :: Cython >> >> > That's correct. Cython is a programming language not an implementation. I > would include Shedskin as a programming language rather than an > implementation too. Listing implementations as programming languages loses > the ability to make this distinction at the classifier level (and is also > *incorrect* to my mind). > > > >> even Zope is listed as programming language: >> >> Programming Language :: Zope >> > > > That's odd. :-) > > > >> >> so there isn't all that much consistency in the naming. >> >> BTW: Stackless is missing from your list. >> >> > > Right. Stackless should probably be on the list as libraries may depend on > Stackless features. > > All the best, > > Michael > > > >> >> Also: What about release versions of those implementations ? >> >> >> >> >> > We could always add those later if anyone really wanted them (for >> Python we >> > have the broad "Python" *plus* version specific categories). In other >> words, >> > YAGNI (for now). >> > >> > Michael >> > >> > >> >> Jython and IronPython appear to follow the CPython release >> >> versions, but PyPy uses its own version scheme. >> >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Source (#1, Sep 16 2011) >> >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >> >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >> >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >> ________________________________________________________________________ >> 2011-10-04: PyCon DE 2011, Leipzig, Germany 18 days to go >> >> ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: >> >> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> Registered at Amtsgericht Duesseldorf: HRB 46611 >> http://www.egenix.com/company/contact/ >> > > > > -- > > http://www.voidspace.org.uk/ > > May you do good and not evil > May you find forgiveness for yourself and forgive others > > May you share freely, never taking more than you give. > -- the sqlite blessing http://www.sqlite.org/different.html > > > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From aclark at aclark.net Thu Nov 17 21:57:59 2011 From: aclark at aclark.net (Alex Clark) Date: Thu, 17 Nov 2011 15:57:59 -0500 Subject: [Catalog-sig] New classifiers for Plone Message-ID: Hi all, There has been a discussion on distutils recently re: new trove classifiers for Plone. We have settled on asking for the following new trove classifiers to be added: Framework :: Plone :: 3.3 Framework :: Plone :: 4.0 Framework :: Plone :: 4.1 Framework :: Plone :: 4.2 Framework :: Plone :: 4.3 We will then encourage our add-on developers to use them in their add-ons, and implement new search functionality on http://plone.org/products accordingly. Any objections? If not, please feel free to add these at your earliest convenience. Thanks, Alex --- Alex Clark ? http://aclark.net From merwok at netwok.org Fri Nov 18 09:26:10 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Fri, 18 Nov 2011 09:26:10 +0100 Subject: [Catalog-sig] PyPI trove classifiers for alternate language implementations In-Reply-To: References: <4E70AA85.6090700@v.loewis.de> <4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com> <4E7287CA.6070900@egenix.com> Message-ID: <4EC616A2.70809@netwok.org> Hi, Le 15/11/2011 23:53, Michael Foord a ?crit : > Whilst we're considering new classifiers - any word on this one? Sorry, which one? It?s hard to tell what the proposal is from the tangled top-posted quotes. Regards From martin at v.loewis.de Fri Nov 18 09:31:18 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 18 Nov 2011 09:31:18 +0100 Subject: [Catalog-sig] PyPI trove classifiers for alternate language implementations In-Reply-To: References: <4E70AA85.6090700@v.loewis.de> <4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com> <4E7287CA.6070900@egenix.com> Message-ID: <4EC617D6.10304@v.loewis.de> Am 15.11.2011 23:53, schrieb Michael Foord: > Whilst we're considering new classifiers - any word on this one? I lost track: what't the proposal, and what's the consensus? Regards, Martin From fuzzyman at gmail.com Fri Nov 18 12:57:38 2011 From: fuzzyman at gmail.com (Michael Foord) Date: Fri, 18 Nov 2011 11:57:38 +0000 Subject: [Catalog-sig] PyPI trove classifiers for alternate language implementations In-Reply-To: <4EC617D6.10304@v.loewis.de> References: <4E70AA85.6090700@v.loewis.de> <4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com> <4E7287CA.6070900@egenix.com> <4EC617D6.10304@v.loewis.de> Message-ID: On 18 November 2011 08:31, "Martin v. L?wis" wrote: > Am 15.11.2011 23:53, schrieb Michael Foord: > > Whilst we're considering new classifiers - any word on this one? > > I lost track: what't the proposal, and what's the consensus? > > Programming Language :: Python :: Implementation :: CPython Programming Language :: Python :: Implementation :: PyPy Programming Language :: Python :: Implementation :: Jython Programming Language :: Python :: Implementation :: IronPython Programming Language :: Python :: Implementation :: Stackless There seemed to be agreement that classifiers for the different implementations was useful. M-A Lemburg suggested adding versions *as well*. Jean-Paul Calderone and I thought it was unnecessary as Jython and IronPython are now using CPython version numbers and different versions of all the implementations tend to target a specific Python language version - for which we already have classifiers. M-A Lemburg disliked the the "Implementation" part of the classifier (he was only -0 on it though). I think it is useful/necessary to have it to disambiguate these implementations from other Python-like-languages (like Cython and Shedskin) that can be used to write Python extensions. (As a matter of correctness all of these implementations provide "the Python programming language" and strive very hard indeed not to be distinct programming languages...) Nobody else weighed in on that particular topic. All the best, Michael Foord > Regards, > Martin > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at gmail.com Fri Nov 18 12:58:24 2011 From: fuzzyman at gmail.com (Michael Foord) Date: Fri, 18 Nov 2011 11:58:24 +0000 Subject: [Catalog-sig] PyPI trove classifiers for alternate language implementations In-Reply-To: <4EC616A2.70809@netwok.org> References: <4E70AA85.6090700@v.loewis.de> <4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com> <4E7287CA.6070900@egenix.com> <4EC616A2.70809@netwok.org> Message-ID: On 18 November 2011 08:26, ?ric Araujo wrote: > Hi, > > Le 15/11/2011 23:53, Michael Foord a ?crit : > > Whilst we're considering new classifiers - any word on this one? > > Sorry, which one? It?s hard to tell what the proposal is from the > tangled top-posted quotes. > > You trimmed so much from your response it's impossible for me to see which bits you may have had problems understanding. So I can't help sorry. Michael > Regards > _______________________________________________ > Catalog-SIG mailing list > Catalog-SIG at python.org > http://mail.python.org/mailman/listinfo/catalog-sig > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From mal at egenix.com Fri Nov 18 14:23:06 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 18 Nov 2011 14:23:06 +0100 Subject: [Catalog-sig] New classifiers for Plone In-Reply-To: References: Message-ID: <4EC65C3A.70403@egenix.com> Alex Clark wrote: > Hi all, > > There has been a discussion on distutils recently re: new trove classifiers for Plone. We have > settled on asking for the following new trove classifiers to be added: > > > Framework :: Plone :: 3.3 > Framework :: Plone :: 4.0 > Framework :: Plone :: 4.1 > Framework :: Plone :: 4.2 > Framework :: Plone :: 4.3 > > We will then encourage our add-on developers to use them in their add-ons, and implement new search > functionality on http://plone.org/products accordingly. > > Any objections? If not, please feel free to add these at your earliest convenience. You should also include: Framework :: Plone Framework :: Plone :: 3 Framework :: Plone :: 4 to make the set complete. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 18 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From aclark at aclark.net Fri Nov 18 16:38:17 2011 From: aclark at aclark.net (Alex Clark) Date: Fri, 18 Nov 2011 10:38:17 -0500 Subject: [Catalog-sig] New classifiers for Plone In-Reply-To: <4EC65C3A.70403@egenix.com> References: <4EC65C3A.70403@egenix.com> Message-ID: Hi, On 11/18/11 8:23 AM, M.-A. Lemburg wrote: > Alex Clark wrote: >> Hi all, >> >> There has been a discussion on distutils recently re: new trove classifiers for Plone. We have >> settled on asking for the following new trove classifiers to be added: >> >> >> Framework :: Plone :: 3.3 >> Framework :: Plone :: 4.0 >> Framework :: Plone :: 4.1 >> Framework :: Plone :: 4.2 >> Framework :: Plone :: 4.3 >> >> We will then encourage our add-on developers to use them in their add-ons, and implement new search >> functionality on http://plone.org/products accordingly. >> >> Any objections? If not, please feel free to add these at your earliest convenience. > > You should also include: > > Framework :: Plone > Framework :: Plone :: 3 > Framework :: Plone :: 4 > > to make the set complete. We actually don't want those, unless you want to use 4 instead of 4.0. Using 3 (or 3.0) does not help us, as we don't intend to classify add-ons for releases prior to egg-based Plone releases (starting at 3.2). We also discussed keeping the list as small as possible on the other thread. Alex > From mal at egenix.com Fri Nov 18 17:17:29 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 18 Nov 2011 17:17:29 +0100 Subject: [Catalog-sig] New classifiers for Plone In-Reply-To: References: <4EC65C3A.70403@egenix.com> Message-ID: <4EC68519.2080701@egenix.com> Alex Clark wrote: > Hi, > > On 11/18/11 8:23 AM, M.-A. Lemburg wrote: >> Alex Clark wrote: >>> Hi all, >>> >>> There has been a discussion on distutils recently re: new trove classifiers for Plone. We have >>> settled on asking for the following new trove classifiers to be added: >>> >>> >>> Framework :: Plone :: 3.3 >>> Framework :: Plone :: 4.0 >>> Framework :: Plone :: 4.1 >>> Framework :: Plone :: 4.2 >>> Framework :: Plone :: 4.3 >>> >>> We will then encourage our add-on developers to use them in their add-ons, and implement new search >>> functionality on http://plone.org/products accordingly. >>> >>> Any objections? If not, please feel free to add these at your earliest convenience. >> >> You should also include: >> >> Framework :: Plone >> Framework :: Plone :: 3 >> Framework :: Plone :: 4 >> >> to make the set complete. > > > We actually don't want those, unless you want to use 4 instead of 4.0. Using 3 (or 3.0) does not > help us, as we don't intend to classify add-ons for releases prior to egg-based Plone releases > (starting at 3.2). Well, you don't, but users may want to browser PyPI and other similar indexes based on products for Plone, Plone 3 and Plone 4. The reasoning behind using major release classifiers is that package authors may now want to update the classifiers for their packages every time you issue a new release (by making a new release of the package). The unqualified category is needed for consistency with the other parent categories in the trove index. > We also discussed keeping the list as small as possible on the other thread. The above just follows the same schema as used for Python itself: Programming Language :: Python Programming Language :: Python :: 2 Programming Language :: Python :: 2.3 Programming Language :: Python :: 2.4 Programming Language :: Python :: 2.5 Programming Language :: Python :: 2.6 Programming Language :: Python :: 2.7 Programming Language :: Python :: 3 Programming Language :: Python :: 3.0 Programming Language :: Python :: 3.1 Programming Language :: Python :: 3.2 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 18 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From aclark at aclark.net Fri Nov 18 17:33:11 2011 From: aclark at aclark.net (Alex Clark) Date: Fri, 18 Nov 2011 11:33:11 -0500 Subject: [Catalog-sig] New classifiers for Plone In-Reply-To: <4EC68519.2080701@egenix.com> References: <4EC65C3A.70403@egenix.com> <4EC68519.2080701@egenix.com> Message-ID: Hi On 11/18/11 11:17 AM, M.-A. Lemburg wrote: > Alex Clark wrote: >> Hi, >> >> On 11/18/11 8:23 AM, M.-A. Lemburg wrote: >>> Alex Clark wrote: >>>> Hi all, >>>> >>>> There has been a discussion on distutils recently re: new trove classifiers for Plone. We have >>>> settled on asking for the following new trove classifiers to be added: >>>> >>>> >>>> Framework :: Plone :: 3.3 >>>> Framework :: Plone :: 4.0 >>>> Framework :: Plone :: 4.1 >>>> Framework :: Plone :: 4.2 >>>> Framework :: Plone :: 4.3 >>>> >>>> We will then encourage our add-on developers to use them in their add-ons, and implement new search >>>> functionality on http://plone.org/products accordingly. >>>> >>>> Any objections? If not, please feel free to add these at your earliest convenience. >>> >>> You should also include: >>> >>> Framework :: Plone >>> Framework :: Plone :: 3 >>> Framework :: Plone :: 4 >>> >>> to make the set complete. >> >> >> We actually don't want those, unless you want to use 4 instead of 4.0. Using 3 (or 3.0) does not >> help us, as we don't intend to classify add-ons for releases prior to egg-based Plone releases >> (starting at 3.2). > > Well, you don't, but users may want to browser PyPI and other similar > indexes based on products for Plone, Plone 3 and Plone 4. > > The reasoning behind using major release classifiers is that package > authors may now want to update the classifiers for their packages > every time you issue a new release (by making a new release of the > package). > > The unqualified category is needed for consistency with the other parent > categories in the trove index. > >> We also discussed keeping the list as small as possible on the other thread. > > The above just follows the same schema as used for Python itself: > > Programming Language :: Python > Programming Language :: Python :: 2 > Programming Language :: Python :: 2.3 > Programming Language :: Python :: 2.4 > Programming Language :: Python :: 2.5 > Programming Language :: Python :: 2.6 > Programming Language :: Python :: 2.7 > Programming Language :: Python :: 3 > Programming Language :: Python :: 3.0 > Programming Language :: Python :: 3.1 > Programming Language :: Python :: 3.2 OK I'm fine with this, then. So to reiterate, we are asking for (I forgot 3.2 in the previous list): Framework :: Plone :: 3 Framework :: Plone :: 3.2 Framework :: Plone :: 3.3 Framework :: Plone :: 4 Framework :: Plone :: 4.0 Framework :: Plone :: 4.1 Framework :: Plone :: 4.2 Framework :: Plone :: 4.3 Alex > From ziade.tarek at gmail.com Fri Nov 18 20:47:07 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Fri, 18 Nov 2011 11:47:07 -0800 Subject: [Catalog-sig] New classifiers for Plone In-Reply-To: <4EC68519.2080701@egenix.com> References: <4EC65C3A.70403@egenix.com> <4EC68519.2080701@egenix.com> Message-ID: On Fri, Nov 18, 2011 at 8:17 AM, M.-A. Lemburg wrote: > Alex Clark wrote: >> Hi, >> >> On 11/18/11 8:23 AM, M.-A. Lemburg wrote: >>> Alex Clark wrote: >>>> Hi all, >>>> >>>> There has been a discussion on distutils recently re: new trove classifiers for Plone. We have >>>> settled on asking for the following new trove classifiers to be added: >>>> >>>> >>>> ? ? Framework :: Plone :: 3.3 >>>> ? ? Framework :: Plone :: 4.0 >>>> ? ? Framework :: Plone :: 4.1 >>>> ? ? Framework :: Plone :: 4.2 >>>> ? ? Framework :: Plone :: 4.3 >>>> >>>> We will then encourage our add-on developers to use them in their add-ons, and implement new search >>>> functionality on http://plone.org/products accordingly. >>>> >>>> Any objections? If not, please feel free to add these at your earliest convenience. >>> >>> You should also include: >>> >>> Framework :: Plone >>> Framework :: Plone :: 3 >>> Framework :: Plone :: 4 >>> >>> to make the set complete. >> >> >> We actually don't want those, unless you want to use 4 instead of 4.0. Using 3 (or 3.0) does not >> help us, as we don't intend to classify add-ons for releases prior to egg-based Plone releases >> (starting at 3.2). > > Well, you don't, but users may want to browser PyPI and other similar > indexes based on products for Plone, Plone 3 and Plone 4. > > The reasoning behind using major release classifiers is that package > authors may now want to update the classifiers for their packages > every time you issue a new release (by making a new release of the > package). > > The unqualified category is needed for consistency with the other parent > categories in the trove index. > >> We also discussed keeping the list as small as possible on the other thread. > > The above just follows the same schema as used for Python itself: I understand the need for Python itself, but for Plone or , does that make sense to add/maintain in the Trove the framework versions ? that's an endless list to maintain, and it makes me think that maybe we should allow *custom* trove classifiers, so people can extend that list without having to ask additions in the main trove list all the time Cheers Tarek > Programming Language :: Python > Programming Language :: Python :: 2 > Programming Language :: Python :: 2.3 > Programming Language :: Python :: 2.4 > Programming Language :: Python :: 2.5 > Programming Language :: Python :: 2.6 > Programming Language :: Python :: 2.7 > Programming Language :: Python :: 3 > Programming Language :: Python :: 3.0 > Programming Language :: Python :: 3.1 > Programming Language :: Python :: 3.2 > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source ?(#1, Nov 18 2011) >>>> Python/Zope Consulting and Support ... ? ? ? ?http://www.egenix.com/ >>>> mxODBC.Zope.Database.Adapter ... ? ? ? ? ? ? http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... ? ? ? ?http://python.egenix.com/ > ________________________________________________________________________ > > ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: > > > ? eGenix.com Software, Skills and Services GmbH ?Pastor-Loeh-Str.48 > ? ?D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > ? ? ? ? ? Registered at Amtsgericht Duesseldorf: HRB 46611 > ? ? ? ? ? ? ? http://www.egenix.com/company/contact/ > _______________________________________________ > Catalog-SIG mailing list > Catalog-SIG at python.org > http://mail.python.org/mailman/listinfo/catalog-sig > -- Tarek Ziad? | http://ziade.org From mal at egenix.com Fri Nov 18 21:05:30 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 18 Nov 2011 21:05:30 +0100 Subject: [Catalog-sig] New classifiers for Plone In-Reply-To: References: <4EC65C3A.70403@egenix.com> <4EC68519.2080701@egenix.com> Message-ID: <4EC6BA8A.1000401@egenix.com> Tarek Ziad? wrote: > On Fri, Nov 18, 2011 at 8:17 AM, M.-A. Lemburg wrote: >> Alex Clark wrote: >>> Hi, >>> >>> On 11/18/11 8:23 AM, M.-A. Lemburg wrote: >>>> Alex Clark wrote: >>>>> Hi all, >>>>> >>>>> There has been a discussion on distutils recently re: new trove classifiers for Plone. We have >>>>> settled on asking for the following new trove classifiers to be added: >>>>> >>>>> >>>>> Framework :: Plone :: 3.3 >>>>> Framework :: Plone :: 4.0 >>>>> Framework :: Plone :: 4.1 >>>>> Framework :: Plone :: 4.2 >>>>> Framework :: Plone :: 4.3 >>>>> >>>>> We will then encourage our add-on developers to use them in their add-ons, and implement new search >>>>> functionality on http://plone.org/products accordingly. >>>>> >>>>> Any objections? If not, please feel free to add these at your earliest convenience. >>>> >>>> You should also include: >>>> >>>> Framework :: Plone >>>> Framework :: Plone :: 3 >>>> Framework :: Plone :: 4 >>>> >>>> to make the set complete. >>> >>> >>> We actually don't want those, unless you want to use 4 instead of 4.0. Using 3 (or 3.0) does not >>> help us, as we don't intend to classify add-ons for releases prior to egg-based Plone releases >>> (starting at 3.2). >> >> Well, you don't, but users may want to browser PyPI and other similar >> indexes based on products for Plone, Plone 3 and Plone 4. >> >> The reasoning behind using major release classifiers is that package >> authors may now want to update the classifiers for their packages >> every time you issue a new release (by making a new release of the >> package). >> >> The unqualified category is needed for consistency with the other parent >> categories in the trove index. >> >>> We also discussed keeping the list as small as possible on the other thread. >> >> The above just follows the same schema as used for Python itself: > > > I understand the need for Python itself, but for Plone or framework name here>, does that make sense to add/maintain in the > Trove the framework versions ? that's an endless list to maintain, and > it makes me think that maybe we should allow *custom* trove > classifiers, so people can extend that list without having to ask > additions in the main trove list all the time While custom classifiers would be nice, you'd also end up with inconsistencies, different naming for the same thing and lots of typos. Perhaps adding a limited form of such custom classifiers would work out at least for some parts of the tree: If a::b is in the index, then qualifiers using a::b as prefix would also be accepted, e.g. a::b::c and a::b::c::d. That way e.g. frameworks could start using subtrees that they manage themselves. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 18 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From aclark at aclark.net Fri Nov 18 21:06:31 2011 From: aclark at aclark.net (Alex Clark) Date: Fri, 18 Nov 2011 15:06:31 -0500 Subject: [Catalog-sig] New classifiers for Plone In-Reply-To: References: <4EC65C3A.70403@egenix.com> <4EC68519.2080701@egenix.com> Message-ID: <4EC6BAC7.7010704@aclark.net> Hi, On 11/18/11 2:47 PM, Tarek Ziad? wrote: > On Fri, Nov 18, 2011 at 8:17 AM, M.-A. Lemburg wrote: >> Alex Clark wrote: >>> Hi, >>> >>> On 11/18/11 8:23 AM, M.-A. Lemburg wrote: >>>> Alex Clark wrote: >>>>> Hi all, >>>>> >>>>> There has been a discussion on distutils recently re: new trove classifiers for Plone. We have >>>>> settled on asking for the following new trove classifiers to be added: >>>>> >>>>> >>>>> Framework :: Plone :: 3.3 >>>>> Framework :: Plone :: 4.0 >>>>> Framework :: Plone :: 4.1 >>>>> Framework :: Plone :: 4.2 >>>>> Framework :: Plone :: 4.3 >>>>> >>>>> We will then encourage our add-on developers to use them in their add-ons, and implement new search >>>>> functionality on http://plone.org/products accordingly. >>>>> >>>>> Any objections? If not, please feel free to add these at your earliest convenience. >>>> >>>> You should also include: >>>> >>>> Framework :: Plone >>>> Framework :: Plone :: 3 >>>> Framework :: Plone :: 4 >>>> >>>> to make the set complete. >>> >>> >>> We actually don't want those, unless you want to use 4 instead of 4.0. Using 3 (or 3.0) does not >>> help us, as we don't intend to classify add-ons for releases prior to egg-based Plone releases >>> (starting at 3.2). >> >> Well, you don't, but users may want to browser PyPI and other similar >> indexes based on products for Plone, Plone 3 and Plone 4. >> >> The reasoning behind using major release classifiers is that package >> authors may now want to update the classifiers for their packages >> every time you issue a new release (by making a new release of the >> package). >> >> The unqualified category is needed for consistency with the other parent >> categories in the trove index. >> >>> We also discussed keeping the list as small as possible on the other thread. >> >> The above just follows the same schema as used for Python itself: > > > I understand the need for Python itself, but for Plone or framework name here>, does that make sense to add/maintain in the > Trove the framework versions ? that's an endless list to maintain, and > it makes me think that maybe we should allow *custom* trove > classifiers, so people can extend that list without having to ask > additions in the main trove list all the time. Supporting custom trove classifiers would help a lot. In fact I have avoided asking this question for years, because I knew someone would respond with the exact comment above ;-). But if they go in the trove list for now, that makes my life easier because then we can use the setuptools API to extract the version info and set the appropriate fields in PloneSoftwareCenter (or at least that is my current understanding). Alternatively, if we just instruct folks to start using those classifiers, we'd likely have to do something ugly to provide the same type of functionality. Bottom line: we'd appreciate these being added until such time as custom classifiers can be implemented. I picked "4.3" because it's the furthest release on the radar from now. We don't expect to be asking again for another 6 months at least, maybe longer. And I agree that it's "suboptimal" to have to keep asking (and supporting an endless list). Not to mention any "my framework too, please!!!" precedent this could potentially cause. Alex > > > Cheers > Tarek > > >> Programming Language :: Python >> Programming Language :: Python :: 2 >> Programming Language :: Python :: 2.3 >> Programming Language :: Python :: 2.4 >> Programming Language :: Python :: 2.5 >> Programming Language :: Python :: 2.6 >> Programming Language :: Python :: 2.7 >> Programming Language :: Python :: 3 >> Programming Language :: Python :: 3.0 >> Programming Language :: Python :: 3.1 >> Programming Language :: Python :: 3.2 >> >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Source (#1, Nov 18 2011) >>>>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >> ________________________________________________________________________ >> >> ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: >> >> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> Registered at Amtsgericht Duesseldorf: HRB 46611 >> http://www.egenix.com/company/contact/ >> _______________________________________________ >> Catalog-SIG mailing list >> Catalog-SIG at python.org >> http://mail.python.org/mailman/listinfo/catalog-sig >> > > > From ziade.tarek at gmail.com Fri Nov 18 21:08:19 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Fri, 18 Nov 2011 12:08:19 -0800 Subject: [Catalog-sig] New classifiers for Plone In-Reply-To: <4EC6BA8A.1000401@egenix.com> References: <4EC65C3A.70403@egenix.com> <4EC68519.2080701@egenix.com> <4EC6BA8A.1000401@egenix.com> Message-ID: On Fri, Nov 18, 2011 at 12:05 PM, M.-A. Lemburg wrote: ... > While custom classifiers would be nice, you'd also end up with > inconsistencies, different naming for the same thing and lots > of typos. > > Perhaps adding a limited form of such custom classifiers would > work out at least for some parts of the tree: > > ? ?If a::b is in the index, then qualifiers using a::b as prefix > ? ?would also be accepted, e.g. a::b::c and a::b::c::d. > > That way e.g. frameworks could start using subtrees that they manage > themselves. Sounds like a good idea to me. The only required change is in the PyPI server software so it allows a custom part. Cheers -- Tarek Ziad? | http://ziade.org From ziade.tarek at gmail.com Fri Nov 18 21:11:12 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Fri, 18 Nov 2011 12:11:12 -0800 Subject: [Catalog-sig] New classifiers for Plone In-Reply-To: <4EC6BAC7.7010704@aclark.net> References: <4EC65C3A.70403@egenix.com> <4EC68519.2080701@egenix.com> <4EC6BAC7.7010704@aclark.net> Message-ID: On Fri, Nov 18, 2011 at 12:06 PM, Alex Clark wrote: .. > Supporting custom trove classifiers would help a lot. In fact I have avoided > asking this question for years, because I knew someone would respond with > the exact comment above ;-). > > But if they go in the trove list for now, that makes my life easier because > then we can use the setuptools API to extract the version info and set the > appropriate fields in PloneSoftwareCenter (or at least that is my current > understanding). In my knowledge, the only part where a custom classifier would not work is the main PyPI server, that checks the value when you register your metadata. A few years ago, my intent was that PSC could maintain extra classifiers, exactly for this use case. > Alternatively, if we just instruct folks to start using those classifiers, > we'd likely have to do something ugly to provide the same type of > functionality. > > Bottom line: we'd appreciate these being added until such time as custom > classifiers can be implemented. I picked "4.3" because it's the furthest > release on the radar from now. We don't expect to be asking again for > another 6 months at least, maybe longer. And I agree that it's "suboptimal" > to have to keep asking (and supporting an endless list). Not to mention any > "my framework too, please!!!" precedent this could potentially cause. > > > > Alex > > > > >> >> >> Cheers >> Tarek >> >> >>> Programming Language :: Python >>> Programming Language :: Python :: 2 >>> Programming Language :: Python :: 2.3 >>> Programming Language :: Python :: 2.4 >>> Programming Language :: Python :: 2.5 >>> Programming Language :: Python :: 2.6 >>> Programming Language :: Python :: 2.7 >>> Programming Language :: Python :: 3 >>> Programming Language :: Python :: 3.0 >>> Programming Language :: Python :: 3.1 >>> Programming Language :: Python :: 3.2 >>> >>> -- >>> Marc-Andre Lemburg >>> eGenix.com >>> >>> Professional Python Services directly from the Source ?(#1, Nov 18 2011) >>>>>> >>>>>> Python/Zope Consulting and Support ... ? ? ? ?http://www.egenix.com/ >>>>>> mxODBC.Zope.Database.Adapter ... ? ? ? ? ? ? http://zope.egenix.com/ >>>>>> mxODBC, mxDateTime, mxTextTools ... ? ? ? ?http://python.egenix.com/ >>> >>> ________________________________________________________________________ >>> >>> ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: >>> >>> >>> ? eGenix.com Software, Skills and Services GmbH ?Pastor-Loeh-Str.48 >>> ? ?D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>> ? ? ? ? ? Registered at Amtsgericht Duesseldorf: HRB 46611 >>> ? ? ? ? ? ? ? http://www.egenix.com/company/contact/ >>> _______________________________________________ >>> Catalog-SIG mailing list >>> Catalog-SIG at python.org >>> http://mail.python.org/mailman/listinfo/catalog-sig >>> >> >> >> > > > _______________________________________________ > Catalog-SIG mailing list > Catalog-SIG at python.org > http://mail.python.org/mailman/listinfo/catalog-sig > -- Tarek Ziad? | http://ziade.org From martin at v.loewis.de Fri Nov 18 22:13:14 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 18 Nov 2011 22:13:14 +0100 Subject: [Catalog-sig] New classifiers for Plone In-Reply-To: <4EC65C3A.70403@egenix.com> References: <4EC65C3A.70403@egenix.com> Message-ID: <4EC6CA6A.50508@v.loewis.de> > You should also include: > > Framework :: Plone > Framework :: Plone :: 3 > Framework :: Plone :: 4 > > to make the set complete. I think I'll go by what the Plone community decides on. If they don't need these classifiers, they just don't need them. The fewer the better. Regards, Martin From tjreedy at udel.edu Fri Nov 18 22:44:29 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 18 Nov 2011 16:44:29 -0500 Subject: [Catalog-sig] PyPI trove classifiers for alternate language implementations In-Reply-To: References: <4E70AA85.6090700@v.loewis.de> <4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com> <4E7287CA.6070900@egenix.com> <4EC617D6.10304@v.loewis.de> Message-ID: On 11/18/2011 6:57 AM, Michael Foord wrote: > > > On 18 November 2011 08:31, "Martin v. L?wis" > wrote: > > Am 15.11.2011 23:53, schrieb Michael Foord: > > Whilst we're considering new classifiers - any word on this one? > > I lost track: what't the proposal, and what's the consensus? > > > Programming Language :: Python :: Implementation :: CPython > Programming Language :: Python :: Implementation :: PyPy > Programming Language :: Python :: Implementation :: Jython > Programming Language :: Python :: Implementation :: IronPython > Programming Language :: Python :: Implementation :: Stackless > > There seemed to be agreement that classifiers for the different > implementations was useful. > > M-A Lemburg suggested adding versions *as well*. Jean-Paul Calderone and > I thought it was unnecessary as Jython and IronPython are now using > CPython version numbers and different versions of all the > implementations tend to target a specific Python language version - for > which we already have classifiers. > > M-A Lemburg disliked the the "Implementation" part of the classifier (he > was only -0 on it though). I think it is useful/necessary to have it to > disambiguate these implementations from other Python-like-languages > (like Cython and Shedskin) that can be used to write Python extensions. For the purpose of searching, I cannot see how adding 'implementation' helps much -- unless there are a lot of other 3rd and 4th level classifiers that I do not know about. So I am - or + depending on the context. As I understand them, Shedskin compiles a subset and Cython a superset of Python. > (As a matter of correctness all of these implementations provide "the > Python programming language" and strive very hard indeed not to be > distinct programming languages...) -- Terry Jan Reedy From mal at egenix.com Sat Nov 19 00:14:24 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Sat, 19 Nov 2011 00:14:24 +0100 Subject: [Catalog-sig] New classifiers for Plone In-Reply-To: <4EC6CA6A.50508@v.loewis.de> References: <4EC65C3A.70403@egenix.com> <4EC6CA6A.50508@v.loewis.de> Message-ID: <4EC6E6D0.7080203@egenix.com> "Martin v. L?wis" wrote: >> You should also include: >> >> Framework :: Plone >> Framework :: Plone :: 3 >> Framework :: Plone :: 4 >> >> to make the set complete. > > I think I'll go by what the Plone community decides on. If they > don't need these classifiers, they just don't need them. The fewer > the better. You probably missed Alex's reply: Alex Clark wrote: > OK I'm fine with this, then. So to reiterate, we are asking for (I forgot 3.2 in the previous list): > > Framework :: Plone :: 3 > Framework :: Plone :: 3.2 > Framework :: Plone :: 3.3 > Framework :: Plone :: 4 > Framework :: Plone :: 4.0 > Framework :: Plone :: 4.1 > Framework :: Plone :: 4.2 > Framework :: Plone :: 4.3 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 19 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From fuzzyman at gmail.com Sat Nov 19 15:14:49 2011 From: fuzzyman at gmail.com (Michael Foord) Date: Sat, 19 Nov 2011 14:14:49 +0000 Subject: [Catalog-sig] PyPI trove classifiers for alternate language implementations In-Reply-To: References: <4E70AA85.6090700@v.loewis.de> <4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com> <4E7287CA.6070900@egenix.com> <4EC617D6.10304@v.loewis.de> Message-ID: On 18 November 2011 21:44, Terry Reedy wrote: > On 11/18/2011 6:57 AM, Michael Foord wrote: > >> >> >> On 18 November 2011 08:31, "Martin v. L?wis" > > wrote: >> >> Am 15.11.2011 23:53, schrieb Michael Foord: >> > Whilst we're considering new classifiers - any word on this one? >> >> I lost track: what't the proposal, and what's the consensus? >> >> >> Programming Language :: Python :: Implementation :: CPython >> Programming Language :: Python :: Implementation :: PyPy >> Programming Language :: Python :: Implementation :: Jython >> Programming Language :: Python :: Implementation :: IronPython >> Programming Language :: Python :: Implementation :: Stackless >> >> There seemed to be agreement that classifiers for the different >> implementations was useful. >> >> M-A Lemburg suggested adding versions *as well*. Jean-Paul Calderone and >> I thought it was unnecessary as Jython and IronPython are now using >> CPython version numbers and different versions of all the >> implementations tend to target a specific Python language version - for >> which we already have classifiers. >> >> M-A Lemburg disliked the the "Implementation" part of the classifier (he >> was only -0 on it though). I think it is useful/necessary to have it to >> disambiguate these implementations from other Python-like-languages >> (like Cython and Shedskin) that can be used to write Python extensions. >> > > For the purpose of searching, I cannot see how adding 'implementation' > helps much -- unless there are a lot of other 3rd and 4th level classifiers > that I do not know about. So I am - or + depending on the context. > > As I understand them, Shedskin compiles a subset and Cython a superset of > Python. Trove classifiers are for classification (and searching is a nice consequence of that), right? It's a matter of accuracy. PyPy, IronPython and Jython are *not* programming languages they are implementations of the Python programming language. Shedskin and and Cython are python-like programming languages (yes, subset and mostly-superset respectively). A recent thread here mentioned that our classifiers already go to five levels deep, so a four level classifier won't be "novel". Michael > > > (As a matter of correctness all of these implementations provide "the >> Python programming language" and strive very hard indeed not to be >> distinct programming languages...) >> > > -- > Terry Jan Reedy > > > > ______________________________**_________________ > Catalog-SIG mailing list > Catalog-SIG at python.org > http://mail.python.org/**mailman/listinfo/catalog-sig > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at v.loewis.de Sun Nov 20 10:49:14 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 20 Nov 2011 10:49:14 +0100 Subject: [Catalog-sig] PyPI trove classifiers for alternate language implementations In-Reply-To: References: <4E70AA85.6090700@v.loewis.de> <4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com> <4E7287CA.6070900@egenix.com> <4EC617D6.10304@v.loewis.de> Message-ID: <4EC8CD1A.2010604@v.loewis.de> > Programming Language :: Python :: Implementation :: CPython > Programming Language :: Python :: Implementation :: PyPy > Programming Language :: Python :: Implementation :: Jython > Programming Language :: Python :: Implementation :: IronPython > Programming Language :: Python :: Implementation :: Stackless I have now added these. To support this structure, the slightly bogus "Programming Language :: Python :: Implementation" classifier needed to be added as well. Regards, Martin From martin at v.loewis.de Sun Nov 20 10:51:04 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 20 Nov 2011 10:51:04 +0100 Subject: [Catalog-sig] New classifiers for Plone In-Reply-To: References: <4EC65C3A.70403@egenix.com> <4EC68519.2080701@egenix.com> Message-ID: <4EC8CD88.5030809@v.loewis.de> > Framework :: Plone :: 3.2 > Framework :: Plone :: 3.3 > Framework :: Plone :: 4.0 > Framework :: Plone :: 4.1 > Framework :: Plone :: 4.2 > Framework :: Plone :: 4.3 I have now added these. If you do need the ones with just the major version, let me know. Regards, Martin From fuzzyman at gmail.com Sun Nov 20 14:39:33 2011 From: fuzzyman at gmail.com (Michael Foord) Date: Sun, 20 Nov 2011 13:39:33 +0000 Subject: [Catalog-sig] PyPI trove classifiers for alternate language implementations In-Reply-To: <4EC8CD1A.2010604@v.loewis.de> References: <4E70AA85.6090700@v.loewis.de> <4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com> <4E7287CA.6070900@egenix.com> <4EC617D6.10304@v.loewis.de> <4EC8CD1A.2010604@v.loewis.de> Message-ID: On 20 November 2011 09:49, "Martin v. L?wis" wrote: > > Programming Language :: Python :: Implementation :: CPython > > Programming Language :: Python :: Implementation :: PyPy > > Programming Language :: Python :: Implementation :: Jython > > Programming Language :: Python :: Implementation :: IronPython > > Programming Language :: Python :: Implementation :: Stackless > > I have now added these. To support this structure, the slightly bogus > "Programming Language :: Python :: Implementation" classifier needed > to be added as well. > Thanks Martin. All the best, Michael > > Regards, > Martin > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgollakota at gmail.com Sun Nov 20 15:47:52 2011 From: pgollakota at gmail.com (Praveen Gollakota) Date: Sun, 20 Nov 2011 09:47:52 -0500 Subject: [Catalog-sig] Is PyPI an OpenID/OAuth Provider? Message-ID: Hello, I am trying to create a website that can be used by PyPI package owners/maintainers to collect feedback about their projects. For the project I need to be able to *authenticate* the package owner/maintainer. Does PyPI *provide* an OpenID/OAuth based authentication? I was looking around online, but was not able to find out for sure. Thanks, Praveen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at v.loewis.de Sun Nov 20 20:46:02 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 20 Nov 2011 20:46:02 +0100 Subject: [Catalog-sig] Is PyPI an OpenID/OAuth Provider? In-Reply-To: References: Message-ID: <4EC958FA.7030302@v.loewis.de> > I am trying to create a website that can be used by PyPI package > owners/maintainers to collect feedback about their projects. For the > project I need to be able to *authenticate* the package > owner/maintainer. Does PyPI *provide* an OpenID/OAuth based > authentication? There is some implementation of that, but it's not an official service yet. If you are willing to rely on experimental services and in-progress work, let me know, and I'll provide you with the details. Regards, Martin From aclark at aclark.net Mon Nov 21 03:16:24 2011 From: aclark at aclark.net (Alex Clark) Date: Sun, 20 Nov 2011 21:16:24 -0500 Subject: [Catalog-sig] New classifiers for Plone In-Reply-To: <4EC8CD88.5030809@v.loewis.de> References: <4EC65C3A.70403@egenix.com> <4EC68519.2080701@egenix.com> <4EC8CD88.5030809@v.loewis.de> Message-ID: On 11/20/11 4:51 AM, "Martin v. L?wis" wrote: >> Framework :: Plone :: 3.2 >> Framework :: Plone :: 3.3 >> Framework :: Plone :: 4.0 >> Framework :: Plone :: 4.1 >> Framework :: Plone :: 4.2 >> Framework :: Plone :: 4.3 > > I have now added these. If you do need the ones with just the major > version, let me know. Thanks Martin! Will do. Alex > > Regards, > Martin From martin at v.loewis.de Mon Nov 21 22:52:42 2011 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 21 Nov 2011 22:52:42 +0100 Subject: [Catalog-sig] PyPI as an OpenID provider Message-ID: <4ECAC82A.4030403@v.loewis.de> Thanks to Mark Rees, PyPI is now an OpenID provider. I fixed a few remaining issues, so I'm now able to announce this as an experimental service. "Experimental" here means that we wait a few months to see whether serious problems show up that may cause us to revert the service or change the URL schemes. We certainly hope that this won't be necessary. To use this OpenID provider, enter "pypi.python.org/id" into any form that expects an OpenID. Should the service not support OpenID 2, you will have to enter "pypi.python.org/id/" instead (the former is the provider ID, the latter are the user IDs). We follow the emerging approach that you have to sign into PyPI *before* signing into the actual services. This is intended to prevent phishing, as otherwise the relying party may fake PyPI's login page and collect your PyPI password (which they can still do if you fall for it). It also avoids "nested" logins (i.e. where you need to log into PyPI with an OpenID while trying to login elsewhere with the PyPI id). If you find any problems with this service, please report them here or to the PyPI bug tracker. A few success reports are also appreciated. Regards, Martin From inform at tiker.net Thu Nov 24 01:53:37 2011 From: inform at tiker.net (Andreas Kloeckner) Date: Wed, 23 Nov 2011 19:53:37 -0500 Subject: [Catalog-sig] PyPI uploads >= 1M Message-ID: <871usy5oj2.fsf@ding.tiker.net> Hi there, I just tried to submit the next version of the 'islpy' Python package, but PyPI wouldn't let me--it said '413 Request entity too large'. The package is about 1.6 MB gzipped or 1.2 MB bzip2'd. It's a legitimate package with a few users--I promise. :) The reason for the size is that it includes a minimal subset of Boost.Python as well as the isl library (which it wraps). I read somewhere that there's a file size limit of 5M (which sounds reasonable), but it looks like the httpd refuses smaller packages before they even get uploaded. Please cc me on responses as I'm not subscribed. Thanks, Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jannis at leidel.info Sat Nov 26 17:04:48 2011 From: jannis at leidel.info (Jannis Leidel) Date: Sat, 26 Nov 2011 17:04:48 +0100 Subject: [Catalog-sig] PyPI uploads >= 1M In-Reply-To: <871usy5oj2.fsf@ding.tiker.net> References: <871usy5oj2.fsf@ding.tiker.net> Message-ID: <17966CEF-EFD3-4A11-BEBF-40BD54C61B9C@leidel.info> On 24.11.2011, at 01:53, Andreas Kloeckner wrote: > Hi there, > > I just tried to submit the next version of the 'islpy' Python package, > but PyPI wouldn't let me--it said '413 Request entity too large'. The > package is about 1.6 MB gzipped or 1.2 MB bzip2'd. It's a legitimate > package with a few users--I promise. :) The reason for the size is that > it includes a minimal subset of Boost.Python as well as the isl library > (which it wraps). I read somewhere that there's a file size limit of 5M > (which sounds reasonable), but it looks like the httpd refuses smaller > packages before they even get uploaded. > > Please cc me on responses as I'm not subscribed. That has been fixed yesterday, please try again. Jannis From inform at tiker.net Sat Nov 26 18:00:36 2011 From: inform at tiker.net (Andreas Kloeckner) Date: Sat, 26 Nov 2011 12:00:36 -0500 Subject: [Catalog-sig] PyPI uploads >= 1M In-Reply-To: <17966CEF-EFD3-4A11-BEBF-40BD54C61B9C@leidel.info> References: <871usy5oj2.fsf@ding.tiker.net> <17966CEF-EFD3-4A11-BEBF-40BD54C61B9C@leidel.info> Message-ID: <87zkfi3jkb.fsf@ding.tiker.net> On Sat, 26 Nov 2011 17:04:48 +0100, Jannis Leidel wrote: > On 24.11.2011, at 01:53, Andreas Kloeckner wrote: > > > Hi there, > > > > I just tried to submit the next version of the 'islpy' Python package, > > but PyPI wouldn't let me--it said '413 Request entity too large'. The > > package is about 1.6 MB gzipped or 1.2 MB bzip2'd. It's a legitimate > > package with a few users--I promise. :) The reason for the size is that > > it includes a minimal subset of Boost.Python as well as the isl library > > (which it wraps). I read somewhere that there's a file size limit of 5M > > (which sounds reasonable), but it looks like the httpd refuses smaller > > packages before they even get uploaded. > > > > Please cc me on responses as I'm not subscribed. > > > That has been fixed yesterday, please try again. Works now, thanks a bunch! Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rpqlive at hotmail.com Tue Nov 29 18:32:46 2011 From: rpqlive at hotmail.com (Ramon Quezada) Date: Tue, 29 Nov 2011 12:32:46 -0500 Subject: [Catalog-sig] unable to register new account at bugs.python.org Message-ID: Hi, I've tried to register a few times using openid and normal register method on bugs.python.org and never receive an e-mail. The e-mail I'm trying to register with is, rpqpro at hotmail.com Is there a hotmail block? -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at v.loewis.de Tue Nov 29 22:34:09 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 29 Nov 2011 22:34:09 +0100 Subject: [Catalog-sig] unable to register new account at bugs.python.org In-Reply-To: References: Message-ID: <4ED54FD1.6050203@v.loewis.de> Am 29.11.2011 18:32, schrieb Ramon Quezada: > Hi, > > I've tried to register a few times using openid and normal register > method on bugs.python.org and never receive an e-mail. > > The e-mail I'm trying to register with is, rpqpro at hotmail.com > > > Is there a hotmail block? Apparently so, but not necessarily on our side. We have a few mails hanging in the outgoing spool with an error status reason=connect to mx2.hotmail.com[65.54.188.110]:25: Connection timed out So apparently, either hotmail is down or plays possum for us. I doubt there is anything we can do - we really do need reliable email connectivity to you if you want to report bugs. Regards, Martin P.S. catalog-sig is for the Python Package Index (PyPI). Issues with the bug tracker can be reported to tracker-discuss at ...