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: <CAJ3HoZ1cZAuDf7H544UkNh-X2EFvjMo7EWG_LyP3nPx9affb1w@mail.gmail.com>
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: <CAJ3HoZ1cZAuDf7H544UkNh-X2EFvjMo7EWG_LyP3nPx9affb1w@mail.gmail.com>
References: <CAJ3HoZ1cZAuDf7H544UkNh-X2EFvjMo7EWG_LyP3nPx9affb1w@mail.gmail.com>
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: <CAJ3HoZ2=zDT19vq=AhDG-bbSO9j7krWMNOxog4AFf3s1CmjM0g@mail.gmail.com>
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: <CAJ3HoZ2=zDT19vq=AhDG-bbSO9j7krWMNOxog4AFf3s1CmjM0g@mail.gmail.com>
References: <CAJ3HoZ2=zDT19vq=AhDG-bbSO9j7krWMNOxog4AFf3s1CmjM0g@mail.gmail.com>
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: <CAJ3HoZ2=zDT19vq=AhDG-bbSO9j7krWMNOxog4AFf3s1CmjM0g@mail.gmail.com>
<4EC035BC.2040905@v.loewis.de>
Message-ID: <CAJ3HoZ2bxVF1+bcdeuV6y6OWJBvtjHZT7jotBaXfR0Fhvt_CsA@mail.gmail.com>
On Mon, Nov 14, 2011 at 10:25 AM, "Martin v. L?wis" <martin at v.loewis.de> 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: <CAJ3HoZ2bxVF1+bcdeuV6y6OWJBvtjHZT7jotBaXfR0Fhvt_CsA@mail.gmail.com>
References: <CAJ3HoZ2=zDT19vq=AhDG-bbSO9j7krWMNOxog4AFf3s1CmjM0g@mail.gmail.com>
<4EC035BC.2040905@v.loewis.de>
<CAJ3HoZ2bxVF1+bcdeuV6y6OWJBvtjHZT7jotBaXfR0Fhvt_CsA@mail.gmail.com>
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" <martin at v.loewis.de> 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: <http://mail.python.org/pipermail/catalog-sig/attachments/20111113/59f7a296/attachment.pgp>
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: <CAJ3HoZ2=zDT19vq=AhDG-bbSO9j7krWMNOxog4AFf3s1CmjM0g@mail.gmail.com>
<4EC035BC.2040905@v.loewis.de>
<CAJ3HoZ2bxVF1+bcdeuV6y6OWJBvtjHZT7jotBaXfR0Fhvt_CsA@mail.gmail.com>
<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: <CAJ3HoZ2=zDT19vq=AhDG-bbSO9j7krWMNOxog4AFf3s1CmjM0g@mail.gmail.com>
<4EC035BC.2040905@v.loewis.de>
<CAJ3HoZ2bxVF1+bcdeuV6y6OWJBvtjHZT7jotBaXfR0Fhvt_CsA@mail.gmail.com>
<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.
>
<nod> 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: <http://mail.python.org/pipermail/catalog-sig/attachments/20111114/cd78309e/attachment.pgp>
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: <CAJ3HoZ2=zDT19vq=AhDG-bbSO9j7krWMNOxog4AFf3s1CmjM0g@mail.gmail.com>
<4EC035BC.2040905@v.loewis.de>
<CAJ3HoZ2bxVF1+bcdeuV6y6OWJBvtjHZT7jotBaXfR0Fhvt_CsA@mail.gmail.com>
<20111114003747.GG2861@unaka.lan>
Message-ID: <j9sdu6$t05$1@dough.gmane.org>
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: <j9sdu6$t05$1@dough.gmane.org>
References: <CAJ3HoZ2=zDT19vq=AhDG-bbSO9j7krWMNOxog4AFf3s1CmjM0g@mail.gmail.com>
<4EC035BC.2040905@v.loewis.de>
<CAJ3HoZ2bxVF1+bcdeuV6y6OWJBvtjHZT7jotBaXfR0Fhvt_CsA@mail.gmail.com>
<20111114003747.GG2861@unaka.lan> <j9sdu6$t05$1@dough.gmane.org>
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: <http://mail.python.org/pipermail/catalog-sig/attachments/20111114/d21bf83a/attachment.pgp>
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: <j9sdu6$t05$1@dough.gmane.org>
References: <CAJ3HoZ2=zDT19vq=AhDG-bbSO9j7krWMNOxog4AFf3s1CmjM0g@mail.gmail.com> <4EC035BC.2040905@v.loewis.de> <CAJ3HoZ2bxVF1+bcdeuV6y6OWJBvtjHZT7jotBaXfR0Fhvt_CsA@mail.gmail.com> <20111114003747.GG2861@unaka.lan>
<j9sdu6$t05$1@dough.gmane.org>
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: <CAJ3HoZ2=zDT19vq=AhDG-bbSO9j7krWMNOxog4AFf3s1CmjM0g@mail.gmail.com> <4EC035BC.2040905@v.loewis.de> <CAJ3HoZ2bxVF1+bcdeuV6y6OWJBvtjHZT7jotBaXfR0Fhvt_CsA@mail.gmail.com> <20111114003747.GG2861@unaka.lan>
<j9sdu6$t05$1@dough.gmane.org> <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: <CAJ3HoZ2=zDT19vq=AhDG-bbSO9j7krWMNOxog4AFf3s1CmjM0g@mail.gmail.com>
<4EC035BC.2040905@v.loewis.de>
<CAJ3HoZ2bxVF1+bcdeuV6y6OWJBvtjHZT7jotBaXfR0Fhvt_CsA@mail.gmail.com>
<20111114003747.GG2861@unaka.lan> <j9sdu6$t05$1@dough.gmane.org>
<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.
>
<nod> 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: <http://mail.python.org/pipermail/catalog-sig/attachments/20111115/bc755f5a/attachment.pgp>
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: <CAKCKLWxLCVRNj3eiDQi28C1GuS4KW8bDMBaYq+w8OUt=fWwFAg@mail.gmail.com>
References: <CADiSq7dNhexnM56-u3W1Y_i3u1vAdHrFBtFVLbrri0JXLVf1XQ@mail.gmail.com>
<DF04F544-0CA8-426F-A9F2-DAFA7EBCDC14@gmail.com>
<4E70AA85.6090700@v.loewis.de>
<CAKCKLWz=13LuP=h0NsYRQ55uy8suM46viKh9+0HKeSdEv7ZvUg@mail.gmail.com>
<4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com>
<CAKCKLWxDj3zh5-Crw8v7e_8GJ2HQdvpBC2QRteQdK9umYQrPpA@mail.gmail.com>
<4E7287CA.6070900@egenix.com>
<CAKCKLWxLCVRNj3eiDQi28C1GuS4KW8bDMBaYq+w8OUt=fWwFAg@mail.gmail.com>
Message-ID: <CAKCKLWyv8Sj0=5nZ9fFgxL03S=TMfsr9QXVjznczchDsP=-AWg@mail.gmail.com>
Whilst we're considering new classifiers - any word on this one?
Michael
On 16 October 2011 16:06, Michael Foord <fuzzyman at gmail.com> wrote:
>
>
> On 16 September 2011 00:18, M.-A. Lemburg <mal at egenix.com> wrote:
>
>> Michael Foord wrote:
>> > On 15 September 2011 15:24, M.-A. Lemburg <mal at egenix.com> 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: <http://mail.python.org/pipermail/catalog-sig/attachments/20111115/da63a823/attachment-0001.html>
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: <ja3sgn$cf$1@dough.gmane.org>
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: <CAKCKLWyv8Sj0=5nZ9fFgxL03S=TMfsr9QXVjznczchDsP=-AWg@mail.gmail.com>
References: <CADiSq7dNhexnM56-u3W1Y_i3u1vAdHrFBtFVLbrri0JXLVf1XQ@mail.gmail.com> <DF04F544-0CA8-426F-A9F2-DAFA7EBCDC14@gmail.com> <4E70AA85.6090700@v.loewis.de> <CAKCKLWz=13LuP=h0NsYRQ55uy8suM46viKh9+0HKeSdEv7ZvUg@mail.gmail.com> <4E7207B2.4070404@v.loewis.de>
<4E720A85.2070501@egenix.com> <CAKCKLWxDj3zh5-Crw8v7e_8GJ2HQdvpBC2QRteQdK9umYQrPpA@mail.gmail.com> <4E7287CA.6070900@egenix.com> <CAKCKLWxLCVRNj3eiDQi28C1GuS4KW8bDMBaYq+w8OUt=fWwFAg@mail.gmail.com>
<CAKCKLWyv8Sj0=5nZ9fFgxL03S=TMfsr9QXVjznczchDsP=-AWg@mail.gmail.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: <CAKCKLWyv8Sj0=5nZ9fFgxL03S=TMfsr9QXVjznczchDsP=-AWg@mail.gmail.com>
References: <CADiSq7dNhexnM56-u3W1Y_i3u1vAdHrFBtFVLbrri0JXLVf1XQ@mail.gmail.com> <DF04F544-0CA8-426F-A9F2-DAFA7EBCDC14@gmail.com> <4E70AA85.6090700@v.loewis.de> <CAKCKLWz=13LuP=h0NsYRQ55uy8suM46viKh9+0HKeSdEv7ZvUg@mail.gmail.com> <4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com> <CAKCKLWxDj3zh5-Crw8v7e_8GJ2HQdvpBC2QRteQdK9umYQrPpA@mail.gmail.com> <4E7287CA.6070900@egenix.com> <CAKCKLWxLCVRNj3eiDQi28C1GuS4KW8bDMBaYq+w8OUt=fWwFAg@mail.gmail.com>
<CAKCKLWyv8Sj0=5nZ9fFgxL03S=TMfsr9QXVjznczchDsP=-AWg@mail.gmail.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: <CADiSq7dNhexnM56-u3W1Y_i3u1vAdHrFBtFVLbrri0JXLVf1XQ@mail.gmail.com>
<DF04F544-0CA8-426F-A9F2-DAFA7EBCDC14@gmail.com>
<4E70AA85.6090700@v.loewis.de>
<CAKCKLWz=13LuP=h0NsYRQ55uy8suM46viKh9+0HKeSdEv7ZvUg@mail.gmail.com>
<4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com>
<CAKCKLWxDj3zh5-Crw8v7e_8GJ2HQdvpBC2QRteQdK9umYQrPpA@mail.gmail.com>
<4E7287CA.6070900@egenix.com>
<CAKCKLWxLCVRNj3eiDQi28C1GuS4KW8bDMBaYq+w8OUt=fWwFAg@mail.gmail.com>
<CAKCKLWyv8Sj0=5nZ9fFgxL03S=TMfsr9QXVjznczchDsP=-AWg@mail.gmail.com>
<4EC617D6.10304@v.loewis.de>
Message-ID: <CAKCKLWwOPw2y-dTyEZGCvsvikyZbyTHa9VJ+sZ1q-QWRXLvkFA@mail.gmail.com>
On 18 November 2011 08:31, "Martin v. L?wis" <martin at v.loewis.de> 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: <http://mail.python.org/pipermail/catalog-sig/attachments/20111118/6c1dcebb/attachment.html>
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: <CADiSq7dNhexnM56-u3W1Y_i3u1vAdHrFBtFVLbrri0JXLVf1XQ@mail.gmail.com>
<DF04F544-0CA8-426F-A9F2-DAFA7EBCDC14@gmail.com>
<4E70AA85.6090700@v.loewis.de>
<CAKCKLWz=13LuP=h0NsYRQ55uy8suM46viKh9+0HKeSdEv7ZvUg@mail.gmail.com>
<4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com>
<CAKCKLWxDj3zh5-Crw8v7e_8GJ2HQdvpBC2QRteQdK9umYQrPpA@mail.gmail.com>
<4E7287CA.6070900@egenix.com>
<CAKCKLWxLCVRNj3eiDQi28C1GuS4KW8bDMBaYq+w8OUt=fWwFAg@mail.gmail.com>
<CAKCKLWyv8Sj0=5nZ9fFgxL03S=TMfsr9QXVjznczchDsP=-AWg@mail.gmail.com>
<4EC616A2.70809@netwok.org>
Message-ID: <CAKCKLWzbmejUWce185Lv23yX06yTiAuNgMuSX70ks4VwEkAO7A@mail.gmail.com>
On 18 November 2011 08:26, ?ric Araujo <merwok at netwok.org> 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: <http://mail.python.org/pipermail/catalog-sig/attachments/20111118/fcc066ed/attachment.html>
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: <ja3sgn$cf$1@dough.gmane.org>
References: <ja3sgn$cf$1@dough.gmane.org>
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: <ja3sgn$cf$1@dough.gmane.org> <4EC65C3A.70403@egenix.com>
Message-ID: <ja5u58$i9a$1@dough.gmane.org>
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: <ja5u58$i9a$1@dough.gmane.org>
References: <ja3sgn$cf$1@dough.gmane.org> <4EC65C3A.70403@egenix.com>
<ja5u58$i9a$1@dough.gmane.org>
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: <ja3sgn$cf$1@dough.gmane.org> <4EC65C3A.70403@egenix.com>
<ja5u58$i9a$1@dough.gmane.org> <4EC68519.2080701@egenix.com>
Message-ID: <ja61c8$d75$1@dough.gmane.org>
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: <ja3sgn$cf$1@dough.gmane.org> <4EC65C3A.70403@egenix.com>
<ja5u58$i9a$1@dough.gmane.org> <4EC68519.2080701@egenix.com>
Message-ID: <CAGSi+Q4smdJR=2TrMDBbVv45WXjkZxN+j6ii4OjUr876oDwroA@mail.gmail.com>
On Fri, Nov 18, 2011 at 8:17 AM, M.-A. Lemburg <mal at egenix.com> 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 <put a
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
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: <CAGSi+Q4smdJR=2TrMDBbVv45WXjkZxN+j6ii4OjUr876oDwroA@mail.gmail.com>
References: <ja3sgn$cf$1@dough.gmane.org> <4EC65C3A.70403@egenix.com>
<ja5u58$i9a$1@dough.gmane.org> <4EC68519.2080701@egenix.com>
<CAGSi+Q4smdJR=2TrMDBbVv45WXjkZxN+j6ii4OjUr876oDwroA@mail.gmail.com>
Message-ID: <4EC6BA8A.1000401@egenix.com>
Tarek Ziad? wrote:
> On Fri, Nov 18, 2011 at 8:17 AM, M.-A. Lemburg <mal at egenix.com> 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 <put a
> 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: <CAGSi+Q4smdJR=2TrMDBbVv45WXjkZxN+j6ii4OjUr876oDwroA@mail.gmail.com>
References: <ja3sgn$cf$1@dough.gmane.org> <4EC65C3A.70403@egenix.com>
<ja5u58$i9a$1@dough.gmane.org> <4EC68519.2080701@egenix.com>
<CAGSi+Q4smdJR=2TrMDBbVv45WXjkZxN+j6ii4OjUr876oDwroA@mail.gmail.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<mal at egenix.com> 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<put a
> 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: <ja3sgn$cf$1@dough.gmane.org> <4EC65C3A.70403@egenix.com>
<ja5u58$i9a$1@dough.gmane.org> <4EC68519.2080701@egenix.com>
<CAGSi+Q4smdJR=2TrMDBbVv45WXjkZxN+j6ii4OjUr876oDwroA@mail.gmail.com>
<4EC6BA8A.1000401@egenix.com>
Message-ID: <CAGSi+Q4Gy75Y_-FJeJ-mTkpSYv10YY027W66rVFRQUf__gOMYg@mail.gmail.com>
On Fri, Nov 18, 2011 at 12:05 PM, M.-A. Lemburg <mal at egenix.com> 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: <ja3sgn$cf$1@dough.gmane.org> <4EC65C3A.70403@egenix.com>
<ja5u58$i9a$1@dough.gmane.org> <4EC68519.2080701@egenix.com>
<CAGSi+Q4smdJR=2TrMDBbVv45WXjkZxN+j6ii4OjUr876oDwroA@mail.gmail.com>
<4EC6BAC7.7010704@aclark.net>
Message-ID: <CAGSi+Q7QY7BR5t3A9RnCTSW1CA=XUBfdnxUVrZeiqJ5SNProFw@mail.gmail.com>
On Fri, Nov 18, 2011 at 12:06 PM, Alex Clark <aclark at aclark.net> 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: <ja3sgn$cf$1@dough.gmane.org> <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: <CAKCKLWwOPw2y-dTyEZGCvsvikyZbyTHa9VJ+sZ1q-QWRXLvkFA@mail.gmail.com>
References: <CADiSq7dNhexnM56-u3W1Y_i3u1vAdHrFBtFVLbrri0JXLVf1XQ@mail.gmail.com>
<DF04F544-0CA8-426F-A9F2-DAFA7EBCDC14@gmail.com>
<4E70AA85.6090700@v.loewis.de>
<CAKCKLWz=13LuP=h0NsYRQ55uy8suM46viKh9+0HKeSdEv7ZvUg@mail.gmail.com>
<4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com>
<CAKCKLWxDj3zh5-Crw8v7e_8GJ2HQdvpBC2QRteQdK9umYQrPpA@mail.gmail.com>
<4E7287CA.6070900@egenix.com>
<CAKCKLWxLCVRNj3eiDQi28C1GuS4KW8bDMBaYq+w8OUt=fWwFAg@mail.gmail.com>
<CAKCKLWyv8Sj0=5nZ9fFgxL03S=TMfsr9QXVjznczchDsP=-AWg@mail.gmail.com>
<4EC617D6.10304@v.loewis.de>
<CAKCKLWwOPw2y-dTyEZGCvsvikyZbyTHa9VJ+sZ1q-QWRXLvkFA@mail.gmail.com>
Message-ID: <ja6jk6$l6f$1@dough.gmane.org>
On 11/18/2011 6:57 AM, Michael Foord wrote:
>
>
> On 18 November 2011 08:31, "Martin v. L?wis" <martin at v.loewis.de
> <mailto:martin at v.loewis.de>> 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: <ja3sgn$cf$1@dough.gmane.org> <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: <ja6jk6$l6f$1@dough.gmane.org>
References: <CADiSq7dNhexnM56-u3W1Y_i3u1vAdHrFBtFVLbrri0JXLVf1XQ@mail.gmail.com>
<DF04F544-0CA8-426F-A9F2-DAFA7EBCDC14@gmail.com>
<4E70AA85.6090700@v.loewis.de>
<CAKCKLWz=13LuP=h0NsYRQ55uy8suM46viKh9+0HKeSdEv7ZvUg@mail.gmail.com>
<4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com>
<CAKCKLWxDj3zh5-Crw8v7e_8GJ2HQdvpBC2QRteQdK9umYQrPpA@mail.gmail.com>
<4E7287CA.6070900@egenix.com>
<CAKCKLWxLCVRNj3eiDQi28C1GuS4KW8bDMBaYq+w8OUt=fWwFAg@mail.gmail.com>
<CAKCKLWyv8Sj0=5nZ9fFgxL03S=TMfsr9QXVjznczchDsP=-AWg@mail.gmail.com>
<4EC617D6.10304@v.loewis.de>
<CAKCKLWwOPw2y-dTyEZGCvsvikyZbyTHa9VJ+sZ1q-QWRXLvkFA@mail.gmail.com>
<ja6jk6$l6f$1@dough.gmane.org>
Message-ID: <CAKCKLWy2xLQVfQQ7UdGwqD7JrVcbdWnfXqTcvSKu+A17vXH_8A@mail.gmail.com>
On 18 November 2011 21:44, Terry Reedy <tjreedy at udel.edu> wrote:
> On 11/18/2011 6:57 AM, Michael Foord wrote:
>
>>
>>
>> On 18 November 2011 08:31, "Martin v. L?wis" <martin at v.loewis.de
>> <mailto:martin at v.loewis.de>> 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://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: <http://mail.python.org/pipermail/catalog-sig/attachments/20111119/be5f7582/attachment.html>
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: <CAKCKLWwOPw2y-dTyEZGCvsvikyZbyTHa9VJ+sZ1q-QWRXLvkFA@mail.gmail.com>
References: <CADiSq7dNhexnM56-u3W1Y_i3u1vAdHrFBtFVLbrri0JXLVf1XQ@mail.gmail.com> <DF04F544-0CA8-426F-A9F2-DAFA7EBCDC14@gmail.com> <4E70AA85.6090700@v.loewis.de> <CAKCKLWz=13LuP=h0NsYRQ55uy8suM46viKh9+0HKeSdEv7ZvUg@mail.gmail.com> <4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com> <CAKCKLWxDj3zh5-Crw8v7e_8GJ2HQdvpBC2QRteQdK9umYQrPpA@mail.gmail.com> <4E7287CA.6070900@egenix.com> <CAKCKLWxLCVRNj3eiDQi28C1GuS4KW8bDMBaYq+w8OUt=fWwFAg@mail.gmail.com> <CAKCKLWyv8Sj0=5nZ9fFgxL03S=TMfsr9QXVjznczchDsP=-AWg@mail.gmail.com> <4EC617D6.10304@v.loewis.de>
<CAKCKLWwOPw2y-dTyEZGCvsvikyZbyTHa9VJ+sZ1q-QWRXLvkFA@mail.gmail.com>
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: <ja61c8$d75$1@dough.gmane.org>
References: <ja3sgn$cf$1@dough.gmane.org>
<4EC65C3A.70403@egenix.com> <ja5u58$i9a$1@dough.gmane.org>
<4EC68519.2080701@egenix.com> <ja61c8$d75$1@dough.gmane.org>
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: <CADiSq7dNhexnM56-u3W1Y_i3u1vAdHrFBtFVLbrri0JXLVf1XQ@mail.gmail.com>
<DF04F544-0CA8-426F-A9F2-DAFA7EBCDC14@gmail.com>
<4E70AA85.6090700@v.loewis.de>
<CAKCKLWz=13LuP=h0NsYRQ55uy8suM46viKh9+0HKeSdEv7ZvUg@mail.gmail.com>
<4E7207B2.4070404@v.loewis.de> <4E720A85.2070501@egenix.com>
<CAKCKLWxDj3zh5-Crw8v7e_8GJ2HQdvpBC2QRteQdK9umYQrPpA@mail.gmail.com>
<4E7287CA.6070900@egenix.com>
<CAKCKLWxLCVRNj3eiDQi28C1GuS4KW8bDMBaYq+w8OUt=fWwFAg@mail.gmail.com>
<CAKCKLWyv8Sj0=5nZ9fFgxL03S=TMfsr9QXVjznczchDsP=-AWg@mail.gmail.com>
<4EC617D6.10304@v.loewis.de>
<CAKCKLWwOPw2y-dTyEZGCvsvikyZbyTHa9VJ+sZ1q-QWRXLvkFA@mail.gmail.com>
<4EC8CD1A.2010604@v.loewis.de>
Message-ID: <CAKCKLWw7B+1juGO=gts7H1DuWdw_Prw1mB8XhSg5ZdV13BZM1w@mail.gmail.com>
On 20 November 2011 09:49, "Martin v. L?wis" <martin at v.loewis.de> 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: <http://mail.python.org/pipermail/catalog-sig/attachments/20111120/71b3ca71/attachment.html>
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: <CAOXAgaF8dEk5bt9XuPbioiRs3z9Pf_dg9TmKfhEFd=QuWhUzdw@mail.gmail.com>
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: <http://mail.python.org/pipermail/catalog-sig/attachments/20111120/c1c4e821/attachment.html>
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: <CAOXAgaF8dEk5bt9XuPbioiRs3z9Pf_dg9TmKfhEFd=QuWhUzdw@mail.gmail.com>
References: <CAOXAgaF8dEk5bt9XuPbioiRs3z9Pf_dg9TmKfhEFd=QuWhUzdw@mail.gmail.com>
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: <ja3sgn$cf$1@dough.gmane.org>
<4EC65C3A.70403@egenix.com> <ja5u58$i9a$1@dough.gmane.org>
<4EC68519.2080701@egenix.com> <ja61c8$d75$1@dough.gmane.org>
<4EC8CD88.5030809@v.loewis.de>
Message-ID: <jacc9o$54c$1@dough.gmane.org>
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/<username>"
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: <http://mail.python.org/pipermail/catalog-sig/attachments/20111123/d4293577/attachment.pgp>
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 <jannis at leidel.info> 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: <http://mail.python.org/pipermail/catalog-sig/attachments/20111126/270d9fb4/attachment.pgp>
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: <BLU163-W54062E89CC4F9EFAD28DF4AAB30@phx.gbl>
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: <http://mail.python.org/pipermail/catalog-sig/attachments/20111129/af4e2f62/attachment.html>
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: <BLU163-W54062E89CC4F9EFAD28DF4AAB30@phx.gbl>
References: <BLU163-W54062E89CC4F9EFAD28DF4AAB30@phx.gbl>
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
> <mailto: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 ...