From martin at v.loewis.de  Tue Dec  1 20:39:50 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 01 Dec 2009 20:39:50 +0100
Subject: [Catalog-sig] Poll results
Message-ID: <4B157106.6000705@v.loewis.de>

The poll is now closed, with these results

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

My interpretation is that the result is inconclusive. A clear majority
does want a comment facility (in some form); another (not so clear)
majority wants to see something changed.

So it might be best to implement what appears as middle-ground,
i.e. allow package authors to opt out of comments.

Opinions?

Regards,
Martin

From benji at benjiyork.com  Tue Dec  1 20:46:51 2009
From: benji at benjiyork.com (Benji York)
Date: Tue, 1 Dec 2009 14:46:51 -0500
Subject: [Catalog-sig] Poll results
In-Reply-To: <4B157106.6000705@v.loewis.de>
References: <4B157106.6000705@v.loewis.de>
Message-ID: <e5fff6640912011146r76dac7ap50da8ce83c2cdf7f@mail.gmail.com>

On Tue, Dec 1, 2009 at 2:39 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> The poll is now closed, with these results
[snip]
> So it might be best to implement what appears as middle-ground,
> i.e. allow package authors to opt out of comments.

+1
-- 
Benji York

From hanno at hannosch.eu  Tue Dec  1 20:49:45 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Tue, 1 Dec 2009 20:49:45 +0100
Subject: [Catalog-sig] Poll results
In-Reply-To: <4B157106.6000705@v.loewis.de>
References: <4B157106.6000705@v.loewis.de>
Message-ID: <5cae42b20912011149t6c12c60am5e5a9ca3a74d0a26@mail.gmail.com>

On Tue, Dec 1, 2009 at 8:39 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> My interpretation is that the result is inconclusive. A clear majority
> does want a comment facility (in some form); another (not so clear)
> majority wants to see something changed.
>
> So it might be best to implement what appears as middle-ground,
> i.e. allow package authors to opt out of comments.
>
> Opinions?

+1, seems a good conclusion to me.

Hanno

From exarkun at twistedmatrix.com  Tue Dec  1 20:55:12 2009
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Tue, 01 Dec 2009 19:55:12 -0000
Subject: [Catalog-sig] Poll results
In-Reply-To: <4B157106.6000705@v.loewis.de>
References: <4B157106.6000705@v.loewis.de>
Message-ID: <20091201195512.2549.1176007483.divmod.xquotient.46@localhost.localdomain>

On 07:39 pm, martin at v.loewis.de wrote:
>The poll is now closed, with these results
>
>Allow ratings and comments on all packages (status quo) 237
>Allow package owners to disallow comments (ratings unmodified). 139
>Allow comments, but only send them to package owners (ratings
>unmodified).    33
>Disallow comments (ratings unmodified). 24
>Disallow ratings and comments (status three months ago).        88
>
>My interpretation is that the result is inconclusive. A clear majority
>does want a comment facility (in some form); another (not so clear)
>majority wants to see something changed.
>
>So it might be best to implement what appears as middle-ground,
>i.e. allow package authors to opt out of comments.
>
>Opinions?

+1

Jean-Paul

From ianb at colorstudy.com  Tue Dec  1 21:53:29 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 1 Dec 2009 14:53:29 -0600
Subject: [Catalog-sig] Poll results
In-Reply-To: <4B157106.6000705@v.loewis.de>
References: <4B157106.6000705@v.loewis.de>
Message-ID: <b654cd2e0912011253i6eda0d0oac1d0b591c16013c@mail.gmail.com>

On Tue, Dec 1, 2009 at 1:39 PM, "Martin v. L?wis" <martin at v.loewis.de>wrote:

> The poll is now closed, with these results
>
> Allow ratings and comments on all packages (status quo) 237
> Allow package owners to disallow comments (ratings unmodified). 139
> Allow comments, but only send them to package owners (ratings
> unmodified).    33
> Disallow comments (ratings unmodified). 24
> Disallow ratings and comments (status three months ago).        88
>
> My interpretation is that the result is inconclusive. A clear majority
> does want a comment facility (in some form); another (not so clear)
> majority wants to see something changed.
>
> So it might be best to implement what appears as middle-ground,
> i.e. allow package authors to opt out of comments.
>
> Opinions?
>

I'm fine with that opt-out, though not opt-in (it's the packages with no one
at the wheel that most need comments).

I'd also like package authors to be able to comment (but not rate), and for
anyone to be able to comment without rating (which I've wanted to do).
 These seem like uncontroversial changes.

A perhaps more controversial change that I personally would like to see, is
that package authors be able to hide any comment on their package.  The
comment might be inaccurate, or spam, or whatever; a hidden comment could
just be visible after you click a [+] or something, not entirely censured
but made less prominent.  The Python community generally defers to
maintainers, and I believe if it deferred with respect to comments, I would
be surprised if it was abused.


-- 
Ian Bicking  |  http://blog.ianbicking.org  |
http://topplabs.org/civichacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20091201/28b452c8/attachment.htm>

From lac at openend.se  Tue Dec  1 22:50:33 2009
From: lac at openend.se (Laura Creighton)
Date: Tue, 01 Dec 2009 22:50:33 +0100
Subject: [Catalog-sig] Poll results
In-Reply-To: Message from =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
	<martin@v.loewis.de> 
	of "Tue, 01 Dec 2009 20:39:50 +0100." <4B157106.6000705@v.loewis.de> 
References: <4B157106.6000705@v.loewis.de> 
Message-ID: <200912012150.nB1LoXsm013404@theraft.openend.se>

In a message of Tue, 01 Dec 2009 20:39:50 +0100, "Martin v. L?wis" writes:
>The poll is now closed, with these results
>
>Allow ratings and comments on all packages (status quo)	237
>Allow package owners to disallow comments (ratings unmodified).	13
>9
>Allow comments, but only send them to package owners (ratings
>unmodified).	33
>Disallow comments (ratings unmodified).	24
>Disallow ratings and comments (status three months ago).	88
>
>My interpretation is that the result is inconclusive. A clear majority
>does want a comment facility (in some form); another (not so clear)
>majority wants to see something changed.
>
>So it might be best to implement what appears as middle-ground,
>i.e. allow package authors to opt out of comments.
>
>Opinions?
>
>Regards,
>Martin

There are seven states that could have been represented had you
designed this poll.  1 is 'mail comments back to the owners only'
the other 3 states are

for ratings, comments:
    would you like them to be a) mandatory
			      b) opt-in/out at the package owners request
			      c) prohibited/non-existant

Had you oranised the poll this way, you would have found me in the
'ratings prohibited/comments opt-in' camp.  So, of course I think
that allowing package authors to opt-out is a good idea.

But I think that getting rid of the ratings is is also important.

Laura


From noah at coderanger.net  Tue Dec  1 22:50:54 2009
From: noah at coderanger.net (Noah Kantrowitz)
Date: Tue, 1 Dec 2009 13:50:54 -0800
Subject: [Catalog-sig] Poll results
In-Reply-To: <4B157106.6000705@v.loewis.de>
References: <4B157106.6000705@v.loewis.de>
Message-ID: <005e01ca72d0$5c63d150$152b73f0$@net>

> -----Original Message-----
> From: catalog-sig-bounces+noah=coderanger.net at python.org
> [mailto:catalog-sig-bounces+noah=coderanger.net at python.org] On Behalf
> Of "Martin v. L?wis"
> Sent: Tuesday, December 01, 2009 11:40 AM
> To: catalog-sig
> Subject: [Catalog-sig] Poll results
> 
> The poll is now closed, with these results
> 
> Allow ratings and comments on all packages (status quo)	237
> Allow package owners to disallow comments (ratings unmodified).	139
> Allow comments, but only send them to package owners (ratings
> unmodified).	33
> Disallow comments (ratings unmodified).	24
> Disallow ratings and comments (status three months ago).	88
> 
> My interpretation is that the result is inconclusive. A clear majority
> does want a comment facility (in some form); another (not so clear)
> majority wants to see something changed.
> 
> So it might be best to implement what appears as middle-ground,
> i.e. allow package authors to opt out of comments.
> 
> Opinions?

Can we switch to using Disqus (http://disqus.com/) or similar service that
is a little easier on the eyes (and has some moderation tools, etc etc)?

--Noah


From martin at v.loewis.de  Tue Dec  1 23:00:26 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 01 Dec 2009 23:00:26 +0100
Subject: [Catalog-sig] Poll results
In-Reply-To: <200912012150.nB1LoXsm013404@theraft.openend.se>
References: <4B157106.6000705@v.loewis.de>
	<200912012150.nB1LoXsm013404@theraft.openend.se>
Message-ID: <4B1591FA.1090700@v.loewis.de>

> But I think that getting rid of the ratings is is also important.

I don't think this is consensus.

Regards,
Martin

From ianb at colorstudy.com  Tue Dec  1 23:02:47 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 1 Dec 2009 16:02:47 -0600
Subject: [Catalog-sig] Poll results
In-Reply-To: <200912012150.nB1LoXsm013404@theraft.openend.se>
References: <martin@v.loewis.de> <4B157106.6000705@v.loewis.de> 
	<200912012150.nB1LoXsm013404@theraft.openend.se>
Message-ID: <b654cd2e0912011402g5c17741bufa7bff39159932dc@mail.gmail.com>

On Tue, Dec 1, 2009 at 3:50 PM, Laura Creighton <lac at openend.se> wrote:

> Had you oranised the poll this way, you would have found me in the
> 'ratings prohibited/comments opt-in' camp.  So, of course I think
> that allowing package authors to opt-out is a good idea.
>
> But I think that getting rid of the ratings is is also important.
>

Do you have an opinion on my proposal for a different (non-numeric) rating
system?
http://mail.python.org/pipermail/catalog-sig/2009-November/002410.html

-- 
Ian Bicking  |  http://blog.ianbicking.org  |
http://topplabs.org/civichacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20091201/a2b7d6d2/attachment.htm>

From martin at v.loewis.de  Tue Dec  1 23:06:08 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 01 Dec 2009 23:06:08 +0100
Subject: [Catalog-sig] Poll results
In-Reply-To: <005e01ca72d0$5c63d150$152b73f0$@net>
References: <4B157106.6000705@v.loewis.de>
	<005e01ca72d0$5c63d150$152b73f0$@net>
Message-ID: <4B159350.6070500@v.loewis.de>

> Can we switch to using Disqus (http://disqus.com/) or similar service that
> is a little easier on the eyes (and has some moderation tools, etc etc)?

I wouldn't know how to do that, and I'm not sure what it means (i.e. how
the end result would look and work like). So somebody would need to help
with that.

Regards,
Martin

From ianb at colorstudy.com  Tue Dec  1 23:23:52 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 1 Dec 2009 16:23:52 -0600
Subject: [Catalog-sig] Poll results
In-Reply-To: <4B159350.6070500@v.loewis.de>
References: <4B157106.6000705@v.loewis.de>
	<005e01ca72d0$5c63d150$152b73f0$@net> 
	<4B159350.6070500@v.loewis.de>
Message-ID: <b654cd2e0912011423u1cf8a70bt8c2309ee13e42f07@mail.gmail.com>

On Tue, Dec 1, 2009 at 4:06 PM, "Martin v. L?wis" <martin at v.loewis.de>wrote:

> > Can we switch to using Disqus (http://disqus.com/) or similar service
> that
> > is a little easier on the eyes (and has some moderation tools, etc etc)?
>
> I wouldn't know how to do that, and I'm not sure what it means (i.e. how
> the end result would look and work like). So somebody would need to help
> with that.
>

I haven't implemented Disqus before, but I think it is just a matter of
embedding some Javascript/HTML in each page.

I'm not sure it's a good idea.  While I agree the current system really
needs some UI work, that work isn't very extensive (just some small layout
changes and CSS).  But it uses the existing PyPI auth system, includes
ratings, and makes it possible to implement PyPI-specific details (like
using package author information in the system, or relating comments to
versions in different ways).  I don't think we want to encourage comments to
become a discussion forum, so the features Disqus offers don't seem that
applicable.

-- 
Ian Bicking  |  http://blog.ianbicking.org  |
http://topplabs.org/civichacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20091201/fc946626/attachment.htm>

From mal at egenix.com  Wed Dec  2 11:08:20 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 02 Dec 2009 11:08:20 +0100
Subject: [Catalog-sig] Poll results
In-Reply-To: <4B157106.6000705@v.loewis.de>
References: <4B157106.6000705@v.loewis.de>
Message-ID: <4B163C94.3070506@egenix.com>

"Martin v. L?wis" wrote:
> The poll is now closed, with these results
> 
> Allow ratings and comments on all packages (status quo)	237
> Allow package owners to disallow comments (ratings unmodified).	139
> Allow comments, but only send them to package owners (ratings
> unmodified).	33
> Disallow comments (ratings unmodified).	24
> Disallow ratings and comments (status three months ago).	88
> 
> My interpretation is that the result is inconclusive. A clear majority
> does want a comment facility (in some form); another (not so clear)
> majority wants to see something changed.
> 
> So it might be best to implement what appears as middle-ground,
> i.e. allow package authors to opt out of comments.
> 
> Opinions?

Same as before the poll:

1. Add comment opt-in/opt-out for authors
2. Add rating opt-in/opt-out for authors
3. Disallow anonymous ratings, i.e. show the rating given by
   a user

and some more as a result of all the discussion around the poll:

4. Allow comment without rating
5. Allow rating without comment

With those features, package authors can implement most of the
poll's options, except for the "only send comments to authors"
which I find a bit strange, since the package pages already
list an email address for this purpose.

That said, I still believe that this whole comment and rating
system on PyPI is not very helpful. The needed developer and
admin time to maintain such a system is better invested
elsewhere.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 02 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From ziade.tarek at gmail.com  Wed Dec  2 15:49:01 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 2 Dec 2009 15:49:01 +0100
Subject: [Catalog-sig] New fields in the Metadata for PyPI
Message-ID: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>

Hello

As suggested here, then discussed at Distutils-SIG,  I would like to
propose the addition of two more fields for the
upcoming Metadata 1.2 (PEP 345) that could be used at PyPI on projects pages.

"Repository-Browse-URL"
    A string containing the URL for the package's browsable
repository. It can be any url of the repository
    (trunk, branch, tags) as long as it can be browsed from a web browser.

  Example:
     http://svn.python.org/view/python/trunk

"Bug-Tracker-URL"
  A string containing the URL for the package's bug tracker.

  Example:
     http://bugs.python.org/


Other fields were proposed, but were controversial. You can follow the
latest discussions at distutils-sig about them,

If these fields are added, PyPI could display those links and offer a
standard way for end users to interact with the projects
maintainers, besides the "comment/rating" feature.

Regards
Tarek

From szybalski at gmail.com  Wed Dec  2 16:08:19 2009
From: szybalski at gmail.com (Lukasz Szybalski)
Date: Wed, 2 Dec 2009 09:08:19 -0600
Subject: [Catalog-sig] rst not rendering
In-Reply-To: <4AD040C4.7090808@v.loewis.de>
References: <804e5c70910092037h49801e7cxc314aa597c407646@mail.gmail.com>
	<4AD040C4.7090808@v.loewis.de>
Message-ID: <804e5c70912020708r7502f2eaqcb39da442f4b1dcf@mail.gmail.com>

On Sat, Oct 10, 2009 at 2:07 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> Any idea how to test rst so it renders properly. This rst displays
>> just fine in moinmoin, so is there anything special about Pypi as far
>> as rendering?
>
> You can try rendering it locally, with the function processDescription
> in
>
> https://svn.python.org/packages/trunk/pypi/store.py
>
I've checked that out but I can't still get it to render properly.

I found 2 issues possibly.

1. when you do python setup.py bdist
the PKG-INFO has the description but it has 8 spaces in front of every
line. If a description had a space in the beginning of the line(for
tab) it is not there anymore, but rather any space is replaced by the
initial 8 spaces. This means your alignment will be off. This causes
another problem; if you remove the space and replace it with initial 8
spaces, what happens to the lines like this:

this is a code::
[space]some code here

Since above line requires a space for it to be rendered properly I
don't see how this will work for anybody.

2. Even if I copy paste my original docstring pypi still doesn't
render it. moinoin does, rst render does
(http://www.tele3.cz/jbar/rest/rest.html).


Any help on this would be welcomed. 3 out of 4 packages I have don't
render, and the one that does is very short.

Thanks,
Lucas



> Regards,
> Martin
>



-- 
Setup CalendarServer for your company.
http://lucasmanual.com/mywiki/CalendarServer
Automotive Recall Database - See if you vehicle has a recall
http://lucasmanual.com/recall
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PKG-INFO
Type: application/octet-stream
Size: 10825 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20091202/1cf80c4a/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.py
Type: text/x-python
Size: 10406 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20091202/1cf80c4a/attachment-0001.py>

From martin at v.loewis.de  Wed Dec  2 16:33:21 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 02 Dec 2009 16:33:21 +0100
Subject: [Catalog-sig] rst not rendering
In-Reply-To: <804e5c70912020708r7502f2eaqcb39da442f4b1dcf@mail.gmail.com>
References: <804e5c70910092037h49801e7cxc314aa597c407646@mail.gmail.com>	<4AD040C4.7090808@v.loewis.de>
	<804e5c70912020708r7502f2eaqcb39da442f4b1dcf@mail.gmail.com>
Message-ID: <4B1688C1.8020606@v.loewis.de>

> Any help on this would be welcomed.

I took your setup.py, renamed the package, and uploaded it to

http://pypi.python.org/pypi/datahub_mvl

What exactly is incorrect about this page?

Regards,
Martin

From szybalski at gmail.com  Wed Dec  2 16:40:41 2009
From: szybalski at gmail.com (Lukasz Szybalski)
Date: Wed, 2 Dec 2009 09:40:41 -0600
Subject: [Catalog-sig] rst not rendering
In-Reply-To: <4B1688C1.8020606@v.loewis.de>
References: <804e5c70910092037h49801e7cxc314aa597c407646@mail.gmail.com>
	<4AD040C4.7090808@v.loewis.de>
	<804e5c70912020708r7502f2eaqcb39da442f4b1dcf@mail.gmail.com>
	<4B1688C1.8020606@v.loewis.de>
Message-ID: <804e5c70912020740td1ed48dpf5d1b1d2eaf5fe2d@mail.gmail.com>

On Wed, Dec 2, 2009 at 9:33 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> Any help on this would be welcomed.
>
> I took your setup.py, renamed the package, and uploaded it to
>
> http://pypi.python.org/pypi/datahub_mvl
>
> What exactly is incorrect about this page?

nothing in yours...
http://pypi.python.org/pypi/datahub_mvl

but mine?
http://pypi.python.org/pypi/datahub/0.8.90dev


Thanks,
Luca

From martin at v.loewis.de  Wed Dec  2 16:43:56 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 02 Dec 2009 16:43:56 +0100
Subject: [Catalog-sig] rst not rendering
In-Reply-To: <804e5c70912020740td1ed48dpf5d1b1d2eaf5fe2d@mail.gmail.com>
References: <804e5c70910092037h49801e7cxc314aa597c407646@mail.gmail.com>	
	<4AD040C4.7090808@v.loewis.de>	
	<804e5c70912020708r7502f2eaqcb39da442f4b1dcf@mail.gmail.com>	
	<4B1688C1.8020606@v.loewis.de>
	<804e5c70912020740td1ed48dpf5d1b1d2eaf5fe2d@mail.gmail.com>
Message-ID: <4B168B3C.8050809@v.loewis.de>

>> What exactly is incorrect about this page?
> 
> nothing in yours...
> http://pypi.python.org/pypi/datahub_mvl
> 
> but mine?
> http://pypi.python.org/pypi/datahub/0.8.90dev

Well, I used your setup.py literally, and just did "python setup.py
register". How did you get the release registered?

Regards,
Martin

From stephenemslie at gmail.com  Wed Dec  2 16:57:24 2009
From: stephenemslie at gmail.com (Stephen Emslie)
Date: Wed, 2 Dec 2009 15:57:24 +0000
Subject: [Catalog-sig] rst not rendering
In-Reply-To: <4B168B3C.8050809@v.loewis.de>
References: <804e5c70910092037h49801e7cxc314aa597c407646@mail.gmail.com> 
	<4AD040C4.7090808@v.loewis.de>
	<804e5c70912020708r7502f2eaqcb39da442f4b1dcf@mail.gmail.com> 
	<4B1688C1.8020606@v.loewis.de>
	<804e5c70912020740td1ed48dpf5d1b1d2eaf5fe2d@mail.gmail.com> 
	<4B168B3C.8050809@v.loewis.de>
Message-ID: <51f97e530912020757w9eaac40l851a959605659f69@mail.gmail.com>

This looks a lot like a bug I opened against distutils:
http://bugs.python.org/issue1923

here's the related post: http://markmail.org/message/us3aqqixgqmzv3tv


It would be *fantastic* to finally tackle this problem.

Stephen Emslie

On Wed, Dec 2, 2009 at 3:43 PM, "Martin v. L?wis" <martin at v.loewis.de>wrote:

> >> What exactly is incorrect about this page?
> >
> > nothing in yours...
> > http://pypi.python.org/pypi/datahub_mvl
> >
> > but mine?
> > http://pypi.python.org/pypi/datahub/0.8.90dev
>
> Well, I used your setup.py literally, and just did "python setup.py
> register". How did you get the release registered?
>
> Regards,
> Martin
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20091202/ec772896/attachment.htm>

From szybalski at gmail.com  Wed Dec  2 16:59:31 2009
From: szybalski at gmail.com (Lukasz Szybalski)
Date: Wed, 2 Dec 2009 09:59:31 -0600
Subject: [Catalog-sig] rst not rendering
In-Reply-To: <4B168B3C.8050809@v.loewis.de>
References: <804e5c70910092037h49801e7cxc314aa597c407646@mail.gmail.com>
	<4AD040C4.7090808@v.loewis.de>
	<804e5c70912020708r7502f2eaqcb39da442f4b1dcf@mail.gmail.com>
	<4B1688C1.8020606@v.loewis.de>
	<804e5c70912020740td1ed48dpf5d1b1d2eaf5fe2d@mail.gmail.com>
	<4B168B3C.8050809@v.loewis.de>
Message-ID: <804e5c70912020759r4de81e89r33b295152669e6ef@mail.gmail.com>

On Wed, Dec 2, 2009 at 9:43 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>> What exactly is incorrect about this page?
>>
>> nothing in yours...
>> http://pypi.python.org/pypi/datahub_mvl
>>
>> but mine?
>> http://pypi.python.org/pypi/datahub/0.8.90dev
>
> Well, I used your setup.py literally, and just did "python setup.py
> register". How did you get the release registered?
>

That might be the difference then...

I only did python setup.py register the first time and then I was just
using the python setup.py sdist upload.

python setup.py register
python setup.py sdist upload


When I do python setup.py register again;  the new "working"
description gets uploaded correctly.

python setup.py register



I just did another package and that seems to work.

Thanks for your help.
Lucas


ps. I'm not sure why python setup.py register works but "Or upload
your PKG-INFO file (generated by distutils) here:
PKG-INFO file: 	" does not.

From martin at v.loewis.de  Wed Dec  2 17:16:01 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 02 Dec 2009 17:16:01 +0100
Subject: [Catalog-sig] rst not rendering
In-Reply-To: <804e5c70912020759r4de81e89r33b295152669e6ef@mail.gmail.com>
References: <804e5c70910092037h49801e7cxc314aa597c407646@mail.gmail.com>	
	<4AD040C4.7090808@v.loewis.de>	
	<804e5c70912020708r7502f2eaqcb39da442f4b1dcf@mail.gmail.com>	
	<4B1688C1.8020606@v.loewis.de>	
	<804e5c70912020740td1ed48dpf5d1b1d2eaf5fe2d@mail.gmail.com>	
	<4B168B3C.8050809@v.loewis.de>
	<804e5c70912020759r4de81e89r33b295152669e6ef@mail.gmail.com>
Message-ID: <4B1692C1.70801@v.loewis.de>

> ps. I'm not sure why python setup.py register works but "Or upload
> your PKG-INFO file (generated by distutils) here:
> PKG-INFO file: 	" does not.

setup.py register doesn't use the PKG-INFO file at all.

ISTM that PKG-INFO files don't support ReST, period.

Regards,
Martin

From martin at v.loewis.de  Wed Dec  2 17:32:16 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 02 Dec 2009 17:32:16 +0100
Subject: [Catalog-sig] rst not rendering
In-Reply-To: <804e5c70912020759r4de81e89r33b295152669e6ef@mail.gmail.com>
References: <804e5c70910092037h49801e7cxc314aa597c407646@mail.gmail.com>	<4AD040C4.7090808@v.loewis.de>	<804e5c70912020708r7502f2eaqcb39da442f4b1dcf@mail.gmail.com>	<4B1688C1.8020606@v.loewis.de>	<804e5c70912020740td1ed48dpf5d1b1d2eaf5fe2d@mail.gmail.com>	<4B168B3C.8050809@v.loewis.de>
	<804e5c70912020759r4de81e89r33b295152669e6ef@mail.gmail.com>
Message-ID: <4B169690.3010603@v.loewis.de>

> That might be the difference then...
> 
> I only did python setup.py register the first time and then I was just
> using the python setup.py sdist upload.
> 
> python setup.py register
> python setup.py sdist upload

Hmm. When I do "sdist upload", it also works fine for me.

Regards,
Martin


From szybalski at gmail.com  Wed Dec  2 18:19:43 2009
From: szybalski at gmail.com (Lukasz Szybalski)
Date: Wed, 2 Dec 2009 11:19:43 -0600
Subject: [Catalog-sig] rst not rendering
In-Reply-To: <4B169690.3010603@v.loewis.de>
References: <804e5c70910092037h49801e7cxc314aa597c407646@mail.gmail.com>
	<4AD040C4.7090808@v.loewis.de>
	<804e5c70912020708r7502f2eaqcb39da442f4b1dcf@mail.gmail.com>
	<4B1688C1.8020606@v.loewis.de>
	<804e5c70912020740td1ed48dpf5d1b1d2eaf5fe2d@mail.gmail.com>
	<4B168B3C.8050809@v.loewis.de>
	<804e5c70912020759r4de81e89r33b295152669e6ef@mail.gmail.com>
	<4B169690.3010603@v.loewis.de>
Message-ID: <804e5c70912020919g28222865ped7440cf2b2fcef1@mail.gmail.com>

On Wed, Dec 2, 2009 at 10:32 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> That might be the difference then...
>>
>> I only did python setup.py register the first time and then I was just
>> using the python setup.py sdist upload.
>>
>> python setup.py register
>> python setup.py sdist upload
>
> Hmm. When I do "sdist upload", it also works fine for me.
>

I noticed that to. I'm not sure, why it didn't initially work. I'll
test this more in the next release, to see if the sdist upload will
not render. I'll let you know if its not doing it correctly.

>From now on I will use python setup.py register to update description on pypi.

Thanks,
Lucas

From chris at simplistix.co.uk  Wed Dec  2 18:22:35 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 02 Dec 2009 17:22:35 +0000
Subject: [Catalog-sig] Poll results
In-Reply-To: <4B1591FA.1090700@v.loewis.de>
References: <4B157106.6000705@v.loewis.de>	<200912012150.nB1LoXsm013404@theraft.openend.se>
	<4B1591FA.1090700@v.loewis.de>
Message-ID: <4B16A25B.7090204@simplistix.co.uk>

Martin v. L?wis wrote:
>> But I think that getting rid of the ratings is is also important.
> 
> I don't think this is consensus.

That's because the poll didn't really allow people to clearly express 
their views, which was the point of what Laura was saying.

I, too, would like to see ratings be opt-out, but for me it was *much* 
more important to make comments opt-out, so I had to cast my vote 
appropriately.

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From chris at simplistix.co.uk  Wed Dec  2 18:28:27 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 02 Dec 2009 17:28:27 +0000
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>
Message-ID: <4B16A3BB.4030407@simplistix.co.uk>

Tarek Ziad? wrote:
> Hello
> 
> As suggested here, then discussed at Distutils-SIG,  I would like to
> propose the addition of two more fields for the
> upcoming Metadata 1.2 (PEP 345) that could be used at PyPI on projects pages.
> 
> "Repository-Browse-URL"
>     A string containing the URL for the package's browsable
> repository. It can be any url of the repository
>     (trunk, branch, tags) as long as it can be browsed from a web browser.
> 
>   Example:
>      http://svn.python.org/view/python/trunk
> 
> "Bug-Tracker-URL"
>   A string containing the URL for the package's bug tracker.
> 
>   Example:
>      http://bugs.python.org/
> 
> 
> Other fields were proposed, but were controversial. 

The only controversial ones were Change-Log-URL and, at a push, 
Documentation-URL (although it was only you who even queried that ;-), 
so why have Repository-URL and Mailing-List-URL been abandoned?

None of these are mandatory, and I don't see what harm could be done. I 
*do* see a *lot* of good that could be done if all of the ones under 
discussion were added.

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From mal at egenix.com  Wed Dec  2 18:43:20 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 02 Dec 2009 18:43:20 +0100
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>
Message-ID: <4B16A738.6030304@egenix.com>

Tarek Ziad? wrote:
> Hello
> 
> As suggested here, then discussed at Distutils-SIG,  I would like to
> propose the addition of two more fields for the
> upcoming Metadata 1.2 (PEP 345) that could be used at PyPI on projects pages.
> 
> "Repository-Browse-URL"
>     A string containing the URL for the package's browsable
> repository. It can be any url of the repository
>     (trunk, branch, tags) as long as it can be browsed from a web browser.
> 
>   Example:
>      http://svn.python.org/view/python/trunk
> 
> "Bug-Tracker-URL"
>   A string containing the URL for the package's bug tracker.
> 
>   Example:
>      http://bugs.python.org/
> 
> 
> Other fields were proposed, but were controversial. You can follow the
> latest discussions at distutils-sig about them,
> 
> If these fields are added, PyPI could display those links and offer a
> standard way for end users to interact with the projects
> maintainers, besides the "comment/rating" feature.

While more structured meta-data is generally better than less,
I wonder why we have to add URLs for all these things.

The home page of a project will usually provide the URLs
in some form already and if there is no home page, the
long description can be used.

A valid argument for the duplication would be to provide the user
with faster and more standardized access to those resources.
OTOH, they don't really mean anything for computerized consumption.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 02 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From ianb at colorstudy.com  Wed Dec  2 18:51:26 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 2 Dec 2009 11:51:26 -0600
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <4B16A3BB.4030407@simplistix.co.uk>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com> 
	<4B16A3BB.4030407@simplistix.co.uk>
Message-ID: <b654cd2e0912020951o350b8494n7dd7357d5ccd4fb1@mail.gmail.com>

On Wed, Dec 2, 2009 at 11:28 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> The only controversial ones were Change-Log-URL and, at a push,
> Documentation-URL (although it was only you who even queried that ;-), so
> why have Repository-URL and Mailing-List-URL been abandoned?

I didn't notice Documentation-URL in the discussion.  I would like
that, I frequently have a hard time finding a link to a project's
documentation.

I objected to Repository-URL because it was unclear what function it
served.  A URL alone is not sufficient to check out a project.  A
"checkout command" would be more useful, but didn't seem enough
useful.

I'd like to see how the PyPI UI works out.  I can also imagine a more
extensible setup, like:

Project-URLs: documentation=http://myproject.org/docs/
    repository=http://myproject.org/svn/
    mailing list=http://googlegroups.com/groups/myproject

And then display those in some simple structured way.  The text is the
text of the anchor, nothing more, nothing less.  Automated tools might
find it hard to parse these, and it's possible some people would
choose "docs" instead of "documentation".  But you could add blog, or
twitter, or tracker, or forum, or IRC, etc.  I doubt it would get too
chaotic.

With respect to Marc-Andre's response: I think there's some value in
normalizing the presentation of projects.  CPAN is really a rather
extreme example of this.  I personally have a hard time finding some
of these links in many projects.

-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker

From robert.kern at gmail.com  Wed Dec  2 19:17:59 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 02 Dec 2009 12:17:59 -0600
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <4B16A738.6030304@egenix.com>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>
	<4B16A738.6030304@egenix.com>
Message-ID: <hf6b0o$7np$1@ger.gmane.org>

On 2009-12-02 11:43 AM, M.-A. Lemburg wrote:

> While more structured meta-data is generally better than less,
> I wonder why we have to add URLs for all these things.
>
> The home page of a project will usually provide the URLs
> in some form already and if there is no home page, the
> long description can be used.
>
> A valid argument for the duplication would be to provide the user
> with faster and more standardized access to those resources.
> OTOH, they don't really mean anything for computerized consumption.

I believe it was my comment in the PyPI comments thread on python-dev that 
inspired this idea. I suggested the Repository-Browse-URL as a way for PyPI 
users to very quickly (with one click) view the source code of the project in 
order to evaluate it quickly. Personally, I get a much better idea of the 
suitability of a project from a quick browse of the code than short comments and 
ratings. Having it as a separate item in the official metadata encourages 
authors to make it available and allows PyPI to put it in a standard place that 
PyPI users can navigate to quickly.

The Bug-Tracker-URL was not in my suggestion, but the logic supporting it is 
somewhat similar. Some authors want to make sure that bug reports that might 
otherwise incorrectly go in the PyPI comments go to the specified bug tracker 
instead.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From martin at v.loewis.de  Wed Dec  2 20:54:11 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 02 Dec 2009 20:54:11 +0100
Subject: [Catalog-sig] Poll results
In-Reply-To: <4B16A25B.7090204@simplistix.co.uk>
References: <4B157106.6000705@v.loewis.de>	<200912012150.nB1LoXsm013404@theraft.openend.se>	<4B1591FA.1090700@v.loewis.de>
	<4B16A25B.7090204@simplistix.co.uk>
Message-ID: <4B16C5E3.20201@v.loewis.de>

Chris Withers wrote:
> Martin v. L?wis wrote:
>>> But I think that getting rid of the ratings is is also important.
>>
>> I don't think this is consensus.
> 
> That's because the poll didn't really allow people to clearly express
> their views, which was the point of what Laura was saying.
> 
> I, too, would like to see ratings be opt-out,

I think what Laura wants is different: she doesn't want package owners
to be able to opt out of ratings (for their own sake), but the feature
be removed altogether, for the sake of users which she considers misled
by ratings (IIUC).

Regards,
Martin

From martin at v.loewis.de  Wed Dec  2 21:21:48 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 02 Dec 2009 21:21:48 +0100
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <b654cd2e0912020951o350b8494n7dd7357d5ccd4fb1@mail.gmail.com>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>
	<4B16A3BB.4030407@simplistix.co.uk>
	<b654cd2e0912020951o350b8494n7dd7357d5ccd4fb1@mail.gmail.com>
Message-ID: <4B16CC5C.7050008@v.loewis.de>

> I'd like to see how the PyPI UI works out.  I can also imagine a more
> extensible setup, like:
> 
> Project-URLs: documentation=http://myproject.org/docs/
>     repository=http://myproject.org/svn/
>     mailing list=http://googlegroups.com/groups/myproject

I think this also points to an important detail: are they per package,
or per release?

It may seem irrelevant, as it shouldn't hurt when they are per release
(so what?) - but it does: when you change the bug tracker, will it
retroactively also change for all past releases?

So for the repository, mailing list, bug tracker, I think that they
should be per project, not per release. Whether it is then useful to
put them into PKG-INFO, I don't know.

OTOH, the documentation URL often *is* per release, for many projects
(although there might be a documentation root for the entire project,
and a URL for the "current" documentation).

Regards,
Martin


From ziade.tarek at gmail.com  Wed Dec  2 22:34:38 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 2 Dec 2009 22:34:38 +0100
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <4B16CC5C.7050008@v.loewis.de>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>
	<4B16A3BB.4030407@simplistix.co.uk>
	<b654cd2e0912020951o350b8494n7dd7357d5ccd4fb1@mail.gmail.com>
	<4B16CC5C.7050008@v.loewis.de>
Message-ID: <94bdd2610912021334j26bd9bddr189a298eb9ad01aa@mail.gmail.com>

On Wed, Dec 2, 2009 at 9:21 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> I'd like to see how the PyPI UI works out. ?I can also imagine a more
>> extensible setup, like:
>>
>> Project-URLs: documentation=http://myproject.org/docs/
>> ? ? repository=http://myproject.org/svn/
>> ? ? mailing list=http://googlegroups.com/groups/myproject

That would be a nice solution,

>
> I think this also points to an important detail: are they per package,
> or per release?
>
> It may seem irrelevant, as it shouldn't hurt when they are per release
> (so what?) - but it does: when you change the bug tracker, will it
> retroactively also change for all past releases?
>
> So for the repository, mailing list, bug tracker, I think that they
> should be per project, not per release. Whether it is then useful to
> put them into PKG-INFO, I don't know.

We have raised that problem some time ago, about the "Home-page" url that
could change in a new release, but old releases would keep the
previous one in PyPI.
That led to some bugs in some installers, because they were trying to
visit dead links.

So I think a way to handle this would be to cleary state in the PEP that some
metadata are per-project, and that the newest value always overrides
any previous value.

The fields that would be eligible are:

- Home-page
- Project-urls (or any field we will end up adding)

>
> OTOH, the documentation URL often *is* per release, for many projects
> (although there might be a documentation root for the entire project,
> and a URL for the "current" documentation).

But the project always wants to display the newest urls. For example, in Python
you have links to the latest installer, and documentation, whereas old versions
are archived and can be accessed only through a specific link "Old versions".

IOW, if PyPI display only keeps the latest home page for the project,
and the latest urls,
that should be enough for all projects : they can point in their own
documentation to
older documentation.

Regards
Tarek

From martin at v.loewis.de  Wed Dec  2 22:53:54 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 02 Dec 2009 22:53:54 +0100
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <94bdd2610912021334j26bd9bddr189a298eb9ad01aa@mail.gmail.com>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>	
	<4B16A3BB.4030407@simplistix.co.uk>	
	<b654cd2e0912020951o350b8494n7dd7357d5ccd4fb1@mail.gmail.com>	
	<4B16CC5C.7050008@v.loewis.de>
	<94bdd2610912021334j26bd9bddr189a298eb9ad01aa@mail.gmail.com>
Message-ID: <4B16E1F2.6060304@v.loewis.de>

> But the project always wants to display the newest urls.

Not at all. For some projects, it's more important to be conscious about
documentation versions than for others. For example

http://www.postgresql.org/docs/

asks you to make an explicit choice of version, and the URLs reflect
that. Likewise,

http://java.sun.com/javase/reference/api.jsp

asks you to select the version (even though more versions are available
than listed there).

For Python, it somewhat unfortunate that there is a tradition of
"newest documentation". When the documentation format changed, many
URLs broke - something that would not have happened when all URLs
had been versioned.

For another example,

http://docs.djangoproject.com/

defaults to the development version of the docs (through redirects), but
also has documentation sets for each release.

So if the PKG-INFO for Django 1.2 (say) would include a documentation
URL, I would expect that the Django authors want that to point to the
Django 1.2 documentation.

> IOW, if PyPI display only keeps the latest home page for the project,
> and the latest urls

But it doesn't: e.g.

http://pypi.python.org/pypi/PyUMLGraph

displays all non-hidden versions of the package. It defaults to the
most recent version only if all other versions are marked as hidden.

> that should be enough for all projects : they can point in their own
> documentation to older documentation.

I'm not sure package authors would like that.

Regards,
Martin

From ziade.tarek at gmail.com  Wed Dec  2 23:42:45 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 2 Dec 2009 23:42:45 +0100
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <4B16E1F2.6060304@v.loewis.de>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>
	<4B16A3BB.4030407@simplistix.co.uk>
	<b654cd2e0912020951o350b8494n7dd7357d5ccd4fb1@mail.gmail.com>
	<4B16CC5C.7050008@v.loewis.de>
	<94bdd2610912021334j26bd9bddr189a298eb9ad01aa@mail.gmail.com>
	<4B16E1F2.6060304@v.loewis.de>
Message-ID: <94bdd2610912021442w54c7a1d6r605d1e498770225a@mail.gmail.com>

2009/12/2 "Martin v. L?wis" <martin at v.loewis.de>:
[..]
> For Python, it somewhat unfortunate that there is a tradition of
> "newest documentation". When the documentation format changed, many
> URLs broke - something that would not have happened when all URLs
> had been versioned.

Are you suggesting that packages.python.org should be versioned ?

[..]
>> IOW, if PyPI display only keeps the latest home page for the project,
>> and the latest urls
>
> But it doesn't: e.g.
>
> http://pypi.python.org/pypi/PyUMLGraph
>
> displays all non-hidden versions of the package. It defaults to the
> most recent version only if all other versions are marked as hidden.

Hold on... marking the old versions as hidden is the default PyPI behavior.
You have shown a specific example here.

If you upload new versions, previous ones will be hidden by default,
and we are landing on the newest version. That's the vast majority of
the projects at PyPI
AFAIK.

>> that should be enough for all projects : they can point in their own
>> documentation to older documentation.
>
> I'm not sure package authors would like that.

I'm not sure what you mean.

AFAIK the new "packages.python.org" is not versioned: if I upload a
doc, the previous
one is gone.

On the long_description front, the default behavior is to display the
latest one, and if you are not logged in,
*there's no link to older versions*

See that page : http://pypi.python.org/pypi/distribute  (that's the
way most projects are presented)

But we are moving away from what I have proposed at the PEP level
here, and just discussing
the current PyPI behaviour:

    I have suggested that we should mark in the PEP some fields are
being per-project, and let
    PyPI display them on every pages related to that project.


Regards
Tarek

From ziade.tarek at gmail.com  Wed Dec  2 23:56:01 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 2 Dec 2009 23:56:01 +0100
Subject: [Catalog-sig] rst not rendering
In-Reply-To: <804e5c70912020919g28222865ped7440cf2b2fcef1@mail.gmail.com>
References: <804e5c70910092037h49801e7cxc314aa597c407646@mail.gmail.com>
	<4AD040C4.7090808@v.loewis.de>
	<804e5c70912020708r7502f2eaqcb39da442f4b1dcf@mail.gmail.com>
	<4B1688C1.8020606@v.loewis.de>
	<804e5c70912020740td1ed48dpf5d1b1d2eaf5fe2d@mail.gmail.com>
	<4B168B3C.8050809@v.loewis.de>
	<804e5c70912020759r4de81e89r33b295152669e6ef@mail.gmail.com>
	<4B169690.3010603@v.loewis.de>
	<804e5c70912020919g28222865ped7440cf2b2fcef1@mail.gmail.com>
Message-ID: <94bdd2610912021456n2cec00esea884faa4c471316@mail.gmail.com>

On Wed, Dec 2, 2009 at 6:19 PM, Lukasz Szybalski <szybalski at gmail.com> wrote:
> On Wed, Dec 2, 2009 at 10:32 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>> That might be the difference then...
>>>
>>> I only did python setup.py register the first time and then I was just
>>> using the python setup.py sdist upload.
>>>
>>> python setup.py register
>>> python setup.py sdist upload
>>
>> Hmm. When I do "sdist upload", it also works fine for me.
>>
>
> I noticed that to. I'm not sure, why it didn't initially work. I'll
> test this more in the next release, to see if the sdist upload will
> not render. I'll let you know if its not doing it correctly.
>
> From now on I will use python setup.py register to update description on pypi.

To make your life easier, you can test for reST compliancy like this:

$ python setup.py --long-description | rst2html.py > /dev/null

It will displays warnings and errors.

Notice that I have added in Distutils dev, the "check" command, that
also controls fields:

http://docs.python.org/dev/distutils/examples.html#checking-a-package

Regards
Tarek

From martin at v.loewis.de  Thu Dec  3 00:31:00 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 03 Dec 2009 00:31:00 +0100
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <94bdd2610912021442w54c7a1d6r605d1e498770225a@mail.gmail.com>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>	
	<4B16A3BB.4030407@simplistix.co.uk>	
	<b654cd2e0912020951o350b8494n7dd7357d5ccd4fb1@mail.gmail.com>	
	<4B16CC5C.7050008@v.loewis.de>	
	<94bdd2610912021334j26bd9bddr189a298eb9ad01aa@mail.gmail.com>	
	<4B16E1F2.6060304@v.loewis.de>
	<94bdd2610912021442w54c7a1d6r605d1e498770225a@mail.gmail.com>
Message-ID: <4B16F8B4.1090308@v.loewis.de>

Tarek Ziad? wrote:
> 2009/12/2 "Martin v. L?wis" <martin at v.loewis.de>:
> [..]
>> For Python, it somewhat unfortunate that there is a tradition of
>> "newest documentation". When the documentation format changed, many
>> URLs broke - something that would not have happened when all URLs
>> had been versioned.
> 
> Are you suggesting that packages.python.org should be versioned ?

No, I wasn't talking about packages.python.org at all, but about
docs.python.org. For packages.python.org, it's up to the individual
package to support versioned documentation.

> Hold on... marking the old versions as hidden is the default PyPI behavior.
> You have shown a specific example here.
> 
> If you upload new versions, previous ones will be hidden by default,
> and we are landing on the newest version. That's the vast majority of
> the projects at PyPI
> AFAIK.

For packages that have only one (visible) release, the whole discussion
of whether meta-data are per-package or per-release is pointless,
anyway. This is the simple case, and we can resolve it either way.

>>> that should be enough for all projects : they can point in their own
>>> documentation to older documentation.
>> I'm not sure package authors would like that.
> 
> I'm not sure what you mean.
> 
> AFAIK the new "packages.python.org" is not versioned: if I upload a
> doc, the previous
> one is gone.

That's completely up to you. If the new zip file contains the
documentation of all versions, you get multi-versioned documentation.
See, for example,

http://packages.python.org/zc.async/

> On the long_description front, the default behavior is to display the
> latest one

That's not true. If there are multiple visible releases, no release
is singled out.

> See that page : http://pypi.python.org/pypi/distribute  (that's the
> way most projects are presented)

That's because distribute has only one visible version. Just unhide
one of the older releases.

It would probably better if this URL redirected to

http://pypi.python.org/pypi/distribute/0.6.8

>     I have suggested that we should mark in the PEP some fields are
> being per-project, and let
>     PyPI display them on every pages related to that project.

And I'm fine with that, except that I believe that a documentation URL
(if supported) probably should be per release.

Regards,
Martin

From tjreedy at udel.edu  Thu Dec  3 00:46:47 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 02 Dec 2009 18:46:47 -0500
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <hf6b0o$7np$1@ger.gmane.org>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>	<4B16A738.6030304@egenix.com>
	<hf6b0o$7np$1@ger.gmane.org>
Message-ID: <hf6u97$b33$1@ger.gmane.org>

Robert Kern wrote:
> On 2009-12-02 11:43 AM, M.-A. Lemburg wrote:
> 
>> While more structured meta-data is generally better than less,
>> I wonder why we have to add URLs for all these things.
>>
>> The home page of a project will usually provide the URLs
>> in some form already and if there is no home page, the
>> long description can be used.
>>
>> A valid argument for the duplication would be to provide the user
>> with faster and more standardized access to those resources.
>> OTOH, they don't really mean anything for computerized consumption.
> 
> I believe it was my comment in the PyPI comments thread on python-dev 
> that inspired this idea. I suggested the Repository-Browse-URL as a way 
> for PyPI users to very quickly (with one click) view the source code of 
> the project in order to evaluate it quickly. Personally, I get a much 
> better idea of the suitability of a project from a quick browse of the 
> code than short comments and ratings. Having it as a separate item in 
> the official metadata encourages authors to make it available and allows 
> PyPI to put it in a standard place that PyPI users can navigate to quickly.
> 
> The Bug-Tracker-URL was not in my suggestion, but the logic supporting 
> it is somewhat similar. Some authors want to make sure that bug reports 
> that might otherwise incorrectly go in the PyPI comments go to the 
> specified bug tracker instead.

As a user, I like the idea of having a few links staring me in the face 
in a standardized place and order, instead of having to possibly 'wade 
through' an idiosyncratic home page. 3 or 4 should be enough.



From ziade.tarek at gmail.com  Thu Dec  3 01:16:26 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 3 Dec 2009 01:16:26 +0100
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <4B16F8B4.1090308@v.loewis.de>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>
	<4B16A3BB.4030407@simplistix.co.uk>
	<b654cd2e0912020951o350b8494n7dd7357d5ccd4fb1@mail.gmail.com>
	<4B16CC5C.7050008@v.loewis.de>
	<94bdd2610912021334j26bd9bddr189a298eb9ad01aa@mail.gmail.com>
	<4B16E1F2.6060304@v.loewis.de>
	<94bdd2610912021442w54c7a1d6r605d1e498770225a@mail.gmail.com>
	<4B16F8B4.1090308@v.loewis.de>
Message-ID: <94bdd2610912021616p2dae65b5k4a859141ae0a0e23@mail.gmail.com>

2009/12/3 "Martin v. L?wis" <martin at v.loewis.de>:
>> On the long_description front, the default behavior is to display the
>> latest one

> That's not true. If there are multiple visible releases, no release
> is singled out.

What ? the statement "the default behavior is to display the latest
one" *is* true .. :)

You need to manually unhide some other releases to come up with
several displayed
versions. Manual change implies that it's not the default behavior.

[..]
>
>> See that page : http://pypi.python.org/pypi/distribute ?(that's the
>> way most projects are presented)
>
> That's because distribute has only one visible version. Just unhide
> one of the older releases.
>

Again, only *one* visible version is the default behavior.

If you don't change this manually, it'll display the latest and hide
the others, everytime
you register and upload a release at PyPI. As, most projects do.
Distribute was just an example.

Regards
Tarek

From martin at v.loewis.de  Thu Dec  3 09:58:10 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 03 Dec 2009 09:58:10 +0100
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <94bdd2610912021616p2dae65b5k4a859141ae0a0e23@mail.gmail.com>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>	
	<4B16A3BB.4030407@simplistix.co.uk>	
	<b654cd2e0912020951o350b8494n7dd7357d5ccd4fb1@mail.gmail.com>	
	<4B16CC5C.7050008@v.loewis.de>	
	<94bdd2610912021334j26bd9bddr189a298eb9ad01aa@mail.gmail.com>	
	<4B16E1F2.6060304@v.loewis.de>	
	<94bdd2610912021442w54c7a1d6r605d1e498770225a@mail.gmail.com>	
	<4B16F8B4.1090308@v.loewis.de>
	<94bdd2610912021616p2dae65b5k4a859141ae0a0e23@mail.gmail.com>
Message-ID: <4B177DA2.30108@v.loewis.de>

> If you don't change this manually, it'll display the latest and hide
> the others, everytime
> you register and upload a release at PyPI. As, most projects do.
> Distribute was just an example.

Alternatively, you can also uncheck the auto-hide box on the package,

I would agree that auto-hide is the default. I disagree that "display
the latest version" is the "default behavior".

Regards,
Martin

From mal at egenix.com  Thu Dec  3 12:34:57 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 03 Dec 2009 12:34:57 +0100
Subject: [Catalog-sig] Extending the package meta-data with more
 detailed download information
In-Reply-To: <4B0A693B.50304@v.loewis.de>
References: <4B051FEC.3050905@egenix.com>	<94bdd2610911220751k5ad019fek31d3b87783aba852@mail.gmail.com>	<4B0A548E.1050100@egenix.com>	<4B0A5A00.1000500@v.loewis.de>
	<4B0A637E.8090601@egenix.com> <4B0A693B.50304@v.loewis.de>
Message-ID: <4B17A261.6010600@egenix.com>

"Martin v. L?wis" wrote:
>> I'd like to extend PyPI to also provide support for listing
>> files on other servers as well as making it possible for
>> the package manager tools to automatically select the right
>> installation file for the intended target platform.
> 
> In such a scenario, how do people get the files onto the server?
> Will they typically know the URLs of the files upfront?

Yes.

> ISTM that it would be better to be able to add new such URLs one
> by one, e.g. through a web form.

I don't think that's a feasible approach, e.g. eGenix typically
creates around 50 distribution files for every single release
of a product.

In most cases, only the version number changes, so this can
easily be done using sed or in a text editor.

I agree, though, that an RPC interface would also be possible
to automate such a registration process, e.g. via a new
register_distribution command.

>> To enhance the user experience we were thinking about providing
>> a tool to automate the whole process. However, if PIP can
>> provide this functionality based on the extended distribution
>> file information, we'd rather point our users to PIP.
> 
> If the use case is automated download, I think the list of
> properties should be restricted to the set of properties relevant
> for that use case.

The properties I mentioned are all necessary to get reliable
automatic downloads working. The other properties (e.g. comments)
are already available in the database.

In general, I don't see a problem with having a few more
properties of a distribution file. They don't all have to be
displayed in the PyPI GUI (which is typically used by users
rather than automated scripts), but can well serve package
managers which need more detail to make reliable decisions.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 03 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From martin at v.loewis.de  Thu Dec  3 12:44:19 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 03 Dec 2009 12:44:19 +0100
Subject: [Catalog-sig] Extending the package meta-data with more
 detailed download information
In-Reply-To: <4B17A261.6010600@egenix.com>
References: <4B051FEC.3050905@egenix.com>	<94bdd2610911220751k5ad019fek31d3b87783aba852@mail.gmail.com>	<4B0A548E.1050100@egenix.com>	<4B0A5A00.1000500@v.loewis.de>
	<4B0A637E.8090601@egenix.com> <4B0A693B.50304@v.loewis.de>
	<4B17A261.6010600@egenix.com>
Message-ID: <4B17A493.3080506@v.loewis.de>

>> ISTM that it would be better to be able to add new such URLs one
>> by one, e.g. through a web form.
> 
> I don't think that's a feasible approach, e.g. eGenix typically
> creates around 50 distribution files for every single release
> of a product.
> 
> In most cases, only the version number changes, so this can
> easily be done using sed or in a text editor.
> 
> I agree, though, that an RPC interface would also be possible
> to automate such a registration process, e.g. via a new
> register_distribution command.

Notice that there really isn't much difference between a form
and an RPC interface. The register and upload commands exclusively
use "forms".

Regards,
Martin

From mal at egenix.com  Thu Dec  3 13:18:29 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 03 Dec 2009 13:18:29 +0100
Subject: [Catalog-sig] Extending the package meta-data with more
 detailed download information
In-Reply-To: <4B17A493.3080506@v.loewis.de>
References: <4B051FEC.3050905@egenix.com>	<94bdd2610911220751k5ad019fek31d3b87783aba852@mail.gmail.com>	<4B0A548E.1050100@egenix.com>	<4B0A5A00.1000500@v.loewis.de>	<4B0A637E.8090601@egenix.com>
	<4B0A693B.50304@v.loewis.de>	<4B17A261.6010600@egenix.com>
	<4B17A493.3080506@v.loewis.de>
Message-ID: <4B17AC95.8080709@egenix.com>

"Martin v. L?wis" wrote:
>>> ISTM that it would be better to be able to add new such URLs one
>>> by one, e.g. through a web form.
>>
>> I don't think that's a feasible approach, e.g. eGenix typically
>> creates around 50 distribution files for every single release
>> of a product.
>>
>> In most cases, only the version number changes, so this can
>> easily be done using sed or in a text editor.
>>
>> I agree, though, that an RPC interface would also be possible
>> to automate such a registration process, e.g. via a new
>> register_distribution command.
> 
> Notice that there really isn't much difference between a form
> and an RPC interface. The register and upload commands exclusively
> use "forms".

Technically, that's true. However, a web form is normally meant for
web users to work with and in this case, you can hardly expect a
user to enter all those details by hand. It would also be error-prone.
That's why I used the term RPC.

I was actually thinking of using the XML-RPC interface to PyPI, but
the REST interface would do just as well.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 03 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From deroiste at syslab.com  Thu Dec  3 15:22:40 2009
From: deroiste at syslab.com (=?ISO-8859-1?Q?Cillian_de_R=F3iste?=)
Date: Thu, 03 Dec 2009 15:22:40 +0100
Subject: [Catalog-sig] Request for additional classifier for European Union
 Public License (EUPL)
Message-ID: <4B17C9B0.7060400@syslab.com>

Hi,

I hope this is the correct place to ask ...

We would like to use a classifier for EUPL licensed work:
EUPL is an OSI approved F/OSS license which is approved by the European 
Commission:
http://ec.europa.eu/idabc/eupl.

"License :: OSI Approved :: European Union Public License (EUPL)"

Thanks,
Cillian



From martin at v.loewis.de  Thu Dec  3 20:06:21 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 03 Dec 2009 20:06:21 +0100
Subject: [Catalog-sig] Request for additional classifier for European
 Union Public License (EUPL)
In-Reply-To: <4B17C9B0.7060400@syslab.com>
References: <4B17C9B0.7060400@syslab.com>
Message-ID: <4B180C2D.6050502@v.loewis.de>

> We would like to use a classifier for EUPL licensed work:
> EUPL is an OSI approved F/OSS license which is approved by the European
> Commission:
> http://ec.europa.eu/idabc/eupl.
> 
> "License :: OSI Approved :: European Union Public License (EUPL)"

Can you name a few packages that would be classified under this classifier?

Regards,
Martin

From ianb at colorstudy.com  Thu Dec  3 21:43:01 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 3 Dec 2009 14:43:01 -0600
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <4B16CC5C.7050008@v.loewis.de>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com> 
	<4B16A3BB.4030407@simplistix.co.uk>
	<b654cd2e0912020951o350b8494n7dd7357d5ccd4fb1@mail.gmail.com> 
	<4B16CC5C.7050008@v.loewis.de>
Message-ID: <b654cd2e0912031243uc1b01fcpda4d821e86154de3@mail.gmail.com>

On Wed, Dec 2, 2009 at 2:21 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> I'd like to see how the PyPI UI works out. ?I can also imagine a more
>> extensible setup, like:
>>
>> Project-URLs: documentation=http://myproject.org/docs/
>> ? ? repository=http://myproject.org/svn/
>> ? ? mailing list=http://googlegroups.com/groups/myproject
>
> I think this also points to an important detail: are they per package,
> or per release?

Discussion has continued a bit, but my $0.02.  It seems easiest to
implement per-release, as everything else we have is per-release
(except, I suppose, the project name itself).  Personally I only
submit packages through "setup.py register" which is naturally
per-release; making it per-package would either mean conflating it
with per-release via the register command, or setting up some other
interface.

I think it would be generally useful if old releases included a
warning in the PyPI interface (some prominent box that said "This is
an old release! The newest release is <a href="X.Y">X.Y</a>").  It's
actually pretty easy to get unintentionally to an old release via
search engines.  I think a warning would mitigate this problem and
others.


> It may seem irrelevant, as it shouldn't hurt when they are per release
> (so what?) - but it does: when you change the bug tracker, will it
> retroactively also change for all past releases?

It would be nice (as per-release bug trackers seem quite unlikely) but
I doubt it will be a big problem in practice.  If you change bug
trackers you should probably make the old link point to the new one
anyway; PyPI is hardly the only link to the old bug tracker that will
linger.

Tarek mentioned a problem with installers and old links (which is a
problem), but this is only for links that show up in the /simple/
interface, and I don't think any of these links should be presented
there.  Writing an installer, I don't *want* /simple/ to get any more
links than it already has.


-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker

From martin at v.loewis.de  Thu Dec  3 22:09:26 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 03 Dec 2009 22:09:26 +0100
Subject: [Catalog-sig] New fields in the Metadata for PyPI
In-Reply-To: <b654cd2e0912031243uc1b01fcpda4d821e86154de3@mail.gmail.com>
References: <94bdd2610912020649jef2a1c2xfa1b17b8c9f9593@mail.gmail.com>
	<4B16A3BB.4030407@simplistix.co.uk>
	<b654cd2e0912020951o350b8494n7dd7357d5ccd4fb1@mail.gmail.com>
	<4B16CC5C.7050008@v.loewis.de>
	<b654cd2e0912031243uc1b01fcpda4d821e86154de3@mail.gmail.com>
Message-ID: <4B182906.7080203@v.loewis.de>

> I think it would be generally useful if old releases included a
> warning in the PyPI interface (some prominent box that said "This is
> an old release! The newest release is <a href="X.Y">X.Y</a>").

They do already.

> It's
> actually pretty easy to get unintentionally to an old release via
> search engines.  I think a warning would mitigate this problem and
> others.

In the specific case that Tarek referred to, it wouldn't: the repository
URL and -dev URL of a project changed, but the old releases weren't
changed. As a consequence, the package's "simple" page listed both, and
setuptools would chose the wrong one.

Of course, for bug trackers, this specific problem likely won't occur,
unless some software starts to automatically locate the bug tracker
for some software.

> It would be nice (as per-release bug trackers seem quite unlikely) but
> I doubt it will be a big problem in practice.  If you change bug
> trackers you should probably make the old link point to the new one
> anyway; PyPI is hardly the only link to the old bug tracker that will
> linger.

One would hope so. However, people actually leave the old sites in a
very bad shape: hanging web servers and stuff like that.

Regards,
Martin

From jannis at leidel.info  Fri Dec  4 00:34:15 2009
From: jannis at leidel.info (Jannis Leidel)
Date: Fri, 4 Dec 2009 00:34:15 +0100
Subject: [Catalog-sig] Poll results
In-Reply-To: <4B157106.6000705@v.loewis.de>
References: <4B157106.6000705@v.loewis.de>
Message-ID: <A2092F18-1701-447A-BE5B-321437618317@leidel.info>

Am 01.12.2009 um 20:39 schrieb Martin v. L?wis:

> So it might be best to implement what appears as middle-ground,
> i.e. allow package authors to opt out of comments.

+1

Jannis

From ben+python at benfinney.id.au  Fri Dec  4 04:49:44 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 04 Dec 2009 14:49:44 +1100
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
Message-ID: <87ocmfjt47.fsf@benfinney.id.au>

Howdy all,

In the Subversion repository for PyPI, this revision appeared:

=====
$ bzr info .
Repository checkout (format: 2a)
Location:
  repository checkout root: .
        checkout of branch: https://svn.python.org/packages/trunk/pypi
         shared repository: /home/bignose/Projects/python/pypi

$ bzr log --revision 655
------------------------------------------------------------
revno: 655
svn revno: 690 (on /trunk/pypi)
committer: martin.von.loewis
timestamp: Sun 2009-11-29 17:15:12 +0000
message:
  Update usage agreement according to Van Lindberg's instructions.
=====

The revision modifies various files for the web interface, changing the
wording of an agreement and requiring an ?I agree? checkbox to be
checked.

=====
$ bzr diff --change 655 | diffstat
 templates/openid_return.pt |   28 +++++++++++++++++++---------
 templates/register.pt      |   32 +++++++++++++++++++++++---------
 webui.py                   |    6 ++++++
 3 files changed, 48 insertions(+), 18 deletions(-)
=====

The new wording is one that I can't agree to:

=====
[?]
+             <li>Content is restricted to Python packages and related information only.</li>
+             <li>Any content uploaded to PyPI is provided on a non-confidential basis.</li>
+             <li>The PSF is free to use or disseminate any content that I upload on an 
+               unrestricted basis for any purpose. In particular, the PSF and all other 
+               users of the web site are granted an irrevocable, worldwide, royalty-free, 
+               nonexclusive license to reproduce, distribute, transmit, display, perform, 
+               and publish the content, including in digital form.</li>
+             <li>I represent and warrant that I have complied with all government 
+               regulations [?]
=====

The content that I submit to PyPI is licensed under specific license
terms. That certainly does *not* allow the PSF to ?use or disseminate
any content that I upload on an unrestricted basis for any purpose?,
etc.; it allows only those acts permitted by the license terms granted
in the work.

I have already registered an account at PyPI, and never agreed to this
wording. (The previous wording was much less broad and unobjectionable.)
I would not have noticed it changing if I had not been investigating the
PyPI website source code.

Will the PSF claim I am bound by it anyway? What about future changes?

Why was this wording chosen? How does the PSF propose to reconcile this
with copyright holders's chosen license terms for their work?

-- 
 \       ?Timid men prefer the calm of despotism to the boisterous sea |
  `\                                    of liberty.? ?Thomas Jefferson |
_o__)                                                                  |
Ben Finney


From martin at v.loewis.de  Fri Dec  4 10:12:39 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 04 Dec 2009 10:12:39 +0100
Subject: [Catalog-sig] [Python-Dev] Troubled by changes to PyPI usage
	agreement
In-Reply-To: <20091204042258.GW23922@benfinney.id.au>
References: <87ocmfjt47.fsf@benfinney.id.au>	<1afaf6160912032012k4416e542ue27e3945df5f4dcd@mail.gmail.com>
	<20091204042258.GW23922@benfinney.id.au>
Message-ID: <4B18D287.6070003@v.loewis.de>

Ben Finney wrote:
> On 03-Dec-2009, Benjamin Peterson wrote:
>> Hi Ben,
>> Could I ask why you cced this to python-dev, too? I thought the last
>> string of pypi related emails, we agreed the correct place for this
>> was the catalog-sig.
> 
> I did consider that. But it seems this change is being asserted by the
> PSF. At the least, it seems to need clarification by Python insiders
> who may not be reading the ?catalog-sig? forum.
> 
> Sorry for not making the reason for the cross-post clearer.

Well, python-dev and the PSF have not much to do with each other,
either. You can reach the PSF at psf at python.org.

Regards,
Martin

From ben+python at benfinney.id.au  Fri Dec  4 10:37:06 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 04 Dec 2009 20:37:06 +1100
Subject: [Catalog-sig] [Python-Dev] Troubled by changes to PyPI usage
	agreement
References: <87ocmfjt47.fsf@benfinney.id.au>
	<1afaf6160912032012k4416e542ue27e3945df5f4dcd@mail.gmail.com>
	<20091204042258.GW23922@benfinney.id.au>
	<4B18D287.6070003@v.loewis.de>
Message-ID: <873a3rjd19.fsf@benfinney.id.au>

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

> Well, python-dev and the PSF have not much to do with each other,
> either. You can reach the PSF at psf at python.org.

Okay, thanks.

Folks, I consider this thread on ?python-dev? done. I'll start again
with a new thread crossing between the PSF at the address Martin gives,
and ?catalog-sig?; if you're interested, please join that thread and let
this one end.

-- 
 \      ?Reichel's Law: A body on vacation tends to remain on vacation |
  `\            unless acted upon by an outside force.? ?Carol Reichel |
_o__)                                                                  |
Ben Finney


From ben+python at benfinney.id.au  Fri Dec  4 10:42:06 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 04 Dec 2009 20:42:06 +1100
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
Message-ID: <87y6ljhy8h.fsf@benfinney.id.au>

Howdy all,

[I'm asking for PSF feedback on this PyPI issue, hence the crosspost.]

In the Subversion repository for PyPI, this revision appeared:

=====
$ bzr info .
Repository checkout (format: 2a)
Location:
  repository checkout root: .
        checkout of branch: https://svn.python.org/packages/trunk/pypi
         shared repository: /home/bignose/Projects/python/pypi

$ bzr log --revision 655
------------------------------------------------------------
revno: 655
svn revno: 690 (on /trunk/pypi)
committer: martin.von.loewis
timestamp: Sun 2009-11-29 17:15:12 +0000
message:
  Update usage agreement according to Van Lindberg's instructions.
=====

The revision modifies various files for the web interface, changing the
wording of an agreement and requiring an ?I agree? checkbox to be
checked.

=====
$ bzr diff --change 655 | diffstat
 templates/openid_return.pt |   28 +++++++++++++++++++---------
 templates/register.pt      |   32 +++++++++++++++++++++++---------
 webui.py                   |    6 ++++++
 3 files changed, 48 insertions(+), 18 deletions(-)
=====

The new wording is one that I can't agree to:

=====
[?]
+             <li>Content is restricted to Python packages and related information only.</li>
+             <li>Any content uploaded to PyPI is provided on a non-confidential basis.</li>
+             <li>The PSF is free to use or disseminate any content that I upload on an 
+               unrestricted basis for any purpose. In particular, the PSF and all other 
+               users of the web site are granted an irrevocable, worldwide, royalty-free, 
+               nonexclusive license to reproduce, distribute, transmit, display, perform, 
+               and publish the content, including in digital form.</li>
+             <li>I represent and warrant that I have complied with all government 
+               regulations [?]
=====

The content that I submit to PyPI is licensed under specific license
terms. That certainly does *not* allow the PSF to ?use or disseminate
any content that I upload on an unrestricted basis for any purpose?,
etc.; it allows only those acts permitted by the license terms granted
in the work.

I have already registered an account at PyPI, and never agreed to this
wording. (The previous wording was much less broad and unobjectionable.)
I would not have noticed it changing if I had not been investigating the
PyPI website source code.

Will the PSF claim I am bound by it anyway? What about future changes?

Why was this wording chosen? How does the PSF propose to reconcile this
with copyright holders's chosen license terms for their work?

-- 
 \           ?The lift is being fixed for the day. During that time we |
  `\            regret that you will be unbearable.? ?hotel, Bucharest |
_o__)                                                                  |
Ben Finney


From deroiste at syslab.com  Fri Dec  4 11:37:06 2009
From: deroiste at syslab.com (=?windows-1252?Q?Cillian_de_R=F3iste?=)
Date: Fri, 04 Dec 2009 11:37:06 +0100
Subject: [Catalog-sig] Request for additional classifier for European
 Union Public License (EUPL)
In-Reply-To: <4B180C2D.6050502@v.loewis.de>
References: <4B17C9B0.7060400@syslab.com> <4B180C2D.6050502@v.loewis.de>
Message-ID: <4B18E652.3000803@syslab.com>

Martin v. L?wis wrote:
>> We would like to use a classifier for EUPL licensed work:
>> EUPL is an OSI approved F/OSS license which is approved by the European
>> Commission:
>> http://ec.europa.eu/idabc/eupl.
>>
>> "License :: OSI Approved :: European Union Public License (EUPL)"
> 
> Can you name a few packages that would be classified under this classifier?

Sure, we'd like to use the classifier for the following packages which 
are already on pypi:

http://pypi.python.org/pypi/slc.aggregation
http://pypi.python.org/pypi/slc.editonpro
http://pypi.python.org/pypi/slc.publications
http://pypi.python.org/pypi/slc.seminarportal
http://pypi.python.org/pypi/slc.shoppinglist
http://pypi.python.org/pypi/slc.xliff

The EUPL license has been added to these products in our repository, but 
we have not released new packages yet, hence the query. We will 
certainly have more packages in the future which could also use it.

I have noticed another package which has nothing to do with us but which 
also is licensed under the EUPL:
http://pypi.python.org/pypi/rsa

http://forge.osor.eu/softwaremap/trove_list.php?form_cat=178&discrim=307
lists 3 additional Python projects which are using the license.

According to: http://www.osor.eu/eupl/introduction-to-the-eupl-project
the EUPL was created to satisfy the following requirements of the 
European Commission:

# The Licence should have equal legal value in many languages;
# The terminology regarding intellectual property rights had to be 
conformant with European law requirements ;
# To be valid in all Member States, limitations of liability or warranty 
had to be precise, and not formulated ?to the extend allowed by the law? 
as in most licences designed with the legal environment of the United 
States in mind.

Since we have clients who are requesting that we use this license 
specifically, it would be nice if we could use the classifier.

Please let me know if you would like any further information to support 
this.

Thanks,
Cillian de R?iste

--
SYSLAB.COM GmbH, Landwehrstrasse 60-62, 80336 Munich, Germany
http://www.syslab.com - Amtsgericht Muenchen, HRB 135057
Steuernummer 143/184/50154 - Ust.-ID: DE212842815

From mal at egenix.com  Fri Dec  4 12:27:07 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 04 Dec 2009 12:27:07 +0100
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
In-Reply-To: <87ocmfjt47.fsf@benfinney.id.au>
References: <87ocmfjt47.fsf@benfinney.id.au>
Message-ID: <4B18F20B.1050200@egenix.com>

Ben Finney wrote:
> Howdy all,
> 
> The new wording is one that I can't agree to:
> 
> =====
> [?]
> +             <li>Content is restricted to Python packages and related information only.</li>
> +             <li>Any content uploaded to PyPI is provided on a non-confidential basis.</li>
> +             <li>The PSF is free to use or disseminate any content that I upload on an 
> +               unrestricted basis for any purpose. In particular, the PSF and all other 
> +               users of the web site are granted an irrevocable, worldwide, royalty-free, 
> +               nonexclusive license to reproduce, distribute, transmit, display, perform, 
> +               and publish the content, including in digital form.</li>
> +             <li>I represent and warrant that I have complied with all government 
> +               regulations [?]
> =====
> 
> The content that I submit to PyPI is licensed under specific license
> terms. That certainly does *not* allow the PSF to ?use or disseminate
> any content that I upload on an unrestricted basis for any purpose?,
> etc.; it allows only those acts permitted by the license terms granted
> in the work.

AFAIK, the part 3 you are referring to is meant to allow the PSF to
publish the content you upload on PyPI to users of PyPI.

The same text can be found on the general legal page:

    http://www.python.org/about/legal/

so, in theory, you don't even have to reconfirm the PyPI
terms, since you're automatically bound by them via the general
legal page terms.

The wording of the clause is indeed a bit broad, in particular,
granting a redistribution right not only to the PSF, but also to
any web site user.

Note however, that you don't grant a right to sub-license.
Since you typically upload package archives to PyPI, content only
refers to those archives, not what's in the archives. The files
in the archive are still covered by their respective licenses
and there's nothing the PSF or the web site users can do to
change those licenses, since they did not get the right to
sub-license.

OTOH, you lose control over the dissemination of your package
archives, since the terms are irrevocable and that could result in
some legal problems in case you get e.g. a DMCA-like take-down notice
for one of your packages.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 04 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From solipsis at pitrou.net  Fri Dec  4 14:20:26 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 4 Dec 2009 13:20:26 +0000 (UTC)
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
References: <87y6ljhy8h.fsf@benfinney.id.au>
Message-ID: <loom.20091204T140714-105@post.gmane.org>

Hello,

> The content that I submit to PyPI is licensed under specific license
> terms. That certainly does *not* allow the PSF to ?use or disseminate
> any content that I upload on an unrestricted basis for any purpose?,
> etc.; it allows only those acts permitted by the license terms granted
> in the work.

I think the premise is that any FLOSS license (as recognized by the OSI or,
similarly, by the FSF) allows to ?use and disseminate [...] on an unrestricted
basis for any purpose?.

Perhaps explicitly restricting PyPI to FLOSS would be simpler than this kind of
legalese?

Regards

Antoine.



From benjamin at python.org  Fri Dec  4 05:12:31 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 3 Dec 2009 22:12:31 -0600
Subject: [Catalog-sig] [Python-Dev] Troubled by changes to PyPI usage
	agreement
In-Reply-To: <87ocmfjt47.fsf@benfinney.id.au>
References: <87ocmfjt47.fsf@benfinney.id.au>
Message-ID: <1afaf6160912032012k4416e542ue27e3945df5f4dcd@mail.gmail.com>

2009/12/3 Ben Finney <ben+python at benfinney.id.au>:
> Howdy all,

Hi Ben,
Could I ask why you cced this to python-dev, too? I thought the last
string of pypi related emails, we agreed the correct place for this
was the catalog-sig.



-- 
Regards,
Benjamin

From ben+python at benfinney.id.au  Fri Dec  4 05:22:58 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 4 Dec 2009 15:22:58 +1100
Subject: [Catalog-sig] [Python-Dev] Troubled by changes to PyPI usage
	agreement
In-Reply-To: <1afaf6160912032012k4416e542ue27e3945df5f4dcd@mail.gmail.com>
References: <87ocmfjt47.fsf@benfinney.id.au>
	<1afaf6160912032012k4416e542ue27e3945df5f4dcd@mail.gmail.com>
Message-ID: <20091204042258.GW23922@benfinney.id.au>

On 03-Dec-2009, Benjamin Peterson wrote:
> Hi Ben,
> Could I ask why you cced this to python-dev, too? I thought the last
> string of pypi related emails, we agreed the correct place for this
> was the catalog-sig.

I did consider that. But it seems this change is being asserted by the
PSF. At the least, it seems to need clarification by Python insiders
who may not be reading the ?catalog-sig? forum.

Sorry for not making the reason for the cross-post clearer.

-- 
 \          ?I moved into an all-electric house. I forgot and left the |
  `\   porch light on all day. When I got home the front door wouldn't |
_o__)                                            open.? ?Steven Wright |
Ben Finney <ben at benfinney.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20091204/06000eb8/attachment.pgp>

From doug.hellmann at gmail.com  Fri Dec  4 16:43:42 2009
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Fri, 4 Dec 2009 10:43:42 -0500
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
In-Reply-To: <87y6ljhy8h.fsf@benfinney.id.au>
References: <87y6ljhy8h.fsf@benfinney.id.au>
Message-ID: <C1D58890-97EF-4FDE-B526-E35583FABE84@gmail.com>


On Dec 4, 2009, at 4:42 AM, Ben Finney wrote:

>
> The new wording is one that I can't agree to:
>
> =====
> [?]
> +             <li>Content is restricted to Python packages and  
> related information only.</li>
> +             <li>Any content uploaded to PyPI is provided on a non- 
> confidential basis.</li>
> +             <li>The PSF is free to use or disseminate any content  
> that I upload on an
> +               unrestricted basis for any purpose. In particular,  
> the PSF and all other
> +               users of the web site are granted an irrevocable,  
> worldwide, royalty-free,
> +               nonexclusive license to reproduce, distribute,  
> transmit, display, perform,
> +               and publish the content, including in digital form.</ 
> li>
> +             <li>I represent and warrant that I have complied with  
> all government
> +               regulations [?]
> =====
>
> The content that I submit to PyPI is licensed under specific license
> terms. That certainly does *not* allow the PSF to ?use or disseminate
> any content that I upload on an unrestricted basis for any purpose?,
> etc.; it allows only those acts permitted by the license terms granted
> in the work.

We have to grant the PSF the rights to distribute the files if we're  
uploading them to be hosted on PyPI.  Does the new wording imply that  
we're licensing the use of that code under those terms, or just  
granting distribution rights the file containing the code?  It feels  
like the latter, but I don't know how the word "perform" is  
interpreted in this context.

Doug


From van at python.org  Fri Dec  4 17:05:36 2009
From: van at python.org (VanL)
Date: Fri, 04 Dec 2009 10:05:36 -0600
Subject: [Catalog-sig] [PSF-Board] Troubled by changes to PyPI usage
	agreement
In-Reply-To: <C1D58890-97EF-4FDE-B526-E35583FABE84@gmail.com>
References: <87y6ljhy8h.fsf@benfinney.id.au>
	<C1D58890-97EF-4FDE-B526-E35583FABE84@gmail.com>
Message-ID: <4B193350.7090609@python.org>

Doug Hellmann wrote:
> We have to grant the PSF the rights to distribute the files if we're 
> uploading them to be hosted on PyPI.  Does the new wording imply that 
> we're licensing the use of that code under those terms, or just 
> granting distribution rights the file containing the code?  It feels 
> like the latter, but I don't know how the word "perform" is 
> interpreted in this context. 
Doug is essentially right here. By this agreement, the PSF gets the 
particular rights to:
- reproduce: We can copy it (in memory, or in preparation to send a copy)
- distribute: We can cause other people to receive it.
- transmit: We can send it out on a signal.
- display: We can show the content to other people.
- perform: A term of art for showing some sorts of works (think 
audio-visual or theater works)
- publish: We can offer and provide copies to other people.
... including in digital form: And do all that stuff using computer 
representations of whatever you upload.

You will find that all of these are very closely related, if not 
synonyms. Basically, we can receive your work, copy it, and provide it 
to other people in a variety of ways. This does not give the PSF the 
right to relicense your work, nor to create derivative works -- just to 
pass it on to anybody who happens to wander by the PyPI web page.

Thanks,

Van



From chris at simplistix.co.uk  Fri Dec  4 18:49:16 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 04 Dec 2009 17:49:16 +0000
Subject: [Catalog-sig] Poll results
In-Reply-To: <4B16C5E3.20201@v.loewis.de>
References: <4B157106.6000705@v.loewis.de>	<200912012150.nB1LoXsm013404@theraft.openend.se>	<4B1591FA.1090700@v.loewis.de>
	<4B16A25B.7090204@simplistix.co.uk> <4B16C5E3.20201@v.loewis.de>
Message-ID: <4B194B9C.4000007@simplistix.co.uk>

Martin v. L?wis wrote:
> I think what Laura wants is different: she doesn't want package owners
> to be able to opt out of ratings (for their own sake), but the feature
> be removed altogether, for the sake of users which she considers misled
> by ratings (IIUC).

Yes, but given the choice between:

- having ratings are they are now
- allowing ratings to be turned off by the package manager

I'd put money on which option Laura would choose...

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk


From mal at egenix.com  Fri Dec  4 20:24:01 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 04 Dec 2009 20:24:01 +0100
Subject: [Catalog-sig] [PSF-Board] Troubled by changes to PyPI
	usage	agreement
In-Reply-To: <4B193350.7090609@python.org>
References: <87y6ljhy8h.fsf@benfinney.id.au>	<C1D58890-97EF-4FDE-B526-E35583FABE84@gmail.com>
	<4B193350.7090609@python.org>
Message-ID: <4B1961D1.7010405@egenix.com>

VanL wrote:
> Doug Hellmann wrote:
>> We have to grant the PSF the rights to distribute the files if we're
>> uploading them to be hosted on PyPI.  Does the new wording imply that
>> we're licensing the use of that code under those terms, or just
>> granting distribution rights the file containing the code?  It feels
>> like the latter, but I don't know how the word "perform" is
>> interpreted in this context. 
> Doug is essentially right here. By this agreement, the PSF gets the
> particular rights to:
> - reproduce: We can copy it (in memory, or in preparation to send a copy)
> - distribute: We can cause other people to receive it.
> - transmit: We can send it out on a signal.
> - display: We can show the content to other people.
> - perform: A term of art for showing some sorts of works (think
> audio-visual or theater works)
> - publish: We can offer and provide copies to other people.
> ... including in digital form: And do all that stuff using computer
> representations of whatever you upload.
> 
> You will find that all of these are very closely related, if not
> synonyms. Basically, we can receive your work, copy it, and provide it
> to other people in a variety of ways. This does not give the PSF the
> right to relicense your work, nor to create derivative works -- just to
> pass it on to anybody who happens to wander by the PyPI web page.

Right, but why does the clause also give this permission
to "all other users of the web site" and why does the license
need to be "irrevocable" ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 04 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From noah at coderanger.net  Fri Dec  4 20:30:02 2009
From: noah at coderanger.net (Noah Kantrowitz)
Date: Fri, 4 Dec 2009 11:30:02 -0800
Subject: [Catalog-sig] [PSF-Board] Troubled by changes to
	PyPI	usage	agreement
In-Reply-To: <4B1961D1.7010405@egenix.com>
References: <87y6ljhy8h.fsf@benfinney.id.au>	<C1D58890-97EF-4FDE-B526-E35583FABE84@gmail.com>	<4B193350.7090609@python.org>
	<4B1961D1.7010405@egenix.com>
Message-ID: <019d01ca7518$2dba00f0$892e02d0$@net>

> -----Original Message-----
> From: catalog-sig-bounces+noah=coderanger.net at python.org
> [mailto:catalog-sig-bounces+noah=coderanger.net at python.org] On Behalf
> Of M.-A. Lemburg
> Sent: Friday, December 04, 2009 11:24 AM
> To: VanL
> Cc: Ben Finney; psf at python.org; catalog-sig at python.org
> Subject: Re: [Catalog-sig] [PSF-Board] Troubled by changes to PyPI
> usage agreement
> 
> VanL wrote:
> > Doug Hellmann wrote:
> >> We have to grant the PSF the rights to distribute the files if we're
> >> uploading them to be hosted on PyPI.  Does the new wording imply
> that
> >> we're licensing the use of that code under those terms, or just
> >> granting distribution rights the file containing the code?  It feels
> >> like the latter, but I don't know how the word "perform" is
> >> interpreted in this context.
> > Doug is essentially right here. By this agreement, the PSF gets the
> > particular rights to:
> > - reproduce: We can copy it (in memory, or in preparation to send a
> copy)
> > - distribute: We can cause other people to receive it.
> > - transmit: We can send it out on a signal.
> > - display: We can show the content to other people.
> > - perform: A term of art for showing some sorts of works (think
> > audio-visual or theater works)
> > - publish: We can offer and provide copies to other people.
> > ... including in digital form: And do all that stuff using computer
> > representations of whatever you upload.
> >
> > You will find that all of these are very closely related, if not
> > synonyms. Basically, we can receive your work, copy it, and provide
> it
> > to other people in a variety of ways. This does not give the PSF the
> > right to relicense your work, nor to create derivative works -- just
> to
> > pass it on to anybody who happens to wander by the PyPI web page.
> 
> Right, but why does the clause also give this permission
> to "all other users of the web site" and why does the license
> need to be "irrevocable" ?

PyPI has user-run mirrors, some internal and some public.

--Noah


From lac at openend.se  Fri Dec  4 20:50:53 2009
From: lac at openend.se (Laura Creighton)
Date: Fri, 04 Dec 2009 20:50:53 +0100
Subject: [Catalog-sig] Poll results
In-Reply-To: Message from Chris Withers <chris@simplistix.co.uk> 
	of "Fri, 04 Dec 2009 17:49:16 GMT." <4B194B9C.4000007@simplistix.co.uk> 
References: <4B157106.6000705@v.loewis.de>
	<200912012150.nB1LoXsm013404@theraft.openend.se>
	<4B1591FA.1090700@v.loewis.de> <4B16A25B.7090204@simplistix.co.uk>
	<4B16C5E3.20201@v.loewis.de> <4B194B9C.4000007@simplistix.co.uk> 
Message-ID: <200912041950.nB4JorrI025544@theraft.openend.se>

In a message of Fri, 04 Dec 2009 17:49:16 GMT, Chris Withers writes:
>Martin v. L?wis wrote:
>> I think what Laura wants is different: she doesn't want package owners
>> to be able to opt out of ratings (for their own sake), but the feature
>> be removed altogether, for the sake of users which she considers misled
>> by ratings (IIUC).
>
>Yes, but given the choice between:
>
>- having ratings are they are now
>- allowing ratings to be turned off by the package manager
>
>I'd put money on which option Laura would choose...
>
>Chris
>

Martin is correct in knowing what I really want, but Chris is also correct that
given the choice between forcing everybody to have them, and allowing people to
opt-out, I'd go with allowing people to opt out.

Laura

ps - it is not the users who will be mislead that are my prime concern here.  It is
the package submitters who will be unfairly rated, and all of us who will be submitted to
whatever acrimony that a rating system produces, and all of us who won't find
interesting packages because those people who write them don't care to be rated, and
will avoid PyPI rather than submit to such a thing.


From tjreedy at udel.edu  Fri Dec  4 21:11:12 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 04 Dec 2009 15:11:12 -0500
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
In-Reply-To: <87y6ljhy8h.fsf@benfinney.id.au>
References: <87y6ljhy8h.fsf@benfinney.id.au>
Message-ID: <hfbqcv$rd$1@ger.gmane.org>

Ben Finney wrote:
> Howdy all,

> +             <li>The PSF is free to use or disseminate any content that I upload on an 
> +               unrestricted basis for any purpose.

I presume this is the first thing that bothers Ben. The PYTHON SOFTWARE 
FOUNDATION LICENSE VERSION 2, which I just checked is *NOT* an 
unrestricted license. It has a few mild conditions. So it could seem a 
little strange that it would not allow at least the same restrictions on 
stuff uploaded.

 > 		In particular, the PSF and all other
> +               users of the web site are granted an irrevocable, 

The PSF license has a termination clause.

> The content that I submit to PyPI is licensed under specific license
> terms. That certainly does *not* allow the PSF to ?use or disseminate
> any content that I upload on an unrestricted basis for any purpose?,
> etc.; it allows only those acts permitted by the license terms granted
> in the work.
> 
> I have already registered an account at PyPI, and never agreed to this
> wording. (The previous wording was much less broad and unobjectionable.)
> I would not have noticed it changing if I had not been investigating the
> PyPI website source code.
> 
> Will the PSF claim I am bound by it anyway?

Unless the previous agreement included a unilateral 'change at will' 
clause (which I do not think US courts allow), you are not. You have to 
at least be given notice and a chance to opt out of the change and 
cancel the agreement.

You will have to ask the PSF what it 'claims' and intends.

tjr


From tjreedy at udel.edu  Fri Dec  4 21:15:24 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 04 Dec 2009 15:15:24 -0500
Subject: [Catalog-sig] [PSF-Board] Troubled by changes to PyPI usage
	agreement
In-Reply-To: <4B193350.7090609@python.org>
References: <87y6ljhy8h.fsf@benfinney.id.au>	<C1D58890-97EF-4FDE-B526-E35583FABE84@gmail.com>
	<4B193350.7090609@python.org>
Message-ID: <hfbqkr$1k5$1@ger.gmane.org>

VanL wrote:
>  Basically, we can receive your work, copy it, and provide it
> to other people in a variety of ways.

This much is sensible. But this is not 'unrestricted use'.

 > This does not give the PSF the
> right to relicense your work, nor to create derivative works -- just to 
> pass it on to anybody who happens to wander by the PyPI web page.

To me, 'unrestricted use' means just that the PSF *can* do all these 
things, and anything else it can dream up.

tjr


From ziade.tarek at gmail.com  Sat Dec  5 02:09:25 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 5 Dec 2009 02:09:25 +0100
Subject: [Catalog-sig] PyPI is down
Message-ID: <94bdd2610912041709h64892261pc350c7b27e0da1f@mail.gmail.com>

Hi Guys,

Just wanted to let you know, if someone can check on that server sometimes,

Cc-ing catalog-sig, I don't know if there are other sysops there

Regards,
Tarek

From richard at python.org  Sat Dec  5 05:01:09 2009
From: richard at python.org (Richard Jones)
Date: Sat, 5 Dec 2009 15:01:09 +1100
Subject: [Catalog-sig] PyPI is down
In-Reply-To: <94bdd2610912041709h64892261pc350c7b27e0da1f@mail.gmail.com>
References: <94bdd2610912041709h64892261pc350c7b27e0da1f@mail.gmail.com>
Message-ID: <FDED7AA7-AF17-41C6-AB7D-C3C452E1C1CB@python.org>

On 05/12/2009, at 12:09 PM, Tarek Ziad? wrote:
> Just wanted to let you know, if someone can check on that server sometimes,
> 
> Cc-ing catalog-sig, I don't know if there are other sysops there

It appears to be fine from here.


     Richard


From chris at simplistix.co.uk  Sat Dec  5 09:57:27 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 05 Dec 2009 08:57:27 +0000
Subject: [Catalog-sig] PyPI is down
In-Reply-To: <FDED7AA7-AF17-41C6-AB7D-C3C452E1C1CB@python.org>
References: <94bdd2610912041709h64892261pc350c7b27e0da1f@mail.gmail.com>
	<FDED7AA7-AF17-41C6-AB7D-C3C452E1C1CB@python.org>
Message-ID: <4B1A2077.2030408@simplistix.co.uk>

Richard Jones wrote:
> On 05/12/2009, at 12:09 PM, Tarek Ziad? wrote:
>> Just wanted to let you know, if someone can check on that server sometimes,
>>
>> Cc-ing catalog-sig, I don't know if there are other sysops there
> 
> It appears to be fine from here.

It was down for me when I last checked 7 or so hours ago, appears fine 
now...

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From ben+python at benfinney.id.au  Sun Dec  6 02:06:54 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sun, 06 Dec 2009 12:06:54 +1100
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
References: <87y6ljhy8h.fsf@benfinney.id.au>
	<loom.20091204T140714-105@post.gmane.org>
Message-ID: <87hbs4j4gh.fsf@benfinney.id.au>

Doug Hellmann <doug.hellmann at gmail.com> writes:

> We have to grant the PSF the rights to distribute the files if we're
> uploading them to be hosted on PyPI.

Since the works are free software (IIUC, non-free works are not allowed
to be uploaded to PyPI), then the PSF *has* rights to distribute the
files.

The new ?usage agreement? wording is asserting much more than that,
though.


Terry Reedy <tjreedy at udel.edu> writes:

> VanL wrote:
> > This does not give the PSF the right to relicense your work, nor to
> > create derivative works -- just to pass it on to anybody who happens
> > to wander by the PyPI web page.
>
> To me, 'unrestricted use' means just that the PSF *can* do all these
> things, and anything else it can dream up.

Yes, exactly.

Surely better than claiming some extra rights, the rights already in the
works should be enough:

Antoine Pitrou <solipsis at pitrou.net> writes:

> I think the premise is that any FLOSS license (as recognized by the
> OSI or, similarly, by the FSF) allows to ?use and disseminate [...] on
> an unrestricted basis for any purpose?.
>
> Perhaps explicitly restricting PyPI to FLOSS would be simpler than
> this kind of legalese?

That seems the best option to me. If the PSF were to require only
free-software works on PyPI, this issue would be solved AFAICT.

-- 
 \       ?Selfish, adj. Devoid of consideration for the selfishness of |
  `\          others.? ?Ambrose Bierce, _The Devil's Dictionary_, 1906 |
_o__)                                                                  |
Ben Finney


From martin at v.loewis.de  Sun Dec  6 09:51:06 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sun, 06 Dec 2009 09:51:06 +0100
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
In-Reply-To: <87hbs4j4gh.fsf@benfinney.id.au>
References: <87y6ljhy8h.fsf@benfinney.id.au>	<loom.20091204T140714-105@post.gmane.org>
	<87hbs4j4gh.fsf@benfinney.id.au>
Message-ID: <4B1B707A.7080304@v.loewis.de>

> The new ?usage agreement? wording is asserting much more than that,
> though.

Specifically what rights are asserted that you are not willing to grant?

Regards,
Martin

From lac at openend.se  Sun Dec  6 10:08:42 2009
From: lac at openend.se (Laura Creighton)
Date: Sun, 06 Dec 2009 10:08:42 +0100
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
In-Reply-To: Message from Ben Finney <ben+python@benfinney.id.au> 
	of "Fri, 04 Dec 2009 20:42:06 +1100." <87y6ljhy8h.fsf@benfinney.id.au> 
References: <87y6ljhy8h.fsf@benfinney.id.au> 
Message-ID: <200912060908.nB698gGW005333@theraft.openend.se>

I think it would be better to use the language from the EUPL
see: http://ec.europa.eu/idabc/servlets/Doc?id=31979

In particular, I think that it is much better to say something like:

   In the countries where moral rights apply, the Licensor waives his right to exercise his
   moral right to the extent allowed by law in order to make effective the licence of the
   economic rights here above listed.

   The Licensor grants to the Licensee royalty-free, non exclusive usage rights to any
   patents held by the Licensor, to the extent necessary to make use of the rights granted
   on the Work under this Licence.

rather than asserting 

       The PSF is free to use or disseminate any content ....

because then as part of the PyPi agreeement one can have clauses like this:

	Copyleft clause: If the Licensee distributes and/or communicates copies of the
	Original Works or Derivative Works based upon the Original Work, this Distribution
	and/or Communication will be done under the terms of this Licence or of a later
	version of this Licence unless the Original Work is expressly distributed only under
	this version of the Licence. The Licensee (becoming Licensor) cannot offer or impose
	any additional terms or conditions on the Work or Derivative Work that alter or
	restrict the terms of the Licence.

	Attribution right: the Licensee shall keep intact all copyright, patent or trademarks
	notices and all notices that refer to the Licence and to the disclaimer of warranties.
	The Licensee must include a copy of such notices and a copy of the Licence with
	every copy of the Work he/she distributes and/or communicates. The Licensee must
	cause any Derivative Work to carry prominent notices stating that the Work has been
	modified and the date of modification.   

	Legal Protection: This Licence does not grant permission to use the trade names,
	trademarks, service marks, or names of the Licensor, except as required for
	reasonable and customary use in describing the origin of the Work and reproducing
	the content of the copyright notice.

-----------
However, if we do this, I think we will have to add a clause such as

	 Chain of Authorship
	 The original Licensor warrants that the copyright in the Original Work granted
	 hereunder is owned by him/her or licensed to him/her and that he/she has the power
	 and authority to grant the Licence.
	 Each Contributor warrants that the copyright in the modifications he/she brings to the
	 Work are owned by him/her or licensed to him/her and that he/she has the power and
	 authority to grant the Licence.

	 Each time You accept the Licence, the original Licensor and subsequent Contributors
	 grant You a licence to their contributions to the Work, under the terms of this
	 Licence.

which I think would be a very good idea in any case.

Laura


From doug.hellmann at gmail.com  Sun Dec  6 16:32:36 2009
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Sun, 6 Dec 2009 10:32:36 -0500
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
In-Reply-To: <87hbs4j4gh.fsf@benfinney.id.au>
References: <87y6ljhy8h.fsf@benfinney.id.au>
	<loom.20091204T140714-105@post.gmane.org>
	<87hbs4j4gh.fsf@benfinney.id.au>
Message-ID: <0DB933F6-C1AB-491B-A310-69A6C1A49148@gmail.com>


On Dec 5, 2009, at 8:06 PM, Ben Finney wrote:

> Doug Hellmann <doug.hellmann at gmail.com> writes:
>
>> We have to grant the PSF the rights to distribute the files if we're
>> uploading them to be hosted on PyPI.
>
> Since the works are free software (IIUC, non-free works are not  
> allowed
> to be uploaded to PyPI), then the PSF *has* rights to distribute the
> files.
>
> The new ?usage agreement? wording is asserting much more than that,
> though.

There's a distinction between the permission granted to distribute the  
files and meta-data that make up the software cataloged on PyPI and  
the license under which that same source code can be used in a project.

The way I read the agreement, I'm giving the PSF permission to  
distribute my meta-data and code, not to use the code itself.  Is that  
right, Van?

Doug


From mal at egenix.com  Mon Dec  7 20:51:39 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 07 Dec 2009 20:51:39 +0100
Subject: [Catalog-sig] [PSF-Board] Troubled by changes
	to	PyPI	usage	agreement
In-Reply-To: <019d01ca7518$2dba00f0$892e02d0$@net>
References: <87y6ljhy8h.fsf@benfinney.id.au>	<C1D58890-97EF-4FDE-B526-E35583FABE84@gmail.com>	<4B193350.7090609@python.org>	<4B1961D1.7010405@egenix.com>
	<019d01ca7518$2dba00f0$892e02d0$@net>
Message-ID: <4B1D5CCB.4000309@egenix.com>

Noah Kantrowitz wrote:
>> VanL wrote:
>>> Doug Hellmann wrote:
>>>> We have to grant the PSF the rights to distribute the files if we're
>>>> uploading them to be hosted on PyPI.  Does the new wording imply
>> that
>>>> we're licensing the use of that code under those terms, or just
>>>> granting distribution rights the file containing the code?  It feels
>>>> like the latter, but I don't know how the word "perform" is
>>>> interpreted in this context.
>>> Doug is essentially right here. By this agreement, the PSF gets the
>>> particular rights to:
>>> - reproduce: We can copy it (in memory, or in preparation to send a
>> copy)
>>> - distribute: We can cause other people to receive it.
>>> - transmit: We can send it out on a signal.
>>> - display: We can show the content to other people.
>>> - perform: A term of art for showing some sorts of works (think
>>> audio-visual or theater works)
>>> - publish: We can offer and provide copies to other people.
>>> ... including in digital form: And do all that stuff using computer
>>> representations of whatever you upload.
>>>
>>> You will find that all of these are very closely related, if not
>>> synonyms. Basically, we can receive your work, copy it, and provide
>> it
>>> to other people in a variety of ways. This does not give the PSF the
>>> right to relicense your work, nor to create derivative works -- just
>> to
>>> pass it on to anybody who happens to wander by the PyPI web page.
>>
>> Right, but why does the clause also give this permission
>> to "all other users of the web site" and why does the license
>> need to be "irrevocable" ?
> 
> PyPI has user-run mirrors, some internal and some public.

Those are likely only a handful of users who'd need the
added permissions and it doesn't explain the need for
an irrevocable license.

If you replace "all other users of the web site" with "users
granted permission by the PSF to use the PyPI data", the mirror
requirement would be dealt with in a way that doesn't require
giving redistribution rights to the general public.

The "irrevocable" appears to be unnecessary, since developers
can already revoke the permission by simply deleting the uploaded
files.

Note that the two paragraphs were added after I asked the board
on their views of having crypto code on PyPI.

The conclusion was that pypi.python.org would only be seen as
platform for distribution, without the PSF actually redistributing
the uploaded code and the uploader would be the one to determine
whether it's ok to upload the code or not. That's a convenient
understanding for the PSF, since it doesn't have to control
the uploaded code.

However, the current wording makes it look a lot like the PSF is
in fact regarding itself as a redistributor of the PyPI hosted
code, so the PSF would have to follow export regulations of the
Netherlands (where the servers are hosted) w/r to redistribution
and reexport of crypto code. This again, is not really convenient
for the PSF, since export rules are complicated.

IMHO, it would be better to clearly state that PyPI is only
providing a hosting service for the uploaded files, with the
uploading user controlling the content and only imposing some
limits of what can be uploaded rather than creating
a licensing relationship between the uploader and the PSF,
ie. the PSF provides the web space, the user the content -
thereby avoiding all these issues.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 07 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From van at python.org  Mon Dec  7 20:58:24 2009
From: van at python.org (VanL)
Date: Mon, 07 Dec 2009 13:58:24 -0600
Subject: [Catalog-sig] [PSF-Board] Troubled by changes to PyPI usage
	agreement
In-Reply-To: <200912060908.nB698gGW005333@theraft.openend.se>
References: <87y6ljhy8h.fsf@benfinney.id.au>
	<200912060908.nB698gGW005333@theraft.openend.se>
Message-ID: <4B1D5E60.8010307@python.org>

Laura Creighton wrote:
> I think it would be better to use the language from the EUPL
> see: http://ec.europa.eu/idabc/servlets/Doc?id=31979
>
> In particular, I think that it is much better to say something like:
>
>    In the countries where moral rights apply, the Licensor waives his right to exercise his
>    moral right to the extent allowed by law in order to make effective the licence of the
>    economic rights here above listed.
>
>    The Licensor grants to the Licensee royalty-free, non exclusive usage rights to any
>    patents held by the Licensor, to the extent necessary to make use of the rights granted
>    on the Work under this Licence.
>
> rather than asserting 
>
>        The PSF is free to use or disseminate any content ....
>   
This is irrelevant. The EUPL refers to the licensing of the content; the 
PSF does not get the right to license (or relicense) content, only to 
distribute it. To the extent that anyone is worried about EUPL/GPL-like 
obligations on the content that kick in on redistribution, we provide 
exactly what was provided to us; if it was compliant on upload, it will 
be compliant on download.

Thanks,

Van

From van at python.org  Mon Dec  7 21:12:51 2009
From: van at python.org (VanL)
Date: Mon, 07 Dec 2009 14:12:51 -0600
Subject: [Catalog-sig] [PSF-Board] Troubled by changes
	to	PyPI	usage	agreement
In-Reply-To: <4B1D5CCB.4000309@egenix.com>
References: <87y6ljhy8h.fsf@benfinney.id.au>	<C1D58890-97EF-4FDE-B526-E35583FABE84@gmail.com>	<4B193350.7090609@python.org>	<4B1961D1.7010405@egenix.com>
	<019d01ca7518$2dba00f0$892e02d0$@net> <4B1D5CCB.4000309@egenix.com>
Message-ID: <4B1D61C3.7030705@python.org>

M.-A. Lemburg wrote:
> Those are likely only a handful of users who'd need the
> added permissions and it doesn't explain the need for
> an irrevocable license.
>   
The irrevocability is there to protect the PSF. It is so that no one can 
claim later that they got mad at the PSF and revoked the PSF's ability 
to redistribute something that they previously uploaded.

> If you replace "all other users of the web site" with "users
> granted permission by the PSF to use the PyPI data", the mirror
> requirement would be dealt with in a way that doesn't require
> giving redistribution rights to the general public.
>   
This also makes it easier for people to pass along PyPI packages to 
their friends. As I have explained before, this doesn't give anybody the 
right to relicense the content. What is provided to the PSF (and those 
who get the package from the PSF) is the right to pass on to others 
exactly what was received.
> The "irrevocable" appears to be unnecessary, since developers
> can already revoke the permission by simply deleting the uploaded
> files.
>   
You are thinking like an engineer, not like a lawyer. It doesn't have to 
make sense, it just is.

> Note that the two paragraphs were added after I asked the board
> on their views of having crypto code on PyPI.
>
> The conclusion was that pypi.python.org would only be seen as
> platform for distribution, without the PSF actually redistributing
> the uploaded code and the uploader would be the one to determine
> whether it's ok to upload the code or not. That's a convenient
> understanding for the PSF, since it doesn't have to control
> the uploaded code.
>   
Not quite right. From the point of view of the United States, export 
takes place when US-sourced code is uploaded to the server in the 
Netherlands. This is done by the person uploading, so that is the person 
that we require to have previously complied with any export 
restrictions. You are incorrect about your assertion that the PSF does 
not redistribute the code. It does.
> However, the current wording makes it look a lot like the PSF is
> in fact regarding itself as a redistributor of the PyPI hosted
> code, so the PSF would have to follow export regulations of the
> Netherlands (where the servers are hosted) w/r to redistribution
> and reexport of crypto code. This again, is not really convenient
> for the PSF, since export rules are complicated.
>   
See above. I have rendered no opinion on Netherlands export laws, as I 
am not qualified to do so. The question asked of me was with regard to 
possible PSF complications relative to PyPI and crypto code. As the PSF 
is a United States corporation, the advice was rendered relative to US law.

> IMHO, it would be better to clearly state that PyPI is only
> providing a hosting service for the uploaded files, with the
> uploading user controlling the content and only imposing some
> limits of what can be uploaded rather than creating
> a licensing relationship between the uploader and the PSF,
> ie. the PSF provides the web space, the user the content -
> thereby avoiding all these issues.
>   
This is incorrect on several counts. The PSF is not a licensor under the 
PyPI text, and therefore the text does not create a licensing 
relationship between the PSF and anyone else. Besides, your proposed 
solution would not solve the problem.

Thanks,

Van

From mal at egenix.com  Mon Dec  7 22:39:13 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 07 Dec 2009 22:39:13 +0100
Subject: [Catalog-sig] [PSF-Board] Troubled by
	changes	to	PyPI	usage	agreement
In-Reply-To: <4B1D61C3.7030705@python.org>
References: <87y6ljhy8h.fsf@benfinney.id.au>	<C1D58890-97EF-4FDE-B526-E35583FABE84@gmail.com>	<4B193350.7090609@python.org>	<4B1961D1.7010405@egenix.com>	<019d01ca7518$2dba00f0$892e02d0$@net>
	<4B1D5CCB.4000309@egenix.com> <4B1D61C3.7030705@python.org>
Message-ID: <4B1D7601.5040608@egenix.com>

VanL wrote:
> M.-A. Lemburg wrote:
>> Those are likely only a handful of users who'd need the
>> added permissions and it doesn't explain the need for
>> an irrevocable license.
>>   
> The irrevocability is there to protect the PSF. It is so that no one can
> claim later that they got mad at the PSF and revoked the PSF's ability
> to redistribute something that they previously uploaded.
> 
>> If you replace "all other users of the web site" with "users
>> granted permission by the PSF to use the PyPI data", the mirror
>> requirement would be dealt with in a way that doesn't require
>> giving redistribution rights to the general public.
>>   
> This also makes it easier for people to pass along PyPI packages to
> their friends. As I have explained before, this doesn't give anybody the
> right to relicense the content. What is provided to the PSF (and those
> who get the package from the PSF) is the right to pass on to others
> exactly what was received.
>
>> The "irrevocable" appears to be unnecessary, since developers
>> can already revoke the permission by simply deleting the uploaded
>> files.
>>   
> You are thinking like an engineer, not like a lawyer. It doesn't have to
> make sense, it just is.

I guess that's the main problem here: developers do tend to
think like engineers, not like lawyers, yet they still have
to read and accept the new terms.

Perhaps a FAQ entry is needed to get the trouble resolved,
or a slightly altered text that doesn't cause the raising
eyebrows to begin with.

FWIW, Google uses similar wording in their TOC, but they
also include this passage, which makes developers feel a lot
better:

http://www.google.com/accounts/TOS?loc=US:
"""
11. Content licence from you
...
This licence is for the sole purpose of enabling Google to display, distribute and promote the Services.
...
"""

ie. Google is *not* "free to use or disseminate such content
on an unrestricted basis for any purpose", but only for
the sole purpose of providing the service in question.
That's a fair deal.

They also don't extend the license to all users of the web-site,
since that's not necessary: the content will come with a license
that defines how to use, copy and distribute it.

And these licenses, as example, may include a restriction on reexporting
code to an embargo country which the PyPI license doesn't, but is
needed in order to protect the package author from knowingly
permitting reexport of such code.

What I'm trying to say is: Less is more :-)

The PSF should just try get the absolute minimum of what's
needed to provide the service and protect itself against
issues with e.g. export regulations, take-down notices,
etc. Nothing more.

>> Note that the two paragraphs were added after I asked the board
>> on their views of having crypto code on PyPI.
>>
>> The conclusion was that pypi.python.org would only be seen as
>> platform for distribution, without the PSF actually redistributing
>> the uploaded code and the uploader would be the one to determine
>> whether it's ok to upload the code or not. That's a convenient
>> understanding for the PSF, since it doesn't have to control
>> the uploaded code.
>>   
> Not quite right. From the point of view of the United States, export
> takes place when US-sourced code is uploaded to the server in the
> Netherlands. This is done by the person uploading, so that is the person
> that we require to have previously complied with any export
> restrictions. You are incorrect about your assertion that the PSF does
> not redistribute the code. It does.
>
>> However, the current wording makes it look a lot like the PSF is
>> in fact regarding itself as a redistributor of the PyPI hosted
>> code, so the PSF would have to follow export regulations of the
>> Netherlands (where the servers are hosted) w/r to redistribution
>> and reexport of crypto code. This again, is not really convenient
>> for the PSF, since export rules are complicated.
>>   
> See above. I have rendered no opinion on Netherlands export laws, as I
> am not qualified to do so. The question asked of me was with regard to
> possible PSF complications relative to PyPI and crypto code. As the PSF
> is a United States corporation, the advice was rendered relative to US law.

Understood. Thanks for clarifying this.

Doesn't the PSF have to follow the Netherlands' law for things
that it publishes on the python.org servers ?

>> IMHO, it would be better to clearly state that PyPI is only
>> providing a hosting service for the uploaded files, with the
>> uploading user controlling the content and only imposing some
>> limits of what can be uploaded rather than creating
>> a licensing relationship between the uploader and the PSF,
>> ie. the PSF provides the web space, the user the content -
>> thereby avoiding all these issues.
>>   
> This is incorrect on several counts. The PSF is not a licensor under the
> PyPI text, and therefore the text does not create a licensing
> relationship between the PSF and anyone else. Besides, your proposed
> solution would not solve the problem.

Perhaps there's a misunderstanding here: the text on PyPI
does create a licensing relationship between the author of a
package uploading code to PyPI and the PSF (and any user of
the web-site). The author is licensor, the PSF and all
others are licensees.

Anyway, the above was just a suggestion.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 07 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From chairman at python.org  Tue Dec  8 03:28:14 2009
From: chairman at python.org (Steve Holden, Chairman, PSF)
Date: Mon, 07 Dec 2009 21:28:14 -0500
Subject: [Catalog-sig] [PSF-Board] Troubled
	by	changes	to	PyPI	usage	agreement
In-Reply-To: <4B1D7601.5040608@egenix.com>
References: <87y6ljhy8h.fsf@benfinney.id.au>	<C1D58890-97EF-4FDE-B526-E35583FABE84@gmail.com>	<4B193350.7090609@python.org>	<4B1961D1.7010405@egenix.com>	<019d01ca7518$2dba00f0$892e02d0$@net>	<4B1D5CCB.4000309@egenix.com>
	<4B1D61C3.7030705@python.org> <4B1D7601.5040608@egenix.com>
Message-ID: <4B1DB9BE.5040000@python.org>

Adding a Google-like clause might make us seem less Draconian.

regards
 Steve

M.-A. Lemburg wrote:
> VanL wrote:
>> M.-A. Lemburg wrote:
>>> Those are likely only a handful of users who'd need the
>>> added permissions and it doesn't explain the need for
>>> an irrevocable license.
>>>   
>> The irrevocability is there to protect the PSF. It is so that no one can
>> claim later that they got mad at the PSF and revoked the PSF's ability
>> to redistribute something that they previously uploaded.
>>
>>> If you replace "all other users of the web site" with "users
>>> granted permission by the PSF to use the PyPI data", the mirror
>>> requirement would be dealt with in a way that doesn't require
>>> giving redistribution rights to the general public.
>>>   
>> This also makes it easier for people to pass along PyPI packages to
>> their friends. As I have explained before, this doesn't give anybody the
>> right to relicense the content. What is provided to the PSF (and those
>> who get the package from the PSF) is the right to pass on to others
>> exactly what was received.
>>
>>> The "irrevocable" appears to be unnecessary, since developers
>>> can already revoke the permission by simply deleting the uploaded
>>> files.
>>>   
>> You are thinking like an engineer, not like a lawyer. It doesn't have to
>> make sense, it just is.
> 
> I guess that's the main problem here: developers do tend to
> think like engineers, not like lawyers, yet they still have
> to read and accept the new terms.
> 
> Perhaps a FAQ entry is needed to get the trouble resolved,
> or a slightly altered text that doesn't cause the raising
> eyebrows to begin with.
> 
> FWIW, Google uses similar wording in their TOC, but they
> also include this passage, which makes developers feel a lot
> better:
> 
> http://www.google.com/accounts/TOS?loc=US:
> """
> 11. Content licence from you
> ...
> This licence is for the sole purpose of enabling Google to display, distribute and promote the Services.
> ...
> """
> 
> ie. Google is *not* "free to use or disseminate such content
> on an unrestricted basis for any purpose", but only for
> the sole purpose of providing the service in question.
> That's a fair deal.
> 
> They also don't extend the license to all users of the web-site,
> since that's not necessary: the content will come with a license
> that defines how to use, copy and distribute it.
> 
> And these licenses, as example, may include a restriction on reexporting
> code to an embargo country which the PyPI license doesn't, but is
> needed in order to protect the package author from knowingly
> permitting reexport of such code.
> 
> What I'm trying to say is: Less is more :-)
> 
> The PSF should just try get the absolute minimum of what's
> needed to provide the service and protect itself against
> issues with e.g. export regulations, take-down notices,
> etc. Nothing more.
> 
>>> Note that the two paragraphs were added after I asked the board
>>> on their views of having crypto code on PyPI.
>>>
>>> The conclusion was that pypi.python.org would only be seen as
>>> platform for distribution, without the PSF actually redistributing
>>> the uploaded code and the uploader would be the one to determine
>>> whether it's ok to upload the code or not. That's a convenient
>>> understanding for the PSF, since it doesn't have to control
>>> the uploaded code.
>>>   
>> Not quite right. From the point of view of the United States, export
>> takes place when US-sourced code is uploaded to the server in the
>> Netherlands. This is done by the person uploading, so that is the person
>> that we require to have previously complied with any export
>> restrictions. You are incorrect about your assertion that the PSF does
>> not redistribute the code. It does.
>>
>>> However, the current wording makes it look a lot like the PSF is
>>> in fact regarding itself as a redistributor of the PyPI hosted
>>> code, so the PSF would have to follow export regulations of the
>>> Netherlands (where the servers are hosted) w/r to redistribution
>>> and reexport of crypto code. This again, is not really convenient
>>> for the PSF, since export rules are complicated.
>>>   
>> See above. I have rendered no opinion on Netherlands export laws, as I
>> am not qualified to do so. The question asked of me was with regard to
>> possible PSF complications relative to PyPI and crypto code. As the PSF
>> is a United States corporation, the advice was rendered relative to US law.
> 
> Understood. Thanks for clarifying this.
> 
> Doesn't the PSF have to follow the Netherlands' law for things
> that it publishes on the python.org servers ?
> 
>>> IMHO, it would be better to clearly state that PyPI is only
>>> providing a hosting service for the uploaded files, with the
>>> uploading user controlling the content and only imposing some
>>> limits of what can be uploaded rather than creating
>>> a licensing relationship between the uploader and the PSF,
>>> ie. the PSF provides the web space, the user the content -
>>> thereby avoiding all these issues.
>>>   
>> This is incorrect on several counts. The PSF is not a licensor under the
>> PyPI text, and therefore the text does not create a licensing
>> relationship between the PSF and anyone else. Besides, your proposed
>> solution would not solve the problem.
> 
> Perhaps there's a misunderstanding here: the text on PyPI
> does create a licensing relationship between the author of a
> package uploading code to PyPI and the PSF (and any user of
> the web-site). The author is licensor, the PSF and all
> others are licensees.
> 
> Anyway, the above was just a suggestion.
> 
> Thanks,


-- 
Steve Holden        Chairman, Python Software Foundation
Visit Us At                       http://python.org/psf/
Watch PyCon on video now!          http://pycon.blip.tv/

From deroiste at syslab.com  Tue Dec  8 12:06:30 2009
From: deroiste at syslab.com (=?windows-1252?Q?Cillian_de_R=F3iste?=)
Date: Tue, 08 Dec 2009 12:06:30 +0100
Subject: [Catalog-sig] Request for additional classifier for European
 Union Public License (EUPL)
In-Reply-To: <4B18E652.3000803@syslab.com>
References: <4B17C9B0.7060400@syslab.com> <4B180C2D.6050502@v.loewis.de>
	<4B18E652.3000803@syslab.com>
Message-ID: <4B1E3336.8040000@syslab.com>

Cillian de R?iste wrote:
> Martin v. L?wis wrote:
>>> We would like to use a classifier for EUPL licensed work:
...
>>> "License :: OSI Approved :: European Union Public License (EUPL)"
>> Can you name a few packages that would be classified under this classifier?
...
> Sure, we'd like to use the classifier for the following packages which 
> are already on pypi:
...

Hi,

Is there anything I can do to help move this forward?

Thanks,
Cillian



From ben+python at benfinney.id.au  Tue Dec  8 23:04:10 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 09 Dec 2009 09:04:10 +1100
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
References: <87y6ljhy8h.fsf@benfinney.id.au>
Message-ID: <87bpi9f7hh.fsf@benfinney.id.au>

Ben Finney <ben+python at benfinney.id.au> writes:

> The new wording is one that I can't agree to:
>
> =====
> [?]
> +             <li>Content is restricted to Python packages and related information only.</li>
> +             <li>Any content uploaded to PyPI is provided on a non-confidential basis.</li>
> +             <li>The PSF is free to use or disseminate any content that I upload on an 
> +               unrestricted basis for any purpose. In particular, the PSF and all other 
> +               users of the web site are granted an irrevocable, worldwide, royalty-free, 
> +               nonexclusive license to reproduce, distribute, transmit, display, perform, 
> +               and publish the content, including in digital form.</li>
> +             <li>I represent and warrant that I have complied with all government 
> +               regulations [?]
> =====
>
> The content that I submit to PyPI is licensed under specific license
> terms. That certainly does *not* allow the PSF to ?use or disseminate
> any content that I upload on an unrestricted basis for any purpose?,
> etc.; it allows only those acts permitted by the license terms granted
> in the work.


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

> Specifically what rights are asserted that you are not willing to
> grant?

As I said above, the PSF asserts the right to ?use or disseminate any
content that I upload on an unrestricted basis for any purpose?. Apart
from the terribly vague ?use?, that's not in line with the deliberately
*restricted* rights granted by the copyright holder.


Doug Hellmann <doug.hellmann at gmail.com> writes:

> There's a distinction between the permission granted to distribute the
> files and meta-data that make up the software cataloged on PyPI and
> the license under which that same source code can be used in a
> project.
>
> The way I read the agreement, I'm giving the PSF permission to
> distribute my meta-data and code, not to use the code itself. Is that
> right, Van?

I don't see how a sensible distinction can be made there. (Perhaps the
vague term ?use? is getting in my way of understanding your point.)


VanL <van at python.org> writes:

> The irrevocability is there to protect the PSF. It is so that no one
> can claim later that they got mad at the PSF and revoked the PSF's
> ability to redistribute something that they previously uploaded.

I think the best way to ensure this is to constrain PyPI users to only
upload free-software works. (Any license terms that can restroactively
revoke the license without violating its specific terms, necessarily
make a non-free work and would thus be excluded from PyPI.)

Attempting to get an *additional*, broader, license from the uploader
strikes me as over-reaching.

> The PSF is not a licensor under the PyPI text, and therefore the text
> does not create a licensing relationship between the PSF and anyone
> else. Besides, your proposed solution would not solve the problem.

I don't see what problem needs solving here. The licenses of free
software works already appear to grant all the freedoms the PyPI needs.

Perhaps I'm still lacking an answer to this question:

Ben Finney <ben+python at benfinney.id.au> writes:

> Why was this wording chosen? How does the PSF propose to reconcile
> this with copyright holders's chosen license terms for their work?

-- 
 \      ?Software patents provide one more means of controlling access |
  `\      to information. They are the tool of choice for the internet |
_o__)                                     highwayman.? ?Anthony Taylor |
Ben Finney


From robert.kern at gmail.com  Tue Dec  8 23:58:29 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 08 Dec 2009 16:58:29 -0600
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
In-Reply-To: <87bpi9f7hh.fsf@benfinney.id.au>
References: <87y6ljhy8h.fsf@benfinney.id.au> <87bpi9f7hh.fsf@benfinney.id.au>
Message-ID: <hfmlml$og9$1@ger.gmane.org>

On 2009-12-08 16:04 PM, Ben Finney wrote:

> VanL<van at python.org>  writes:
>
>> The irrevocability is there to protect the PSF. It is so that no one
>> can claim later that they got mad at the PSF and revoked the PSF's
>> ability to redistribute something that they previously uploaded.
>
> I think the best way to ensure this is to constrain PyPI users to only
> upload free-software works. (Any license terms that can restroactively
> revoke the license without violating its specific terms, necessarily
> make a non-free work and would thus be excluded from PyPI.)

Who determines the freeness of the software? The OSI? That would exclude 
licenses like the CeCILL license which appears to be close enough to free 
(certainly in the respects that concerns redistribution by PyPI) but it has not 
been submitted to the OSI and might not pass every point of the Open Source 
Definition (I'm pretty sure that it is not DFSG-free).

> Attempting to get an *additional*, broader, license from the uploader
> strikes me as over-reaching.

Who would audit the packages to make sure that the uploaded code actually has an 
acceptable license? While I hope that the language can be narrowed or at least 
clarified, I definitely think that the PyPI needs a separate usage agreement 
such that uploading packages to PyPI grants specific permission for PyPI to 
redistribute the package. At the very least, uploading a package to PyPI would 
have to "represent and warrant" that the package complies with some definition 
of freeness, but that's even more vague than the current language.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From ben+python at benfinney.id.au  Wed Dec  9 00:33:12 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 09 Dec 2009 10:33:12 +1100
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
References: <87y6ljhy8h.fsf@benfinney.id.au> <87bpi9f7hh.fsf@benfinney.id.au>
	<hfmlml$og9$1@ger.gmane.org>
Message-ID: <874oo1f3d3.fsf@benfinney.id.au>

Robert Kern <robert.kern at gmail.com> writes:

> On 2009-12-08 16:04 PM, Ben Finney wrote:
>
> > I think the best way to ensure this is to constrain PyPI users to
> > only upload free-software works.
[?]

> Who determines the freeness of the software?

The PSF needs to determine that, since they're the ones who are
responsible for further redistributing the work.

This could be made simpler by using the license declaration in the
package metadata.

> > Attempting to get an *additional*, broader, license from the
> > uploader strikes me as over-reaching.
>
> Who would audit the packages to make sure that the uploaded code
> actually has an acceptable license?

Who audits them now, to ensure that the works don't have license terms
that prohibit some action that the PSF takes?

-- 
 \      ?[Entrenched media corporations will] maintain the status quo, |
  `\       or die trying. Either is better than actually WORKING for a |
_o__)                  living.? ?ringsnake.livejournal.com, 2007-11-12 |
Ben Finney


From tjreedy at udel.edu  Wed Dec  9 03:22:22 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 08 Dec 2009 21:22:22 -0500
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
In-Reply-To: <87bpi9f7hh.fsf@benfinney.id.au>
References: <87y6ljhy8h.fsf@benfinney.id.au> <87bpi9f7hh.fsf@benfinney.id.au>
Message-ID: <hfn1ku$p16$1@ger.gmane.org>

Ben Finney wrote:

> 
> "Martin v. L?wis" <martin at v.loewis.de> writes:
> 
>> Specifically what rights are asserted that you are not willing to
>> grant?

Start with all the privilege that the PSF's Python license does not 
grant to Python users. For instance: modify before redistributing 
without notice. If the PSF is serious about its license, then it would 
not upload or allow Python to be uploaded to any other site or 
distribution that makes such a demand.

> As I said above, the PSF asserts the right to ?use or disseminate any
> content that I upload on an unrestricted basis for any purpose?. Apart
> from the terribly vague ?use?, that's not in line with the deliberately
> *restricted* rights granted by the copyright holder.


From robert.kern at gmail.com  Wed Dec  9 06:13:42 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 08 Dec 2009 23:13:42 -0600
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
In-Reply-To: <874oo1f3d3.fsf@benfinney.id.au>
References: <87y6ljhy8h.fsf@benfinney.id.au>
	<87bpi9f7hh.fsf@benfinney.id.au>	<hfmlml$og9$1@ger.gmane.org>
	<874oo1f3d3.fsf@benfinney.id.au>
Message-ID: <hfnbm8$fbu$1@ger.gmane.org>

On 2009-12-08 17:33 , Ben Finney wrote:
> Robert Kern<robert.kern at gmail.com>  writes:
>
>> On 2009-12-08 16:04 PM, Ben Finney wrote:
>>
>>> I think the best way to ensure this is to constrain PyPI users to
>>> only upload free-software works.
> [?]
>
>> Who determines the freeness of the software?
>
> The PSF needs to determine that, since they're the ones who are
> responsible for further redistributing the work.
>
> This could be made simpler by using the license declaration in the
> package metadata.

You snipped the substantive point. Let me rephrase: Who determines the freeness 
of the declared license? There are many, many licenses out there.

>>> Attempting to get an *additional*, broader, license from the
>>> uploader strikes me as over-reaching.
>>
>> Who would audit the packages to make sure that the uploaded code
>> actually has an acceptable license?
>
> Who audits them now, to ensure that the works don't have license terms
> that prohibit some action that the PSF takes?

No one. The usage agreement now gives the PSF the permission to perform PyPI's 
function without needing to be concerned about the license terms at all. That's 
the entire point of having the usage agreement. The license of the code is 
irrelevant given that secondary agreement. If the uploader does not have the 
rights to give that permission, then PyPI may still have to take down the 
offending package, but I believe the existence of the agreement helps them avoid 
damages (IANAL and am not sure on this point). Without such an agreement, the 
PSF *would* have to audit the packages and their licenses. The usage agreement 
is a more efficient way to ensure that the PSF gets the necessary assurance that 
it has the right to redistribute the uploaded packages.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From robert.kern at gmail.com  Wed Dec  9 06:16:10 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 08 Dec 2009 23:16:10 -0600
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
In-Reply-To: <hfn1ku$p16$1@ger.gmane.org>
References: <87y6ljhy8h.fsf@benfinney.id.au> <87bpi9f7hh.fsf@benfinney.id.au>
	<hfn1ku$p16$1@ger.gmane.org>
Message-ID: <hfnbqr$fbu$2@ger.gmane.org>

On 2009-12-08 20:22 , Terry Reedy wrote:
> Ben Finney wrote:
>
>>
>> "Martin v. L?wis" <martin at v.loewis.de> writes:
>>
>>> Specifically what rights are asserted that you are not willing to
>>> grant?
>
> Start with all the privilege that the PSF's Python license does not
> grant to Python users. For instance: modify before redistributing
> without notice. If the PSF is serious about its license, then it would
> not upload or allow Python to be uploaded to any other site or
> distribution that makes such a demand.

The usage terms do not allow the PSF to modify the uploaded packages. It can 
"reproduce, distribute, transmit, display, perform, and publish the content," 
not modify it.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From martin at v.loewis.de  Wed Dec  9 06:44:40 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 09 Dec 2009 06:44:40 +0100
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
In-Reply-To: <874oo1f3d3.fsf@benfinney.id.au>
References: <87y6ljhy8h.fsf@benfinney.id.au>
	<87bpi9f7hh.fsf@benfinney.id.au>	<hfmlml$og9$1@ger.gmane.org>
	<874oo1f3d3.fsf@benfinney.id.au>
Message-ID: <4B1F3948.4050303@v.loewis.de>

> Who audits them now, to ensure that the works don't have license terms
> that prohibit some action that the PSF takes?

That's exactly the point of the agreement: we will *not* audit any
content uploaded, simply because we don't have the time to do so.
Instead, the PyPI users must permit the PSF (and, thus, PyPI) to
redistribute the packages, regardless of what the licenses say.

Regards,
Martin

From martin at v.loewis.de  Wed Dec  9 06:46:23 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 09 Dec 2009 06:46:23 +0100
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
In-Reply-To: <hfn1ku$p16$1@ger.gmane.org>
References: <87y6ljhy8h.fsf@benfinney.id.au> <87bpi9f7hh.fsf@benfinney.id.au>
	<hfn1ku$p16$1@ger.gmane.org>
Message-ID: <4B1F39AF.4080601@v.loewis.de>

Terry Reedy wrote:
> Ben Finney wrote:
> 
>>
>> "Martin v. L?wis" <martin at v.loewis.de> writes:
>>
>>> Specifically what rights are asserted that you are not willing to
>>> grant?
> 
> Start with all the privilege that the PSF's Python license does not
> grant to Python users. For instance: modify before redistributing
> without notice.

I don't understand. The PyPI usage terms to ask for the right to modify.

Regards,
Martin

From martin at v.loewis.de  Wed Dec  9 06:47:27 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 09 Dec 2009 06:47:27 +0100
Subject: [Catalog-sig] Troubled by changes to PyPI usage agreement
In-Reply-To: <hfnbm8$fbu$1@ger.gmane.org>
References: <87y6ljhy8h.fsf@benfinney.id.au>	<87bpi9f7hh.fsf@benfinney.id.au>	<hfmlml$og9$1@ger.gmane.org>	<874oo1f3d3.fsf@benfinney.id.au>
	<hfnbm8$fbu$1@ger.gmane.org>
Message-ID: <4B1F39EF.3000203@v.loewis.de>


> No one. The usage agreement now gives the PSF the permission to perform
> PyPI's function without needing to be concerned about the license terms
> at all. That's the entire point of having the usage agreement. The
> license of the code is irrelevant given that secondary agreement. If the
> uploader does not have the rights to give that permission, then PyPI may
> still have to take down the offending package, but I believe the
> existence of the agreement helps them avoid damages (IANAL and am not
> sure on this point). Without such an agreement, the PSF *would* have to
> audit the packages and their licenses. The usage agreement is a more
> efficient way to ensure that the PSF gets the necessary assurance that
> it has the right to redistribute the uploaded packages.

Exactly so.

Regards,
Martin


From mal at egenix.com  Wed Dec  9 19:08:49 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 09 Dec 2009 19:08:49 +0100
Subject: [Catalog-sig] [PSF-Board]
	Troubled	by	changes	to	PyPI	usage	agreement
In-Reply-To: <4B1DB9BE.5040000@python.org>
References: <87y6ljhy8h.fsf@benfinney.id.au>	<C1D58890-97EF-4FDE-B526-E35583FABE84@gmail.com>	<4B193350.7090609@python.org>	<4B1961D1.7010405@egenix.com>	<019d01ca7518$2dba00f0$892e02d0$@net>	<4B1D5CCB.4000309@egenix.com>	<4B1D61C3.7030705@python.org>
	<4B1D7601.5040608@egenix.com> <4B1DB9BE.5040000@python.org>
Message-ID: <4B1FE7B1.9030608@egenix.com>

Steve Holden, Chairman, PSF wrote:
> Adding a Google-like clause might make us seem less Draconian.

Here's a proposal for a less controversial text based on the Google
terms:

"""
PyPI is a service provided by the PSF. In order to be able to distribute the content you upload to
PyPI to web site users, the PSF asks you to agree to and affirmatively acknowledge the following:

1. Content is restricted to Python packages and related information only.

2. Any content uploaded to PyPI is provided on a non-confidential basis.

3. The PSF is granted an irrevocable, worldwide, royalty-free, nonexclusive license to reproduce,
distribute, transmit, display, perform, and publish the content, including in digital form. This
licence is for the sole purpose of enabling the PSF to display, distribute and promote the content
on PyPI.

4. I represent and warrant that I have complied with all government regulations concerning the
transfer or export of any content I upload to the PyPI servers in The Netherlands. In particular, if
I am subject to United States law, I represent and warrant that I have obtained the proper
governmental authorization for the export of the content I upload. I further affirm that any content
I provide is not intended for use by a government end-user as defined in part 772 of the United
States Export Administration Regulations.
"""

The general terms on the python.org legal page would have to be
changed in the same way.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 09 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From tjreedy at udel.edu  Thu Dec 10 20:43:00 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 10 Dec 2009 14:43:00 -0500
Subject: [Catalog-sig] [PSF-Board] Troubled by changes to PyPI usage
	agreement
In-Reply-To: <4B1FE7B1.9030608@egenix.com>
References: <87y6ljhy8h.fsf@benfinney.id.au>	<C1D58890-97EF-4FDE-B526-E35583FABE84@gmail.com>	<4B193350.7090609@python.org>	<4B1961D1.7010405@egenix.com>	<019d01ca7518$2dba00f0$892e02d0$@net>	<4B1D5CCB.4000309@egenix.com>	<4B1D61C3.7030705@python.org>	<4B1D7601.5040608@egenix.com>
	<4B1DB9BE.5040000@python.org> <4B1FE7B1.9030608@egenix.com>
Message-ID: <hfrj04$a9j$1@ger.gmane.org>

M.-A. Lemburg wrote:
> Steve Holden, Chairman, PSF wrote:
>> Adding a Google-like clause might make us seem less Draconian.
> 
> Here's a proposal for a less controversial text based on the Google
> terms:

I like the third part better.
> 
> """
> PyPI is a service provided by the PSF. In order to be able to distribute the content you upload to
> PyPI to web site users, the PSF asks you to agree to and affirmatively acknowledge the following:
> 
> 1. Content is restricted to Python packages and related information only.
> 
> 2. Any content uploaded to PyPI is provided on a non-confidential basis.
> 
> 3. The PSF is granted an irrevocable, worldwide, royalty-free, nonexclusive license to reproduce,
> distribute, transmit, display, perform, and publish the content, including in digital form. This
> licence is for the sole purpose of enabling the PSF to display, distribute and promote the content
> on PyPI.
> 
> 4. I represent and warrant that I have complied with all government regulations concerning the
> transfer or export of any content I upload to the PyPI servers in The Netherlands. In particular, if
> I am subject to United States law, I represent and warrant that I have obtained the proper
> governmental authorization for the export of the content I upload. I further affirm that any content
> I provide is not intended for use by a government end-user as defined in part 772 of the United
> States Export Administration Regulations.
> """

The fourth section might scare people off without further explanation 
somewhere, as it could be taken to imply that people have to get a US 
gov permit to upload, which almost no one has done. If this is only 
about crypto software, it should say so. I do not understand the last 
sentence at all as open-source licenses do not usually exclude specific 
users. I cannot affirm something that is complete gobble talk to me.

Terry Jan Reedy


From mal at egenix.com  Fri Dec 11 01:45:10 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 11 Dec 2009 01:45:10 +0100
Subject: [Catalog-sig] [PSF-Board] Troubled by changes to PyPI
	usage	agreement
In-Reply-To: <hfrj04$a9j$1@ger.gmane.org>
References: <87y6ljhy8h.fsf@benfinney.id.au>	<C1D58890-97EF-4FDE-B526-E35583FABE84@gmail.com>	<4B193350.7090609@python.org>	<4B1961D1.7010405@egenix.com>	<019d01ca7518$2dba00f0$892e02d0$@net>	<4B1D5CCB.4000309@egenix.com>	<4B1D61C3.7030705@python.org>	<4B1D7601.5040608@egenix.com>	<4B1DB9BE.5040000@python.org>
	<4B1FE7B1.9030608@egenix.com> <hfrj04$a9j$1@ger.gmane.org>
Message-ID: <4B219616.1080204@egenix.com>

Terry Reedy wrote:
> M.-A. Lemburg wrote:
>> Steve Holden, Chairman, PSF wrote:
>>> Adding a Google-like clause might make us seem less Draconian.
>>
>> Here's a proposal for a less controversial text based on the Google
>> terms:
> 
> I like the third part better.

Thanks.

>> """
>> PyPI is a service provided by the PSF. In order to be able to
>> distribute the content you upload to
>> PyPI to web site users, the PSF asks you to agree to and affirmatively
>> acknowledge the following:
>>
>> 1. Content is restricted to Python packages and related information only.
>>
>> 2. Any content uploaded to PyPI is provided on a non-confidential basis.
>>
>> 3. The PSF is granted an irrevocable, worldwide, royalty-free,
>> nonexclusive license to reproduce,
>> distribute, transmit, display, perform, and publish the content,
>> including in digital form. This
>> licence is for the sole purpose of enabling the PSF to display,
>> distribute and promote the content
>> on PyPI.
>>
>> 4. I represent and warrant that I have complied with all government
>> regulations concerning the
>> transfer or export of any content I upload to the PyPI servers in The
>> Netherlands. In particular, if
>> I am subject to United States law, I represent and warrant that I have
>> obtained the proper
>> governmental authorization for the export of the content I upload. I
>> further affirm that any content
>> I provide is not intended for use by a government end-user as defined
>> in part 772 of the United
>> States Export Administration Regulations.
>> """
> 
> The fourth section might scare people off without further explanation
> somewhere, as it could be taken to imply that people have to get a US
> gov permit to upload, which almost no one has done. If this is only
> about crypto software, it should say so. I do not understand the last
> sentence at all as open-source licenses do not usually exclude specific
> users. I cannot affirm something that is complete gobble talk to me.

The clause has three parts:

 a) "I represent and warrant that I have complied with all government regulations concerning the
transfer or export of any content I upload to the PyPI servers in The Netherlands."

This part is written in a general way and is needed to
cover export regulations which may be imposed by the country
of the uploader when uploading (exporting) applications to
a server in the The Netherlands.

For many countries these export regulations are variants
of the things laid out in the Wassenaar Arrangement which
covers crypto code, but also other software technologies
that may be considered dual-use:

http://www.wassenaar.org/
in particular:
http://www.wassenaar.org/controllists/2009/WA-LIST%20%2809%29%201/WA-LIST%20%2809%29%201.pdf

Most software will fall under the "GENERAL SOFTWARE NOTE"
(with some special rules for crypto software), but countries
may still implement additional rules such as the ones currently
imposed by the US (you have to send them an email with the link
to the download location - see
http://www.bis.doc.gov/encryption/pubavailencsourcecodenofify.html).

Since the exact regulations depend on the country from where
the code is uploaded, the clause can't be more specific.

I added the location of the servers to the original clause to
make the export nature of the upload more specific.

 b) "In particular, if I am subject to United States law, I represent and warrant that I have
obtained the proper governmental authorization for the export of the content I upload."

This part only applies to US uploaders.

Note that the US regulations have a subtle detail: they apply to
all US-origin content. E.g. if you export some dual-use system software
written in the US from Germany to Cuba, the US can put you on their
embargo list.

 c)  "I further affirm that any content I provide is not intended for use by a government end-user
as defined in part 772 of the United States Export Administration Regulations."

This part applies to all uploaders. The restriction appears to be
a super-set of the embargo restrictions for various individuals -
most of those are government end-users.

I find that clause too board as well, since it prevents government
users in general to use PyPI packages.

Furthermore, the embargo lists also includes companies and, of course,
whole countries, which this clause does not cover. See e.g.
EU: http://ec.europa.eu/external_relations/cfsp/sanctions/docs/measures_en.pdf
US: http://www.bis.doc.gov/news/2009/2009-fpr.pdf
(note how e.g. Cuba is on the US list, but not on the EU list)

I'm not sure why the clause is needed. Perhaps Van could clarify
this.

IMHO, part a) already covers everything that is needed w/r to
export restrictions.

All this with the usual IANAL disclaimer. I've read a lot on these
things when we started shipping a pyOpenSSL distribution. Some of the
things I found are listed above.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 11 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From faassen at startifact.com  Thu Dec 17 21:31:19 2009
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 17 Dec 2009 21:31:19 +0100
Subject: [Catalog-sig] showing a complete list of packages I have access to?
Message-ID: <hge4en$3s6$1@ger.gmane.org>

Hi there,

For a while now the package listing on PyPI when I log in is 
'truncated'. Now that change in itself is fine, as otherwise the PyPI UI 
is rather broken as I have rights to a *lot* of packages. (though I 
think the previous javascript-based collapse method that I used thanks 
to greasemonkey had some merits).

But I'd still very much like there to be a way for me to see which 
packages I have access to, nonetheless, on a separate page, perhaps. 
Perhaps there's a link somewhere? If not, could I hereby request such a 
feature?

Thanks,

Martijn


From benji at benjiyork.com  Thu Dec 17 21:47:21 2009
From: benji at benjiyork.com (Benji York)
Date: Thu, 17 Dec 2009 15:47:21 -0500
Subject: [Catalog-sig] showing a complete list of packages I have access
	to?
In-Reply-To: <hge4en$3s6$1@ger.gmane.org>
References: <hge4en$3s6$1@ger.gmane.org>
Message-ID: <e5fff6640912171247k4045fbdlf60e2803b77697ce@mail.gmail.com>

On Thu, Dec 17, 2009 at 3:31 PM, Martijn Faassen <faassen at startifact.com> wrote:
> Hi there,
>
> For a while now the package listing on PyPI when I log in is 'truncated'.
> Now that change in itself is fine, as otherwise the PyPI UI is rather broken
> as I have rights to a *lot* of packages. (though I think the previous
> javascript-based collapse method that I used thanks to greasemonkey had some
> merits).
>
> But I'd still very much like there to be a way for me to see which packages
> I have access to, nonetheless, on a separate page, perhaps. Perhaps there's
> a link somewhere? If not, could I hereby request such a feature?

You'd probably be interested in this feature request (and patch) --
although it seems stalled at the moment:
http://sourceforge.net/tracker/?func=detail&aid=2906878&group_id=66150&atid=513503
-- 
Benji York

From martin at v.loewis.de  Fri Dec 18 01:21:45 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 18 Dec 2009 01:21:45 +0100
Subject: [Catalog-sig] showing a complete list of packages I have access
 to?
In-Reply-To: <hge4en$3s6$1@ger.gmane.org>
References: <hge4en$3s6$1@ger.gmane.org>
Message-ID: <4B2ACB19.9090104@v.loewis.de>

Martijn Faassen wrote:
> Hi there,
> 
> For a while now the package listing on PyPI when I log in is
> 'truncated'. Now that change in itself is fine, as otherwise the PyPI UI
> is rather broken as I have rights to a *lot* of packages. (though I
> think the previous javascript-based collapse method that I used thanks
> to greasemonkey had some merits).
> 
> But I'd still very much like there to be a way for me to see which
> packages I have access to, nonetheless, on a separate page, perhaps.
> Perhaps there's a link somewhere? If not, could I hereby request such a
> feature?

See

http://sourceforge.net/tracker/?func=detail&aid=2906878&group_id=66150&atid=513503

I'm still waiting for a recommendation what specific change to
implement. Such a recommendation should preferably come from somebody
who has deep understanding of CSS (or else I'll likely be changing that
aspect on a monthly basis for the next year, since somebody would always
complain that the previous change was wrong).

Regards,
Martin

From benji at benjiyork.com  Fri Dec 18 14:16:32 2009
From: benji at benjiyork.com (Benji York)
Date: Fri, 18 Dec 2009 08:16:32 -0500
Subject: [Catalog-sig] showing a complete list of packages I have access
	to?
In-Reply-To: <4B2ACB19.9090104@v.loewis.de>
References: <hge4en$3s6$1@ger.gmane.org> <4B2ACB19.9090104@v.loewis.de>
Message-ID: <e5fff6640912180516w49ec1343l5f49fb75f02b5ea8@mail.gmail.com>

On Thu, Dec 17, 2009 at 7:21 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Martijn Faassen wrote:
>> Hi there,
>>
>> For a while now the package listing on PyPI when I log in is
>> 'truncated'. Now that change in itself is fine, as otherwise the PyPI UI
>> is rather broken as I have rights to a *lot* of packages. (though I
>> think the previous javascript-based collapse method that I used thanks
>> to greasemonkey had some merits).
>>
>> But I'd still very much like there to be a way for me to see which
>> packages I have access to, nonetheless, on a separate page, perhaps.
>> Perhaps there's a link somewhere? If not, could I hereby request such a
>> feature?
>
> See
>
> http://sourceforge.net/tracker/?func=detail&aid=2906878&group_id=66150&atid=513503

Done.
-- 
Benji York

From ziade.tarek at gmail.com  Mon Dec 21 12:18:16 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 21 Dec 2009 12:18:16 +0100
Subject: [Catalog-sig] Fwd: [Distutils] Finishing PEP 345
In-Reply-To: <94bdd2610912210314r450f8857i322dd60a11deb870@mail.gmail.com>
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>
	<20091219211228.GA10616@laurie.devork>
	<94bdd2610912191405s46a02da6wcd949bfafa362f77@mail.gmail.com>
	<94bdd2610912210314r450f8857i322dd60a11deb870@mail.gmail.com>
Message-ID: <94bdd2610912210318o2fdf1e19qf325921b512c2310@mail.gmail.com>

FYI. This Distutils-SIG thread is about proposing PEP 345 and impacts PyPI.
So if there's anything that look suspicious to anyone, please join the
discussion at Distutils-SIG

Regards
Tarek

---------- Forwarded message ----------
From: Tarek Ziad? <ziade.tarek at gmail.com>
Date: Mon, Dec 21, 2009 at 12:14 PM
Subject: Re: [Distutils] Finishing PEP 345
To: Floris Bruynooghe <floris.bruynooghe at gmail.com>
Cc: distutils-sig at python.org


On Sat, Dec 19, 2009 at 11:05 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Sat, Dec 19, 2009 at 10:12 PM, Floris Bruynooghe
> <floris.bruynooghe at gmail.com> wrote:
>> On Fri, Dec 18, 2009 at 03:41:48PM +0100, Tarek Ziad? wrote:
>>> The remaining point I can see is about : Repository-URL,
>>> Repository-Browse-URL, Bug-Tracker-URL.
>>>
>>> As Ian suggested I propose to change these three fields to:
>>>
>>> Project-URL (multiple-use) :
>>>
>>> ? ? A string containing an URL for the project and a label for it.
>>> separated by a comma
>> [...]

I've updated the PEP accordingly.

Here's the mail I'll send to python-dev for PEP 345, if anyone sees a
problem or something to add:

=================
Hi,

On behalf of the Distutils-SIG, I would like to propose to addition of
PEP 345 (once and *if* PEP 376 is accepted).

It's the metadata v1.2: http://www.python.org/dev/peps/pep-0345/

PEP 345 was initiated a while ago by Richard Jones, and reworked by
Tres Seaver, I, and some other folks last year at Pycon (Sorry I lost
track of the full list of contributors, but if anyone wants to be
mentioned in the Acknowledgment section let me know). Then it was
reworked throughout the year with PEP 386, in Distutils-SIG, with the
help of numerous folks.

The major enhancements are:

- being able to express dependencies on other *distributions* names,
rather than packages names or modules names. This enhancement comes
from Setuptools and has been used successfully for years by the
community.

- being able to express some fields which values are specific to some
platforms. For example, being able to define "pywin32" as a dependency
*only* on win32. This enhancement will allow any tool to query PyPI
and to get the metadata for a particular execution context, without
having to download, build, or install the project itself.

- being able to provide a list of browsable URLs for the project, like
a bug tracker, a repository etc,
?in addition to the home url. This will allow UIs like PyPI to
display a list of URLs for a project. A side-effect will be that a
project maintainer will be able to drive its end users to the right
places when they need to find detailed documentation or provide some
feedback. This enhancement was driven by the discussions about the
rating/comment system at PyPI on catalog-sig.

We believe that having PEP 376 and PEP 345 accepted will be a major
improvement for the Python packaging eco-system.

As a side note, I would really like to see them accepted before the
first beta of Python 2.7 so we can add these features in 2.7/3.2 and
start to work on third-party tools (Distribute, Pip, a standalone
version of Distutils for 2.6/2.5, etc..) to get ready to support them
by the time 2.7 final is out.

Regards
Tarek
================



-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Mon Dec 21 12:23:57 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 21 Dec 2009 12:23:57 +0100
Subject: [Catalog-sig] [Distutils] Finishing PEP 345
In-Reply-To: <94bdd2610912210318o2fdf1e19qf325921b512c2310@mail.gmail.com>
References: <94bdd2610912180641i6df1a26co9c3ff34aba034982@mail.gmail.com>
	<20091219211228.GA10616@laurie.devork>
	<94bdd2610912191405s46a02da6wcd949bfafa362f77@mail.gmail.com>
	<94bdd2610912210314r450f8857i322dd60a11deb870@mail.gmail.com>
	<94bdd2610912210318o2fdf1e19qf325921b512c2310@mail.gmail.com>
Message-ID: <94bdd2610912210323s634d621draf6628ebb53c9cc5@mail.gmail.com>

On Mon, Dec 21, 2009 at 12:18 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
[..]
>
> We believe that having PEP 376 and PEP 345 accepted will be a major
> improvement for the Python packaging eco-system.

s/PEP 376/PEP 386

From tseaver at palladion.com  Fri Dec 25 22:51:33 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 25 Dec 2009 16:51:33 -0500
Subject: [Catalog-sig] Proposal:  export PKG-INFO to the PyPI /simple tree
Message-ID: <hh3c54$n67$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the interests of making it easier to mirror package data consistently
with the uploaded package files, could we add to PyPI the feature that
it would save a version-stamped copy of the PKG-INFO file (as read
during registration) to the project's directory underneath /simple?

Folks who mirrored that tree using rsync could then write tools to
rebuild the index without requiring any extension to the PyPI XML-RPC
API to support mirroring.



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAks1M+UACgkQ+gerLs4ltQ44tgCePEzpc2FnjE5mSFgyogyV8hwe
avkAoNg+y9MdiSz9r2UwC5/h3L+wGthq
=jYJL
-----END PGP SIGNATURE-----


From martin at v.loewis.de  Fri Dec 25 23:32:19 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 25 Dec 2009 23:32:19 +0100
Subject: [Catalog-sig] Proposal: export PKG-INFO to the PyPI /simple tree
In-Reply-To: <hh3c54$n67$1@ger.gmane.org>
References: <hh3c54$n67$1@ger.gmane.org>
Message-ID: <4B353D73.5030208@v.loewis.de>

> In the interests of making it easier to mirror package data consistently
> with the uploaded package files, could we add to PyPI the feature that
> it would save a version-stamped copy of the PKG-INFO file (as read
> during registration) to the project's directory underneath /simple?

Can you please give an explicit example of what exact URL should return
what exact data. I'm sure it can be done, but I'm not sure what
precisely it is what you want.

> Folks who mirrored that tree using rsync could then write tools to
> rebuild the index without requiring any extension to the PyPI XML-RPC
> API to support mirroring.

No, they couldn't:
a) there is no rsync server on pypi, and
b) /simple does not exist on disk

However, they *could* mirror it then with wget (although wget is known
to have created quite some load on PyPI in the past).

Regards,
Martin

From tseaver at palladion.com  Sat Dec 26 04:31:28 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 25 Dec 2009 22:31:28 -0500
Subject: [Catalog-sig] Proposal: export PKG-INFO to the PyPI /simple tree
In-Reply-To: <4B353D73.5030208@v.loewis.de>
References: <hh3c54$n67$1@ger.gmane.org> <4B353D73.5030208@v.loewis.de>
Message-ID: <4B358390.90009@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin v. L?wis wrote:
>> In the interests of making it easier to mirror package data consistently
>> with the uploaded package files, could we add to PyPI the feature that
>> it would save a version-stamped copy of the PKG-INFO file (as read
>> during registration) to the project's directory underneath /simple?
> 
> Can you please give an explicit example of what exact URL should return
> what exact data. I'm sure it can be done, but I'm not sure what
> precisely it is what you want.

OK, the current 'simple' page for the 'pkginfo' project lists:

- - pkginfo-0.2.tar.gz
- - pkginfo-0.3.tar.gz
- - pkginfo-0.5.tar.gz
- - pkginfo-0.4.1.tar.gz
- - pkginfo-0.1.tar.gz
- - pkginfo-0.1.1.tar.gz
- - pkginfo-0.4.tar.gz
- - http://packages.python.org/pkginfo/

I am proposing to add the following, each populated according to the
data submutted by registering the corresponding version of the project:
 For projects which have more than one distribution for a given
registered version, only one PKG-INFO.{version} would be written.

- - PKG-INFO-0.1
- - PKG-INFO-0.1.1
- - PKG-INFO-0.2
- - PKG-INFO-0.3
- - PKG-INFO-0.4
- - PKG-INFO-0.4.1
- - PKG-INFO-0.5

>> Folks who mirrored that tree using rsync could then write tools to
>> rebuild the index without requiring any extension to the PyPI XML-RPC
>> API to support mirroring.
> 
> No, they couldn't:
> a) there is no rsync server on pypi, and
> b) /simple does not exist on disk

Hmm, I was relying on what was likely a misread of others' claim that
tools like rsync could already mirror the uploaded distributions.

> However, they *could* mirror it then with wget (although wget is known

I guess using wget to mirror it is OK:  the absence of rsync makes it me
only +0 on my own proposal, however.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAks1g5AACgkQ+gerLs4ltQ7l+wCg2Oars1X0ydxwwI5aFsb8W8kS
m28AmwYpTMu0pui+7J9cR6/MjeZCsnAH
=/mDm
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Mon Dec 28 20:29:04 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Dec 2009 20:29:04 +0100
Subject: [Catalog-sig] PyPI XML-RPC multicall support
Message-ID: <4B390700.9030100@v.loewis.de>

The PyPI XML-RPC server now supports multicalls, with a limit
of 100 subcalls per multicall. So if you have an XML-RPC
application that makes thousands of calls to PyPI in a short
time, consider batching them. I was able to obtain a speedup
of four in an application that tries to get all release data
and urls.

Regards,
Martin

From david.lyon at preisshare.net  Thu Dec 31 02:23:42 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 30 Dec 2009 20:23:42 -0500
Subject: [Catalog-sig] Finalising PEP-345 - Requires-Python
In-Reply-To: <4B358390.90009@palladion.com>
References: <hh3c54$n67$1@ger.gmane.org> <4B353D73.5030208@v.loewis.de>
	<4B358390.90009@palladion.com>
Message-ID: <d533360c6a4001bc69201f86407a71c8@preisshare.net>


> Requires-Python
>
> This field specifies the Python version(s) that the package is 
> guaranteed to be compatible with.
>
> Version numbers must be in the format specified in Version Specifiers.
>
> Examples:
> 
> Requires-Python: 2.5
> Requires-Python: >2.1
> Requires-Python: >=2.3.4
> Requires-Python: >=2.5,<2.7

I think most untrained readers, would find the ">=2.5,<2.7" notation
to be non-obvious and ambiguous.

The shortest known method to express the condition is 
"Requires-Python: 2.5:2.7"

Most importantly, specifying a logical 'AND' operation with a comma is 
obscure and verbose. We don't find any prior examples in any programming
language that I know of where comma's are used to denote a logical 
'and' operation.

What it seems to imply is that there is a pipeline of logical
expressions built into a comma seperated list. That must be
parsed, and if all are true, then the condition is accepted.

I think it would take me some time if I had to explain this proposed
solution to a computer sciences teacher in an exam situation. I
don't think I'd be so confident of getting a pass.

It would be way more logical to do the and operation by
specifying multiple conditions.

  Requires-Python: >=2.5
  Requires-Python: <2.7

As there is an implication that the file will be parsed
sequentially, and every conditional line needs to process
with a true result.

Still, the shortest known way is "Requires-Python: 2.5:2.7"

David




From ben+python at benfinney.id.au  Thu Dec 31 03:10:04 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Thu, 31 Dec 2009 13:10:04 +1100
Subject: [Catalog-sig] Finalising PEP-345 - Requires-Python
References: <hh3c54$n67$1@ger.gmane.org> <4B353D73.5030208@v.loewis.de>
	<4B358390.90009@palladion.com>
	<d533360c6a4001bc69201f86407a71c8@preisshare.net>
Message-ID: <87my0z28sj.fsf@benfinney.id.au>

David Lyon <david.lyon at preisshare.net> writes:

> > Requires-Python: 2.5
> > Requires-Python: >2.1
> > Requires-Python: >=2.3.4
> > Requires-Python: >=2.5,<2.7
>
> I think most untrained readers, would find the ">=2.5,<2.7" notation
> to be non-obvious and ambiguous.
>
> The shortest known method to express the condition is 
> "Requires-Python: 2.5:2.7"

Again, it's a poor assumption that the dependency specifications will be
read as though they follow the rules of Python syntax. The colon doesn't
obviously mean what you're wanting it to mean in that context. Please
lose the Python-language bias when assessing these issues.

-- 
 \      ?Shepherds ? look after their sheep so they can, first, fleece |
  `\   them and second, turn them into meat. That's much more like the |
_o__)      priesthood as I know it.? ?Christopher Hitchens, 2008-10-29 |
Ben Finney


From noah at coderanger.net  Thu Dec 31 03:13:12 2009
From: noah at coderanger.net (Noah Kantrowitz)
Date: Wed, 30 Dec 2009 18:13:12 -0800
Subject: [Catalog-sig] Finalising PEP-345 - Requires-Python
In-Reply-To: <87my0z28sj.fsf@benfinney.id.au>
References: <hh3c54$n67$1@ger.gmane.org>
	<4B353D73.5030208@v.loewis.de>	<4B358390.90009@palladion.com>	<d533360c6a4001bc69201f86407a71c8@preisshare.net>
	<87my0z28sj.fsf@benfinney.id.au>
Message-ID: <006301ca89be$ce54dca0$6afe95e0$@net>

> -----Original Message-----
> From: catalog-sig-bounces+noah=coderanger.net at python.org
> [mailto:catalog-sig-bounces+noah=coderanger.net at python.org] On Behalf
> Of Ben Finney
> Sent: Wednesday, December 30, 2009 6:10 PM
> To: catalog-sig at python.org
> Subject: Re: [Catalog-sig] Finalising PEP-345 - Requires-Python
> 
> David Lyon <david.lyon at preisshare.net> writes:
> 
> > > Requires-Python: 2.5
> > > Requires-Python: >2.1
> > > Requires-Python: >=2.3.4
> > > Requires-Python: >=2.5,<2.7
> >
> > I think most untrained readers, would find the ">=2.5,<2.7" notation
> > to be non-obvious and ambiguous.
> >
> > The shortest known method to express the condition is
> > "Requires-Python: 2.5:2.7"
> 
> Again, it's a poor assumption that the dependency specifications will
> be
> read as though they follow the rules of Python syntax. The colon
> doesn't
> obviously mean what you're wanting it to mean in that context. Please
> lose the Python-language bias when assessing these issues.

Also while the metadata should really have Only One Representation, it isn't directly user facing. A packing index could easily display it in a different way (icons?) and a packager could accept more than one input syntax.

--Noah


From david.lyon at preisshare.net  Thu Dec 31 04:54:48 2009
From: david.lyon at preisshare.net (david.lyon at preisshare.net)
Date: Thu, 31 Dec 2009 14:54:48 +1100 (EST)
Subject: [Catalog-sig] Finalising PEP-345 - Requires-Python
In-Reply-To: <87my0z28sj.fsf@benfinney.id.au>
References: <hh3c54$n67$1@ger.gmane.org> <4B353D73.5030208@v.loewis.de>
	<4B358390.90009@palladion.com>
	<d533360c6a4001bc69201f86407a71c8@preisshare.net>
	<87my0z28sj.fsf@benfinney.id.au>
Message-ID: <1873.218.214.45.58.1262231688.squirrel@syd-srv02.ezyreg.com>


> Again, it's a poor assumption that the dependency specifications will be
> read as though they follow the rules of Python syntax. The colon doesn't
> obviously mean what you're wanting it to mean in that context. Please
> lose the Python-language bias when assessing these issues.

That's not the point at all.

The point is consistency from one section to another
within the same PEP/metadata file.

> Requires-Dist (multiple use)
> ...
>
> Examples:
>
> Requires-Dist: pkginfo
> Requires-Dist: PasteDeploy
> Requires-Dist: zope.interface (>3.5.0)

If we can have the multiple-use rule for other sections, why
cannot we use that same rule in the same file in another
section.

Making it:

> Requires-Python (multiple use)
> ...
>
> Examples:
>
> Requires-Dist: >= 2.4
> Requires-Dist: < 2.7

It doesn't make sense to move to an entirely different
representation (using the comma) when there is already
a convention for multiple-use running through the file
as it has stood for many years.

I just want it to be consistant.. otherwise it gets
more complicated and harder than it needs to be.

David







From david.lyon at preisshare.net  Thu Dec 31 14:31:18 2009
From: david.lyon at preisshare.net (david.lyon at preisshare.net)
Date: Fri, 1 Jan 2010 00:31:18 +1100 (EST)
Subject: [Catalog-sig] Finalising PEP-345 - Requires-Python
In-Reply-To: <006301ca89be$ce54dca0$6afe95e0$@net>
References: <hh3c54$n67$1@ger.gmane.org> <4B353D73.5030208@v.loewis.de>
	<4B358390.90009@palladion.com>
	<d533360c6a4001bc69201f86407a71c8@preisshare.net>
	<87my0z28sj.fsf@benfinney.id.au>
	<006301ca89be$ce54dca0$6afe95e0$@net>
Message-ID: <1243.115.128.4.150.1262266278.squirrel@syd-srv02.ezyreg.com>

Hi Noah,

> Also while the metadata should really have Only One Representation, it
> isn't directly user facing. A packing index could easily display it in a
> different way (icons?) and a packager could accept more than one input
> syntax.

Actually, if it was forward facing to users then I don't think
it would matter so much. If the field was just displayed, it
would be very simple.

In this case, one actually expects the section in question to
be processed programmatically and checked against the internal
python version.

So it is therefore more important to have it consistent with
other sections so that there is code reuse. Having one particular
section inconsistent with all other sections (and requiring
special parsing) is a way to introduce errors right through
the tool chain, and I know for sure that nobody intended that.

A good reliable system is where things don't get too quirky
and there is consistency. Especially within the one file.

I'm sure everyone wants this pep finished. That's why I'm
checking it now so that we can get it done and good to go.

David