From dpeterson at enthought.com  Tue Aug  5 01:17:00 2008
From: dpeterson at enthought.com (Dave Peterson)
Date: Mon, 04 Aug 2008 18:17:00 -0500
Subject: [Catalog-sig] Can we change the capitalization of a registered PyPi
	project?
Message-ID: <48978DEC.9020306@enthought.com>

Hello,

We have a project, currently registered as "MayaVi" that we'd like to 
re-case to "Mayavi".  I can't seem to find anywhere to do that, even 
though case is ignored when searching the repo.   Can anyone provide 
instructions on how to do this, or perhaps just do it for Prabhu and I?

Thanks in advance!

-- Dave


From martin at v.loewis.de  Wed Aug  6 10:22:35 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 06 Aug 2008 10:22:35 +0200
Subject: [Catalog-sig] Hosting documentation on PyPI
Message-ID: <48995F4B.6060409@v.loewis.de>

I'd like to start offering to host web pages on PyPI,
primarily for the purpose of documentation. Users would
upload a tar.gz file into PyPI, which would unpack it,
and make it available as /doc/<package>/<version>.

To prevent this from being spammed, restrictions on
posting documentation would be established:
- only approved users may post documentation, approval
  can be obtained by submitting a support request into
  the PyPI tracker.
- only static pages are supported, no includes, no
  directory listings, just plain files.

What do you think?

Regards,
Martin

From chris at simplistix.co.uk  Wed Aug  6 10:35:56 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 06 Aug 2008 09:35:56 +0100
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <48995F4B.6060409@v.loewis.de>
References: <48995F4B.6060409@v.loewis.de>
Message-ID: <4899626C.4030607@simplistix.co.uk>

Martin v. L?wis wrote:
> What do you think?

I'd prefer PyPI to grow the ability to host and display version 
dependency metadata first for each version of each package. (ie: 
setuptools install_requires)

Most packages I work with seem happy to put all their docs on one page 
(ie: the package page) with internal anchor-based navigation if needed.
Either that or they have their own sites anyway...

cheers,

Chris

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

From martin at v.loewis.de  Wed Aug  6 18:44:56 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 06 Aug 2008 18:44:56 +0200
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <4899CE06.3060206@colorstudy.com>
References: <48995F4B.6060409@v.loewis.de> <4899CE06.3060206@colorstudy.com>
Message-ID: <4899D508.7030001@v.loewis.de>

> There's an XSS concern if users can upload arbitrary HTML.  Approval
> would address some of that, but it might be better to avoid the issue
> altogether.
> 
> One way to handle that would be to host each package's documentation on
> a different domain.  E.g., package.pypi.python.org.

Can you please elaborate? What is the issue, and how could creating
domains resolve it?

Also, what would be the best way to set up the web server to implement
that? Getting a delegation for a pypi.python.org zone onto that machine
should be possible, and I know how to update zone files once an hour.
However, I feel slightly uncomfortable with generating a huge Apache
config with hundreds of virtual hosts, and having Apache restart every
hour.

> Another option is using an HTML scrubber.  But removing Javascript would
> be unfortunate in this case as there's a lot of good uses of it, so
> multiple domains would be better IMHO.

For this, I'm very skeptical. There will be too many complaints that it
removes stuff incorrectly.

> If implemented I think all existing packages could be approved, which
> would greatly reduce the approval queue.

I wouldn't mind this starting slowly, say, being experimental until the
end of the year. Currently, python.org doesn't provide any similar
hosting (although the PyPI-generated package pages come close), so there
could be many risks that cause us to pull the plug.

As for "all existing packages could be approved": the existing ones
perhaps, but for new ones, wouldn't there still be a chance of somebody
uploading/linking porn, viruses, whatever?

Most likely, it works out just fine, of course, as people have to leave
real email addresses, and interact in a fairly involved manner already,
which has prevented spambots from registering so far (I'm sure the RSS
publication would cause immediate reaction from the community should a
spammer make it "through").

Regards,
Martin


From ianb at colorstudy.com  Wed Aug  6 18:15:02 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 06 Aug 2008 11:15:02 -0500
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <48995F4B.6060409@v.loewis.de>
References: <48995F4B.6060409@v.loewis.de>
Message-ID: <4899CE06.3060206@colorstudy.com>

Martin v. L?wis wrote:
> I'd like to start offering to host web pages on PyPI,
> primarily for the purpose of documentation. Users would
> upload a tar.gz file into PyPI, which would unpack it,
> and make it available as /doc/<package>/<version>.
> 
> To prevent this from being spammed, restrictions on
> posting documentation would be established:
> - only approved users may post documentation, approval
>   can be obtained by submitting a support request into
>   the PyPI tracker.
> - only static pages are supported, no includes, no
>   directory listings, just plain files.
> 
> What do you think?

I like the idea.

There's an XSS concern if users can upload arbitrary HTML.  Approval 
would address some of that, but it might be better to avoid the issue 
altogether.

One way to handle that would be to host each package's documentation on 
a different domain.  E.g., package.pypi.python.org.

Another option is using an HTML scrubber.  But removing Javascript would 
be unfortunate in this case as there's a lot of good uses of it, so 
multiple domains would be better IMHO.

If implemented I think all existing packages could be approved, which 
would greatly reduce the approval queue.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From ianb at colorstudy.com  Wed Aug  6 19:11:23 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 06 Aug 2008 12:11:23 -0500
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <4899D508.7030001@v.loewis.de>
References: <48995F4B.6060409@v.loewis.de> <4899CE06.3060206@colorstudy.com>
	<4899D508.7030001@v.loewis.de>
Message-ID: <4899DB3B.5000100@colorstudy.com>

Martin v. L?wis wrote:
>> There's an XSS concern if users can upload arbitrary HTML.  Approval
>> would address some of that, but it might be better to avoid the issue
>> altogether.
>>
>> One way to handle that would be to host each package's documentation on
>> a different domain.  E.g., package.pypi.python.org.
> 
> Can you please elaborate? What is the issue, and how could creating
> domains resolve it?

The issue is that you can put in Javascript that does XMLHttpRequests to 
other URLs on the same domain, and those requests can do things like 
change a user's password, delete packages, etc.  The Javascript will be 
run as the person who is viewing the page.  So if I am logged in to PyPI 
and view some random page on pypi.python.org, and that page contains 
malicious Javascript, that malicious Javascript can do anything on 
pypi.python.org as though it was me doing it.

You can't make XMLHttpRequests across domains, so by putting each 
package on its own domain you avoid the problem.

> Also, what would be the best way to set up the web server to implement
> that? Getting a delegation for a pypi.python.org zone onto that machine
> should be possible, and I know how to update zone files once an hour.
> However, I feel slightly uncomfortable with generating a huge Apache
> config with hundreds of virtual hosts, and having Apache restart every
> hour.

I'd set up a new IP address for the wildcard, and then I think something 
like:

<VirtualHost wildcard_ip_address>
   RewriteCond %{HTTP_HOST} ^([a-z0-9-]+)\.pypi.python.org
   RewriteRule (.*) /pypi/sites/%1/$1 [L]
</VirtualHost>

and of course the other important Apache stuff, like turning off all 
extraneous options, etc.

>> Another option is using an HTML scrubber.  But removing Javascript would
>> be unfortunate in this case as there's a lot of good uses of it, so
>> multiple domains would be better IMHO.
> 
> For this, I'm very skeptical. There will be too many complaints that it
> removes stuff incorrectly.
> 
>> If implemented I think all existing packages could be approved, which
>> would greatly reduce the approval queue.
> 
> I wouldn't mind this starting slowly, say, being experimental until the
> end of the year. Currently, python.org doesn't provide any similar
> hosting (although the PyPI-generated package pages come close), so there
> could be many risks that cause us to pull the plug.
> 
> As for "all existing packages could be approved": the existing ones
> perhaps, but for new ones, wouldn't there still be a chance of somebody
> uploading/linking porn, viruses, whatever?
> 
> Most likely, it works out just fine, of course, as people have to leave
> real email addresses, and interact in a fairly involved manner already,
> which has prevented spambots from registering so far (I'm sure the RSS
> publication would cause immediate reaction from the community should a
> spammer make it "through").

Yes.  I don't think any of the current packages are spam packages 
(though I did see one spam package in the past, but that was years ago), 
and at the moment there's little incentive... mostly because it's just 
too complicated to upload a package.  You could do link spam, it's just 
a lot of trouble.  It would be easier with this system to hide pages in 
weird locations, though you'd still have the spam package as evidence. 
So I don't think the danger is particularly high of spam.  If there were 
a hundred pypi's out there accepting submissions then it might be worth 
coding a bot to spam them, but with just one it seems like it'd be a 
waste of time on the spammer's part.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From ianb at colorstudy.com  Wed Aug  6 19:14:43 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 06 Aug 2008 12:14:43 -0500
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <4899DB3B.5000100@colorstudy.com>
References: <48995F4B.6060409@v.loewis.de>
	<4899CE06.3060206@colorstudy.com>	<4899D508.7030001@v.loewis.de>
	<4899DB3B.5000100@colorstudy.com>
Message-ID: <4899DC03.3010203@colorstudy.com>

Ian Bicking wrote:
> Martin v. L?wis wrote:
>>> There's an XSS concern if users can upload arbitrary HTML.  Approval
>>> would address some of that, but it might be better to avoid the issue
>>> altogether.
>>>
>>> One way to handle that would be to host each package's documentation on
>>> a different domain.  E.g., package.pypi.python.org.
>>
>> Can you please elaborate? What is the issue, and how could creating
>> domains resolve it?
> 
> The issue is that you can put in Javascript that does XMLHttpRequests to 
> other URLs on the same domain, and those requests can do things like 
> change a user's password, delete packages, etc.  The Javascript will be 
> run as the person who is viewing the page.  So if I am logged in to PyPI 
> and view some random page on pypi.python.org, and that page contains 
> malicious Javascript, that malicious Javascript can do anything on 
> pypi.python.org as though it was me doing it.
> 
> You can't make XMLHttpRequests across domains, so by putting each 
> package on its own domain you avoid the problem.

On second thought, simply by using a read-only domain (one that has no 
admin on the domain itself) you'd also be fine.  So 
http://pypidocs.python.org/package/* would work fine, so long as all the 
management for that remained on pypi.python.org.

I personally like domains for projects, though package.pypi.python.org 
is a bit long winded anyway.  A new top-level domain (pypackage.org or 
pyforge.org or something) would mitigate that.  But any place to drop 
docs would be nice.  Especially with Sphinx I think we'll get more 
libraries with multi-page HTML docs.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From martin at v.loewis.de  Wed Aug  6 19:48:47 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 06 Aug 2008 19:48:47 +0200
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <4899DC03.3010203@colorstudy.com>
References: <48995F4B.6060409@v.loewis.de>
	<4899CE06.3060206@colorstudy.com>	<4899D508.7030001@v.loewis.de>
	<4899DB3B.5000100@colorstudy.com> <4899DC03.3010203@colorstudy.com>
Message-ID: <4899E3FF.2000600@v.loewis.de>

> On second thought, simply by using a read-only domain (one that has no
> admin on the domain itself) you'd also be fine.  So
> http://pypidocs.python.org/package/* would work fine, so long as all the
> management for that remained on pypi.python.org.
> 
> I personally like domains for projects, though package.pypi.python.org
> is a bit long winded anyway. 

It's not longer eventually than pypi.python.org/package, and I think I
need to put /version also into it (right?), so with separate hosts, I
get http://package.pypi.python.org/version, perhaps with the empty URL
redirecting to the latest version.

In any case, I've asked whether XS4ALL can provide us with a subdomain,
or a wildcard record; if that fails, I'll fall back to
packages.python.org (unless you specifically would prefer pypidocs over
that).

Thanks for all these ideas,

Martin

P.S. I also found the VirtualDocumentRoot Apache directive, which seems
to be exactly what is needed.

From philipp at weitershausen.de  Wed Aug  6 20:21:02 2008
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Wed, 06 Aug 2008 20:21:02 +0200
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <4899DC03.3010203@colorstudy.com>
References: <48995F4B.6060409@v.loewis.de>	<4899CE06.3060206@colorstudy.com>	<4899D508.7030001@v.loewis.de>	<4899DB3B.5000100@colorstudy.com>
	<4899DC03.3010203@colorstudy.com>
Message-ID: <4899EB8E.4060006@weitershausen.de>

Ian Bicking wrote:
> Ian Bicking wrote:
>> Martin v. L?wis wrote:
>>>> There's an XSS concern if users can upload arbitrary HTML.  Approval
>>>> would address some of that, but it might be better to avoid the issue
>>>> altogether.
>>>>
>>>> One way to handle that would be to host each package's documentation on
>>>> a different domain.  E.g., package.pypi.python.org.
>>>
>>> Can you please elaborate? What is the issue, and how could creating
>>> domains resolve it?
>>
>> The issue is that you can put in Javascript that does XMLHttpRequests 
>> to other URLs on the same domain, and those requests can do things 
>> like change a user's password, delete packages, etc.  The Javascript 
>> will be run as the person who is viewing the page.  So if I am logged 
>> in to PyPI and view some random page on pypi.python.org, and that page 
>> contains malicious Javascript, that malicious Javascript can do 
>> anything on pypi.python.org as though it was me doing it.
>>
>> You can't make XMLHttpRequests across domains, so by putting each 
>> package on its own domain you avoid the problem.
> 
> On second thought, simply by using a read-only domain (one that has no 
> admin on the domain itself) you'd also be fine.  So 
> http://pypidocs.python.org/package/* would work fine, so long as all the 
> management for that remained on pypi.python.org.
> 
> I personally like domains for projects, though package.pypi.python.org 
> is a bit long winded anyway.  A new top-level domain (pypackage.org or 
> pyforge.org or something) would mitigate that.  But any place to drop 
> docs would be nice.  Especially with Sphinx I think we'll get more 
> libraries with multi-page HTML docs.

What about distribution names with dots in them? Or worse, spaces? Both 
are allowed by setuptools and PyPI and I've seen them in the wild 
(especially dotted distribution names aren't uncommon when a namespaced 
package is distributed under its package name, e.g. zope.interface).


From cakebread at gmail.com  Wed Aug  6 20:23:31 2008
From: cakebread at gmail.com (Rob Cakebread)
Date: Wed, 6 Aug 2008 11:23:31 -0700
Subject: [Catalog-sig] Minimal required information before uploading
Message-ID: <9b06ffb10808061123r8aa65c8s6f23ec021bfd75c1@mail.gmail.com>

Hi,

It would be nice if we could restrict people from uploading just a
file without any other information.
For instance, this is the latest one:

http://pypi.python.org/pypi/diviMon/0.3.5dev

There's no description, homepage or any type of contact information
and because it's an egg (no source) there won't even be a README
inside it.

I'd think at a bare minimum PyPI should abort when people try to
submit a package if it doesn't have a description, but some kind of
contact info would be desirable.
License info would be great too, but I'll be happy with at least a description.

Thoughts?

From martin at v.loewis.de  Wed Aug  6 20:26:21 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 06 Aug 2008 20:26:21 +0200
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <4899EB8E.4060006@weitershausen.de>
References: <48995F4B.6060409@v.loewis.de>	<4899CE06.3060206@colorstudy.com>	<4899D508.7030001@v.loewis.de>	<4899DB3B.5000100@colorstudy.com>
	<4899DC03.3010203@colorstudy.com>
	<4899EB8E.4060006@weitershausen.de>
Message-ID: <4899ECCD.1040600@v.loewis.de>

> What about distribution names with dots in them? Or worse, spaces? Both
> are allowed by setuptools and PyPI and I've seen them in the wild
> (especially dotted distribution names aren't uncommon when a namespaced
> package is distributed under its package name, e.g. zope.interface).

Ah, so it sounds like we need to go for the single host name, anyway.

Regards,
Martin



From ianb at colorstudy.com  Wed Aug  6 20:31:15 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 06 Aug 2008 13:31:15 -0500
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <4899EB8E.4060006@weitershausen.de>
References: <48995F4B.6060409@v.loewis.de>	<4899CE06.3060206@colorstudy.com>	<4899D508.7030001@v.loewis.de>	<4899DB3B.5000100@colorstudy.com>
	<4899DC03.3010203@colorstudy.com>
	<4899EB8E.4060006@weitershausen.de>
Message-ID: <4899EDF3.10809@colorstudy.com>

Philipp von Weitershausen wrote:
>> I personally like domains for projects, though package.pypi.python.org 
>> is a bit long winded anyway.  A new top-level domain (pypackage.org or 
>> pyforge.org or something) would mitigate that.  But any place to drop 
>> docs would be nice.  Especially with Sphinx I think we'll get more 
>> libraries with multi-page HTML docs.
> 
> What about distribution names with dots in them? Or worse, spaces? Both 
> are allowed by setuptools and PyPI and I've seen them in the wild 
> (especially dotted distribution names aren't uncommon when a namespaced 
> package is distributed under its package name, e.g. zope.interface).

Can't they be normalized?  I.e.:

   re.sub('--+', '-', re.sub('[^a-z0-9]', '-', package.lower()))

I *think* package names should be unique after this normalization, but 
I'm not sure.  It would be nice if no packages relied on punctuation or 
case to make them unique, regardless of this domain issue.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From dpeterson at enthought.com  Wed Aug  6 20:34:22 2008
From: dpeterson at enthought.com (Dave Peterson)
Date: Wed, 06 Aug 2008 13:34:22 -0500
Subject: [Catalog-sig] "distribution too large"  -- what is the limit?
Message-ID: <4899EEAE.3040406@enthought.com>

Hello,

The Mayavi project has recently started to include runtime accessible 
documentation in their distributions and this has pushed the latest 
Windows egg to 10,989,580 bytes in size.   I'm finding that this can't 
be uploaded into PyPi as I get a "distribution too large" message 
whenever using the upload command, or when manually trying to upload it 
to PyPi.

What is the limit I have to tell the Mayavi community to adhere to?   I 
used the search box on the PyPi pages and also tried googling a bit for 
the phrase "distribution too large" but couldn't come up with a limit.


Also, I'm still looking for help with re-casing the project registration 
from MayaVi to Mayavi.  Is there anyway to do this short of completely 
unregistering the project and re-registering it?


-- Dave

From martin at v.loewis.de  Wed Aug  6 20:35:33 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 06 Aug 2008 20:35:33 +0200
Subject: [Catalog-sig] Minimal required information before uploading
In-Reply-To: <9b06ffb10808061123r8aa65c8s6f23ec021bfd75c1@mail.gmail.com>
References: <9b06ffb10808061123r8aa65c8s6f23ec021bfd75c1@mail.gmail.com>
Message-ID: <4899EEF5.10106@v.loewis.de>

> Thoughts?

Please submit this as a report to the tracker, sf.net/projects/pypi.

I don't find it a serious problem that there are packages with
no description - those packages just won't get much attention.

Contributions to establish a policy and implement it are welcome.

Regards,
Martin

From martin at v.loewis.de  Wed Aug  6 20:39:49 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 06 Aug 2008 20:39:49 +0200
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <4899EDF3.10809@colorstudy.com>
References: <48995F4B.6060409@v.loewis.de>	<4899CE06.3060206@colorstudy.com>	<4899D508.7030001@v.loewis.de>	<4899DB3B.5000100@colorstudy.com>
	<4899DC03.3010203@colorstudy.com>
	<4899EB8E.4060006@weitershausen.de> <4899EDF3.10809@colorstudy.com>
Message-ID: <4899EFF5.8010109@v.loewis.de>

> Can't they be normalized?  I.e.:
> 
>   re.sub('--+', '-', re.sub('[^a-z0-9]', '-', package.lower()))
> 
> I *think* package names should be unique after this normalization, but
> I'm not sure.

Currently, they aren't unique under setuptools normalization, but I'm
working on fixing that. Whether or not this normalization will be
stricter, I don't know.

> It would be nice if no packages relied on punctuation or
> case to make them unique, regardless of this domain issue.

That's the setuptools normalization. Currently, there are about 20
packages which conflict under that normalization (in some cases,
these are registrations for the very same software, in other cases,
genuine naming conflicts).

Whether or not package owners would like the resulting host names
is questionable, IMO, so I would like to leave that option for further
study, and start with a single host name.

Regards,
Martin




From g.brandl at gmx.net  Wed Aug  6 23:47:30 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 06 Aug 2008 21:47:30 +0000
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <4899DC03.3010203@colorstudy.com>
References: <48995F4B.6060409@v.loewis.de>	<4899CE06.3060206@colorstudy.com>	<4899D508.7030001@v.loewis.de>	<4899DB3B.5000100@colorstudy.com>
	<4899DC03.3010203@colorstudy.com>
Message-ID: <g7cv60$svu$1@ger.gmane.org>

Ian Bicking schrieb:

> On second thought, simply by using a read-only domain (one that has no 
> admin on the domain itself) you'd also be fine.  So 
> http://pypidocs.python.org/package/* would work fine, so long as all the 
> management for that remained on pypi.python.org.
> 
> I personally like domains for projects, though package.pypi.python.org 
> is a bit long winded anyway.  A new top-level domain (pypackage.org or 
> pyforge.org or something) would mitigate that.  But any place to drop 
> docs would be nice.  Especially with Sphinx I think we'll get more 
> libraries with multi-page HTML docs.

JFTR, I also like the look of http://package.pypi.python.org/ and would
vote for subdomains if it can be done with decent normalization.

Of course, we can also only offer the domain to those distributions
with suitable names.

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From ianb at colorstudy.com  Wed Aug  6 21:54:35 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 06 Aug 2008 14:54:35 -0500
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <4899E3FF.2000600@v.loewis.de>
References: <48995F4B.6060409@v.loewis.de>
	<4899CE06.3060206@colorstudy.com>	<4899D508.7030001@v.loewis.de>
	<4899DB3B.5000100@colorstudy.com> <4899DC03.3010203@colorstudy.com>
	<4899E3FF.2000600@v.loewis.de>
Message-ID: <489A017B.6050708@colorstudy.com>

Martin v. L?wis wrote:
>> On second thought, simply by using a read-only domain (one that has no
>> admin on the domain itself) you'd also be fine.  So
>> http://pypidocs.python.org/package/* would work fine, so long as all the
>> management for that remained on pypi.python.org.
>>
>> I personally like domains for projects, though package.pypi.python.org
>> is a bit long winded anyway. 
> 
> It's not longer eventually than pypi.python.org/package, and I think I
> need to put /version also into it (right?), so with separate hosts, I
> get http://package.pypi.python.org/version, perhaps with the empty URL
> redirecting to the latest version.

I'm not that happy with PyPI versioning as it is (it seems to hurt 
searchability), and versioned docs would be worse yet.  Whenever I've 
thought about versioned docs, it seemed reasonable only if everything 
but the main version was hidden from search engines.  Coming upon old 
docs (perhaps because an old version lived for the longest) is a real 
problem with programming documentation that lives in too many places.

Also, I'd like the "current" version to be bookmarkable.  If every URL 
is bound to a version then you can't do that.

I guess I'd rather projects manage the whole space independently.  If 
you want versioned docs, upload directories of docs for every version. 
If you don't want that, then don't.  At least that lets projects do 
things like put in no-index tags into their version-specific docs, or 
put warnings into old doc versions.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From martin at v.loewis.de  Wed Aug  6 22:01:49 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 06 Aug 2008 22:01:49 +0200
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <g7cv60$svu$1@ger.gmane.org>
References: <48995F4B.6060409@v.loewis.de>	<4899CE06.3060206@colorstudy.com>	<4899D508.7030001@v.loewis.de>	<4899DB3B.5000100@colorstudy.com>	<4899DC03.3010203@colorstudy.com>
	<g7cv60$svu$1@ger.gmane.org>
Message-ID: <489A032D.7030206@v.loewis.de>

> JFTR, I also like the look of http://package.pypi.python.org/ and would
> vote for subdomains if it can be done with decent normalization.

It turns out to be quite tricky: the XS4ALL web interface for DNS
doesn't support the proper delegation/wildcards. An option would be
to register a new domain (pypi.org, pyforge.org, pypackages.org
are all gone already) were we can easier manage the zones; XS4ALL
might also be willing to perform a manual change in the zone (haven't
asked yet).

In any case, I view the normalization as the bigger issue.

> Of course, we can also only offer the domain to those distributions
> with suitable names.

That would also be an option. In that case, packages.python.org
would have to be available, anyway, and for those people with "funny"
project names, the DNS lookup would just fail (or then the Apache
virtual host lookup).

Regards,
Martin

From martin at v.loewis.de  Wed Aug  6 22:06:28 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 06 Aug 2008 22:06:28 +0200
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <489A017B.6050708@colorstudy.com>
References: <48995F4B.6060409@v.loewis.de>
	<4899CE06.3060206@colorstudy.com>	<4899D508.7030001@v.loewis.de>
	<4899DB3B.5000100@colorstudy.com> <4899DC03.3010203@colorstudy.com>
	<4899E3FF.2000600@v.loewis.de> <489A017B.6050708@colorstudy.com>
Message-ID: <489A0444.5000306@v.loewis.de>

> I guess I'd rather projects manage the whole space independently.  If
> you want versioned docs, upload directories of docs for every version.
> If you don't want that, then don't.  At least that lets projects do
> things like put in no-index tags into their version-specific docs, or
> put warnings into old doc versions.

Sounds reasonable. So it is just packages.python.org/<project> then,
and the upload interface is on the pkg_edit page (rather than the
submit_form page).

Regards,
Martin


From ianb at colorstudy.com  Wed Aug  6 22:09:16 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 06 Aug 2008 15:09:16 -0500
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <489A0444.5000306@v.loewis.de>
References: <48995F4B.6060409@v.loewis.de>
	<4899CE06.3060206@colorstudy.com>	<4899D508.7030001@v.loewis.de>
	<4899DB3B.5000100@colorstudy.com> <4899DC03.3010203@colorstudy.com>
	<4899E3FF.2000600@v.loewis.de> <489A017B.6050708@colorstudy.com>
	<489A0444.5000306@v.loewis.de>
Message-ID: <489A04EC.7040409@colorstudy.com>

Martin v. L?wis wrote:
>> I guess I'd rather projects manage the whole space independently.  If
>> you want versioned docs, upload directories of docs for every version.
>> If you don't want that, then don't.  At least that lets projects do
>> things like put in no-index tags into their version-specific docs, or
>> put warnings into old doc versions.
> 
> Sounds reasonable. So it is just packages.python.org/<project> then,
> and the upload interface is on the pkg_edit page (rather than the
> submit_form page).

What are you thinking about for upload?  Upload a zip file?  Some more 
RESTy interface?  A REST interface quickly turns into WebDAV, which is 
also kind of annoying to work with.  Does uploading new files implicitly 
remove all old files, or add to them?  Would something like rsync be 
possible to make it more efficient?  Probably automated tools will 
appear nearly instantly (I'd probably use the form about once before 
writing a tool), so something like an API is called for.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From martin at v.loewis.de  Wed Aug  6 22:17:30 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 06 Aug 2008 22:17:30 +0200
Subject: [Catalog-sig] Hosting documentation on PyPI
In-Reply-To: <489A04EC.7040409@colorstudy.com>
References: <48995F4B.6060409@v.loewis.de>
	<4899CE06.3060206@colorstudy.com>	<4899D508.7030001@v.loewis.de>
	<4899DB3B.5000100@colorstudy.com> <4899DC03.3010203@colorstudy.com>
	<4899E3FF.2000600@v.loewis.de> <489A017B.6050708@colorstudy.com>
	<489A0444.5000306@v.loewis.de> <489A04EC.7040409@colorstudy.com>
Message-ID: <489A06DA.6000901@v.loewis.de>

>> Sounds reasonable. So it is just packages.python.org/<project> then,
>> and the upload interface is on the pkg_edit page (rather than the
>> submit_form page).
> 
> What are you thinking about for upload?  Upload a zip file?  Some more
> RESTy interface? 

Initially, just a form upload, with fields for name and content. Content
must be a .tar.gz file.

> Does uploading new files implicitly
> remove all old files, or add to them?

It removes all files, yes.

> Would something like rsync be possible to make it more efficient?

If that ever gets a problem, we will have to buy more disks first, I
fear. It would be possible to set up rsync, yes, although I'm not sure
how to have rsync use the PyPI accounts for authentication - the
passwords aren't stored in a suitable form (instead, they are SHA
hashes). Does anybody have a Python rsync server :-?

I should probably set a size constraints on the file size also;
I really do fear abuse.

> Probably automated tools will
> appear nearly instantly (I'd probably use the form about once before
> writing a tool), so something like an API is called for.

Form upload is not a sufficient API?

Regards,
Martin




From martin at v.loewis.de  Thu Aug  7 12:50:20 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 07 Aug 2008 12:50:20 +0200
Subject: [Catalog-sig] Documentation hosting
Message-ID: <489AD36C.9030707@v.loewis.de>

I have now made the experimental documentation hosting service available.

Please try it out, and report any problems that you see.

Regards,
Martin

From martin at v.loewis.de  Thu Aug  7 18:52:59 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 07 Aug 2008 18:52:59 +0200
Subject: [Catalog-sig] Announcing documentation uploads
Message-ID: <489B286B.3030002@v.loewis.de>

Should uploads of documentation be announced to the RSS feed? Currently,
they are only logged in the database log (available through XML-RPC).

I see the following options:
1. no announcement at all
2. only announce uploads that don't replace previous files
3. announce updates also, but not more often than XXX
4. announce all updates, but avoid duplicates in the RSS files
   (i.e. across the last 30 entries - just as we do now for regular
   releases (*))
   (*) as an option, suppress documentation updates if a release
   is also among the last 30 changes

Regards,
Martin

From ianb at colorstudy.com  Thu Aug  7 22:07:30 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 07 Aug 2008 15:07:30 -0500
Subject: [Catalog-sig] Announcing documentation uploads
In-Reply-To: <489B286B.3030002@v.loewis.de>
References: <489B286B.3030002@v.loewis.de>
Message-ID: <489B5602.6090108@colorstudy.com>

Martin v. L?wis wrote:
> Should uploads of documentation be announced to the RSS feed? Currently,
> they are only logged in the database log (available through XML-RPC).

I don't think we should announce updates.  I wouldn't find them useful. 
  An alternate feed that announced new documentation might be useful to 
some people... but even that doesn't seem terribly interesting. 
However, creating per-project feeds for documentation would be useful. 
Or, if there were per-project feeds generally that would be even better, 
which could include documentation and package updates.

(If we're talking about feeds, I wish there was a feed that only 
included new projects, not updates)


-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From lists at zopyx.com  Mon Aug 11 08:56:30 2008
From: lists at zopyx.com (Andreas Jung)
Date: Mon, 11 Aug 2008 08:56:30 +0200
Subject: [Catalog-sig] High-availability for PyPI, mirroring infrastructures?
Message-ID: <69827A17F9EBCBA3995FD60A@[192.168.0.24]>

Hi there,

Python eggs and zc.buildout are playing a major role in Zope world - both 
for development and deployment. PyPI right now is apparently a 
single-point-of-failure. Although the availability of PyPI become much 
better over time, the complete infrastructure is not highly available which 
is crucial when you are doing commercial development.

What is the perspective for addressing this issue? I have seen that 
Ingeniweb maintains/maintained a PyPI mirror (does not seem to be up2date).
What is the current recommended way for building a (private) mirror?
How big (in GB) is currently PI? If a company would be interested to 
provide a mirroring server, how much diskspace (and bandwidth) would be 
needed?

Regards,
Andreas


-- 
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 T?bingen - Germany
Web: www.zopyx.com - Email: info at zopyx.com - Phone +49 - 7071 - 793376
Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535
Gesch?ftsf?hrer/Gesellschafter: ZOPYX Limited, Birmingham, UK
------------------------------------------------------------------------
E-Publishing, Python, Zope & Plone development, Consulting
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20080811/96090c24/attachment.pgp>

From tarek.ziade at ingeniweb.com  Mon Aug 11 09:48:12 2008
From: tarek.ziade at ingeniweb.com (Tarek Ziade)
Date: Mon, 11 Aug 2008 09:48:12 +0200
Subject: [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <69827A17F9EBCBA3995FD60A@192.168.0.24>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
Message-ID: <a26746990808110048m2a333765jcf72ee0c134825@mail.gmail.com>

2008/8/11 Andreas Jung <lists at zopyx.com>

> Hi there,
>
> Python eggs and zc.buildout are playing a major role in Zope world - both
> for development and deployment. PyPI right now is apparently a
> single-point-of-failure. Although the availability of PyPI become much
> better over time, the complete infrastructure is not highly available which
> is crucial when you are doing commercial development.
>
> What is the perspective for addressing this issue? I have seen that
> Ingeniweb maintains/maintained a PyPI mirror (does not seem to be up2date).
> What is the current recommended way for building a (private) mirror?


Hi Andreas

to do our mirror, we use iw.eggproxy. It is a simple web proxy that grabs
files over pypi upon requests.
every file is then kept locally for the next call.

I know Zope Corp has another script that generates a local copy by scanning
PyPI through XML-RPC
but it is a full copy.



> How big (in GB) is currently PI? If a company would be interested to
> provide a mirroring server, how much diskspace (and bandwidth) would be
> needed?


Around 5 gigas iirc

Regards

Tarek


>
>
> Regards,
> Andreas
>
>
> --
> ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 T?bingen - Germany
> Web: www.zopyx.com - Email: info at zopyx.com - Phone +49 - 7071 - 793376
> Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535
> Gesch?ftsf?hrer/Gesellschafter: ZOPYX Limited, Birmingham, UK
> ------------------------------------------------------------------------
> E-Publishing, Python, Zope & Plone development, Consulting
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
>


-- 
Tarek Ziad? - Directeur Technique
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royale - B?timent D - 9?me ?tage
92210 Saint Cloud - France
Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une soci?t? du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20080811/61492af4/attachment.htm>

From philipp at weitershausen.de  Mon Aug 11 12:03:32 2008
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Mon, 11 Aug 2008 12:03:32 +0200
Subject: [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <a26746990808110048m2a333765jcf72ee0c134825@mail.gmail.com>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
	<a26746990808110048m2a333765jcf72ee0c134825@mail.gmail.com>
Message-ID: <48A00E74.8090701@weitershausen.de>

Tarek Ziade wrote:
> 2008/8/11 Andreas Jung <lists at zopyx.com <mailto:lists at zopyx.com>>
> 
>     Hi there,
> 
>     Python eggs and zc.buildout are playing a major role in Zope world -
>     both for development and deployment. PyPI right now is apparently a
>     single-point-of-failure. Although the availability of PyPI become
>     much better over time, the complete infrastructure is not highly
>     available which is crucial when you are doing commercial development.
> 
>     What is the perspective for addressing this issue? I have seen that
>     Ingeniweb maintains/maintained a PyPI mirror (does not seem to be
>     up2date).
>     What is the current recommended way for building a (private) mirror?
> 
> 
> Hi Andreas
> 
> to do our mirror, we use iw.eggproxy. It is a simple web proxy that 
> grabs files over pypi upon requests.
> every file is then kept locally for the next call.
> 
> I know Zope Corp has another script that generates a local copy by 
> scanning PyPI through XML-RPC
> but it is a full copy.

Yes, zc.mirrorpypislashsimple creates a full copy in the sense that it 
mirrors the pages of *every* package. However, it does not mirror the 
actual download archives. They are still retrieved from python.org.

I'm sure that it could be extended to download those as well, though.

>     How big (in GB) is currently PI? If a company would be interested to
>     provide a mirroring server, how much diskspace (and bandwidth) would
>     be needed?
> 
> 
> Around 5 gigas iirc

By extending zc.mirrorpypislashsimple to also download archives one 
could just try ;).


From lists at zopyx.com  Mon Aug 11 13:11:24 2008
From: lists at zopyx.com (Andreas Jung)
Date: Mon, 11 Aug 2008 13:11:24 +0200
Subject: [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <48A00E74.8090701@weitershausen.de>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
	<a26746990808110048m2a333765jcf72ee0c134825@mail.gmail.com>
	<48A00E74.8090701@weitershausen.de>
Message-ID: <539DFE864DAE0BE3E92D9319@[192.168.0.24]>



--On 11. August 2008 12:03:32 +0200 Philipp von Weitershausen 
<philipp at weitershausen.de> wrote:

>>
>> I know Zope Corp has another script that generates a local copy by
>> scanning PyPI through XML-RPC
>> but it is a full copy.
>
> Yes, zc.mirrorpypislashsimple creates a full copy in the sense that it
> mirrors the pages of *every* package. However, it does not mirror the
> actual download archives. They are still retrieved from python.org.
>
>

zc.mirrorpypislashsimple is not much helpful right now since it does not
mirror the real data (just checked the code and played a bit with it).

A task for our Blackforest sprint would be:

 - all to pass-in a configuration file where you define with packages should
   be mirrored where each line of the configuration would represent a
   package pattern:

   mirror.cfg:
   zope.*
   collective.*
   z3c.*
   lovely.*

This would also fit in our haufe.eggserver infrastructure where we maintain
a local egg repository on the filesystem.   zc.mirrorpypislashsimple could 
directly sync PyPI with our local egg server.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20080811/89189eca/attachment.pgp>

From tarek.ziade at ingeniweb.com  Mon Aug 11 13:49:24 2008
From: tarek.ziade at ingeniweb.com (Tarek Ziade)
Date: Mon, 11 Aug 2008 13:49:24 +0200
Subject: [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <539DFE864DAE0BE3E92D9319@192.168.0.24>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
	<a26746990808110048m2a333765jcf72ee0c134825@mail.gmail.com>
	<48A00E74.8090701@weitershausen.de>
	<539DFE864DAE0BE3E92D9319@192.168.0.24>
Message-ID: <a26746990808110449k752a77b1p340776126786fa92@mail.gmail.com>

2008/8/11 Andreas Jung <lists at zopyx.com>

>
>
> --On 11. August 2008 12:03:32 +0200 Philipp von Weitershausen <
> philipp at weitershausen.de> wrote:
>
>
>>> I know Zope Corp has another script that generates a local copy by
>>> scanning PyPI through XML-RPC
>>> but it is a full copy.
>>>
>>
>> Yes, zc.mirrorpypislashsimple creates a full copy in the sense that it
>> mirrors the pages of *every* package. However, it does not mirror the
>> actual download archives. They are still retrieved from python.org.
>>
>>
>>
> zc.mirrorpypislashsimple is not much helpful right now since it does not
> mirror the real data (just checked the code and played a bit with it).
>
> A task for our Blackforest sprint would be:
>
> - all to pass-in a configuration file where you define with packages should
>  be mirrored where each line of the configuration would represent a
>  package pattern:
>
>  mirror.cfg:
>  zope.*
>  collective.*
>  z3c.*
>  lovely.*
>
> This would also fit in our haufe.eggserver infrastructure where we maintain
> a local egg repository on the filesystem.   zc.mirrorpypislashsimple could
> directly sync PyPI with our local egg server.


Our approach for this is to let the buildouts/easy_install scripts drive the
mirror, e.g. only the archives that are needed are pulled
on demand. The benefit of this approach is that you don't have to specify
which packages are mirrored in a configuration file.

Tarek


>
> Andreas




-- 
Tarek Ziad? - Directeur Technique
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royale - B?timent D - 9?me ?tage
92210 Saint Cloud - France
Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une soci?t? du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20080811/762cf9c7/attachment.htm>

From martin at v.loewis.de  Mon Aug 11 20:10:38 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 11 Aug 2008 20:10:38 +0200
Subject: [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <69827A17F9EBCBA3995FD60A@[192.168.0.24]>
References: <69827A17F9EBCBA3995FD60A@[192.168.0.24]>
Message-ID: <48A0809E.3080406@v.loewis.de>

> What is the perspective for addressing this issue?

It all depends on the community.

> What is the current recommended way for building a (private) mirror?

The easiest way is to mirror just the index, not the files. To do so,
mirror the simple index, and watch the log file per XML-RPC for changes.

If you also plan to mirror the files, please consider providing a way of
updating the download counters on the central server. This hasn't been
done before, so an API would need to be designed and implemented first.

> How big (in GB) is currently PI?

The mere files are 3.9GiB. Disk space for the index itself depends on
how you store it, as the web pages are all generated. The postgres dump
is 85MiB.

> If a company would be interested to
> provide a mirroring server, how much diskspace (and bandwidth) would be
> needed?

PyPI currently sees roughly 150GiB downloads per month (including
generated content).

Regards,
Martin

From martin at v.loewis.de  Mon Aug 11 20:16:47 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 11 Aug 2008 20:16:47 +0200
Subject: [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <48A00E74.8090701@weitershausen.de>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>	<a26746990808110048m2a333765jcf72ee0c134825@mail.gmail.com>
	<48A00E74.8090701@weitershausen.de>
Message-ID: <48A0820F.2040802@v.loewis.de>

> By extending zc.mirrorpypislashsimple to also download archives one
> could just try ;).

If you make this a public mirror, please consider the issue of download
counters. If it is just caching for your own organization, I don't think
collecting download counters would be necessary.

Regards,
Martin

From jim at zope.com  Mon Aug 11 21:50:16 2008
From: jim at zope.com (Jim Fulton)
Date: Mon, 11 Aug 2008 15:50:16 -0400
Subject: [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <69827A17F9EBCBA3995FD60A@[192.168.0.24]>
References: <69827A17F9EBCBA3995FD60A@[192.168.0.24]>
Message-ID: <BA62AA2F-8249-4D11-90FC-680FE2CF8A32@zope.com>


On Aug 11, 2008, at 2:56 AM, Andreas Jung wrote:

> Hi there,
>
> Python eggs and zc.buildout are playing a major role in Zope world -  
> both for development and deployment. PyPI right now is apparently a  
> single-point-of-failure. Although the availability of PyPI become  
> much better over time, the complete infrastructure is not highly  
> available which is crucial when you are doing commercial development.
>
> What is the perspective for addressing this issue? I have seen that  
> Ingeniweb maintains/maintained a PyPI mirror (does not seem to be  
> up2date).

There's also one at http://download.zope.org/simple/

> What is the current recommended way for building a (private) mirror?

There's a project at http://svn.zope.org/ 
zc.mirrorcheeseshopslashsimple/ for mirroring the pypi index data.

In terms of reducing risk, I think that zc.sourcerelease is also  
relevant, because it lets you make a self-contained snapshot of an  
application's source, with all of the eggs used.  If you need to  
deploy an application, you can use a source release, or a binary  
release built from it, without any need to talk to a package index.

Jim

--
Jim Fulton
Zope Corporation



From tarek.ziade at ingeniweb.com  Tue Aug 12 10:41:32 2008
From: tarek.ziade at ingeniweb.com (Tarek Ziade)
Date: Tue, 12 Aug 2008 10:41:32 +0200
Subject: [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <BA62AA2F-8249-4D11-90FC-680FE2CF8A32@zope.com>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
	<BA62AA2F-8249-4D11-90FC-680FE2CF8A32@zope.com>
Message-ID: <a26746990808120141t4f63b622ma24ac8427eb20ca0@mail.gmail.com>

2008/8/11 Jim Fulton <jim at zope.com>

>
> On Aug 11, 2008, at 2:56 AM, Andreas Jung wrote:
>
>  Hi there,
>>
>> Python eggs and zc.buildout are playing a major role in Zope world - both
>> for development and deployment. PyPI right now is apparently a
>> single-point-of-failure. Although the availability of PyPI become much
>> better over time, the complete infrastructure is not highly available which
>> is crucial when you are doing commercial development.
>>
>> What is the perspective for addressing this issue? I have seen that
>> Ingeniweb maintains/maintained a PyPI mirror (does not seem to be up2date).
>>
>
> There's also one at http://download.zope.org/simple/
>
>  What is the current recommended way for building a (private) mirror?
>>
>
> There's a project at http://svn.zope.org/zc.mirrorcheeseshopslashsimple/
> for mirroring the pypi index data.
>
> In terms of reducing risk, I think that zc.sourcerelease is also relevant,
> because it lets you make a self-contained snapshot of an application's
> source, with all of the eggs used.  If you need to deploy an application,
> you can use a source release, or a binary release built from it, without any
> need to talk to a package index.


Jim,
Since mirrors for PyPI and alternative egg servers are being , what about
making the "index" variable in
zc.buildout accept multiple values, like what find-links does ?

This could let us use these mirrors/alternative servers at the buildout
level like this:

  [buildout]

  index =
      http://my.mirror1/simple
      http://pypi.python.org/simple
      http://my.alternative.egg.server/simple

and let buildout look for packages in each Package index object,
sequentially

two use cases:

- a mirror or PyPI is down
- an egg is not present in every server

Tarek


>
> Jim
>
> --
> Jim Fulton
> Zope Corporation
>
>
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>



-- 
Tarek Ziad? - Directeur Technique
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royale - B?timent D - 9?me ?tage
92210 Saint Cloud - France
Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une soci?t? du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20080812/cd48a7d5/attachment-0001.htm>

From tarek.ziade at ingeniweb.com  Tue Aug 12 10:48:23 2008
From: tarek.ziade at ingeniweb.com (Tarek Ziade)
Date: Tue, 12 Aug 2008 10:48:23 +0200
Subject: [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <48A0820F.2040802@v.loewis.de>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
	<a26746990808110048m2a333765jcf72ee0c134825@mail.gmail.com>
	<48A00E74.8090701@weitershausen.de> <48A0820F.2040802@v.loewis.de>
Message-ID: <a26746990808120148j4dee1cdboefb66e180ec2299f@mail.gmail.com>

2008/8/11 "Martin v. L?wis" <martin at v.loewis.de>

> > By extending zc.mirrorpypislashsimple to also download archives one
> > could just try ;).
>
> If you make this a public mirror, please consider the issue of download
> counters. If it is just caching for your own organization, I don't think
> collecting download counters would be necessary.
>
> Regards,
> Martin


Notice that it would be interesting to group the download counter by client
type,
to know if the package was downloaded manually or automatically by tools
like easy_install
or zc.buildout:

some packages like zc.recipe.egg have high values because they are
automatically downloaded
everytime someone builds an application with zc.buildout.

This would involve clients to provide the info in the request headers of
course.

Tarek


-- 
Tarek Ziad? - Directeur Technique
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royale - B?timent D - 9?me ?tage
92210 Saint Cloud - France
Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une soci?t? du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20080812/f9671f3e/attachment.htm>

From jim at zope.com  Tue Aug 12 13:59:23 2008
From: jim at zope.com (Jim Fulton)
Date: Tue, 12 Aug 2008 07:59:23 -0400
Subject: [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <a26746990808120141t4f63b622ma24ac8427eb20ca0@mail.gmail.com>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
	<BA62AA2F-8249-4D11-90FC-680FE2CF8A32@zope.com>
	<a26746990808120141t4f63b622ma24ac8427eb20ca0@mail.gmail.com>
Message-ID: <148B5531-CBA3-4BB2-AEDB-860EF85E50B3@zope.com>


On Aug 12, 2008, at 4:41 AM, Tarek Ziade wrote:
...
> Since mirrors for PyPI and alternative egg servers are being , what  
> about making the "index" variable in
> zc.buildout accept multiple values, like what find-links does ?


Buildout uses and tries hard to be compatible with setuptools. In  
particular, it relies on the setuptools.package_index.PackageIndex  
class, which only allows a single index to be provided.  If we want to  
allow multiple indexes to be used, then support should be added to  
setuptools and easy_install first.

Jim

--
Jim Fulton
Zope Corporation



From tarek.ziade at ingeniweb.com  Tue Aug 12 14:13:00 2008
From: tarek.ziade at ingeniweb.com (Tarek Ziade)
Date: Tue, 12 Aug 2008 14:13:00 +0200
Subject: [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <148B5531-CBA3-4BB2-AEDB-860EF85E50B3@zope.com>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
	<BA62AA2F-8249-4D11-90FC-680FE2CF8A32@zope.com>
	<a26746990808120141t4f63b622ma24ac8427eb20ca0@mail.gmail.com>
	<148B5531-CBA3-4BB2-AEDB-860EF85E50B3@zope.com>
Message-ID: <a26746990808120513w34df129ap44c6ea971df1255c@mail.gmail.com>

2008/8/12 Jim Fulton <jim at zope.com>

>
> On Aug 12, 2008, at 4:41 AM, Tarek Ziade wrote:
> ...
>
>> Since mirrors for PyPI and alternative egg servers are being , what about
>> making the "index" variable in
>> zc.buildout accept multiple values, like what find-links does ?
>>
>
>
> Buildout uses and tries hard to be compatible with setuptools. In
> particular, it relies on the setuptools.package_index.PackageIndex class,
> which only allows a single index to be provided.


Yes, I was thinking of handling several PackageIndex instances on
zc.buildout side as a first thaught.

We have started to play with several index instance in our Proxy, which
assumes it does a bit of conflict/order resolving
but it seems feasible.



>  If we want to allow multiple indexes to be used, then support should be
> added to setuptools and easy_install first.


It sounds right to do it on setuptools level yes, I'll add a feature request
on setuptools tracker to see what Philip says then.

Tarek



>
> Jim
>
> --
> Jim Fulton
> Zope Corporation
>
>
>


-- 
Tarek Ziad? - Directeur Technique
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royale - B?timent D - 9?me ?tage
92210 Saint Cloud - France
Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une soci?t? du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20080812/0f43667c/attachment.htm>

From pje at telecommunity.com  Tue Aug 12 17:09:17 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 12 Aug 2008 11:09:17 -0400
Subject: [Catalog-sig] High-availability for PyPI,
 mirroring  infrastructures?
In-Reply-To: <a26746990808120513w34df129ap44c6ea971df1255c@mail.gmail.co
 m>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
	<BA62AA2F-8249-4D11-90FC-680FE2CF8A32@zope.com>
	<a26746990808120141t4f63b622ma24ac8427eb20ca0@mail.gmail.com>
	<148B5531-CBA3-4BB2-AEDB-860EF85E50B3@zope.com>
	<a26746990808120513w34df129ap44c6ea971df1255c@mail.gmail.com>
Message-ID: <20080812150824.20D4B3A4093@sparrow.telecommunity.com>

At 02:13 PM 8/12/2008 +0200, Tarek Ziade wrote:
>2008/8/12 Jim Fulton <<mailto:jim at zope.com>jim at zope.com>
>
>On Aug 12, 2008, at 4:41 AM, Tarek Ziade wrote:
>...
>
>Since mirrors for PyPI and alternative egg servers are being , what 
>about making the "index" variable in
>zc.buildout accept multiple values, like what find-links does ?
>
>
>
>Buildout uses and tries hard to be compatible with setuptools. In 
>particular, it relies on the setuptools.package_index.PackageIndex 
>class, which only allows a single index to be provided.
>
>
>Yes, I was thinking of handling several PackageIndex instances on 
>zc.buildout side as a first thaught.

What you really want/need is to make the PackageIndex support 
retrieval from multiple index urls; the PackageIndex itself 
aggregates available packages from sources such as the local file 
system, -f urls, and an underlying package index.  So having multiple 
aggregators would duplicate processing, and deprive you of a global 
ordering of package precedences.


From martin at v.loewis.de  Tue Aug 12 20:22:03 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 12 Aug 2008 20:22:03 +0200
Subject: [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <a26746990808120148j4dee1cdboefb66e180ec2299f@mail.gmail.com>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>	
	<a26746990808110048m2a333765jcf72ee0c134825@mail.gmail.com>	
	<48A00E74.8090701@weitershausen.de> <48A0820F.2040802@v.loewis.de>
	<a26746990808120148j4dee1cdboefb66e180ec2299f@mail.gmail.com>
Message-ID: <48A1D4CB.8080108@v.loewis.de>

> Notice that it would be interesting to group the download counter by 
> client type, to know if the package was downloaded manually or
> automatically by tools like easy_install or zc.buildout:
> 
> some packages like zc.recipe.egg have high values because they are 
> automatically downloaded everytime someone builds an application with
> zc.buildout.
> 
> This would involve clients to provide the info in the request headers
> of course.

Good idea. As with any other PyPI improvements, I won't have the time
to do that in a foreseeable future, so contributions are welcome.
I could install patches to enable such counting if it patches were
provided.

Regards,
Martin


From tarek.ziade at ingeniweb.com  Wed Aug 13 19:22:18 2008
From: tarek.ziade at ingeniweb.com (Tarek Ziade)
Date: Wed, 13 Aug 2008 19:22:18 +0200
Subject: [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <20080812150824.20D4B3A4093@sparrow.telecommunity.com>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
	<BA62AA2F-8249-4D11-90FC-680FE2CF8A32@zope.com>
	<a26746990808120141t4f63b622ma24ac8427eb20ca0@mail.gmail.com>
	<148B5531-CBA3-4BB2-AEDB-860EF85E50B3@zope.com>
	<a26746990808120513w34df129ap44c6ea971df1255c@mail.gmail.com>
	<20080812150824.20D4B3A4093@sparrow.telecommunity.com>
Message-ID: <a26746990808131022l4e0946a0qd6ee63031c8f7b4e@mail.gmail.com>

2008/8/12 Phillip J. Eby <pje at telecommunity.com>

> At 02:13 PM 8/12/2008 +0200, Tarek Ziade wrote:
>
>> 2008/8/12 Jim Fulton <<mailto:jim at zope.com>jim at zope.com>
>>
>> On Aug 12, 2008, at 4:41 AM, Tarek Ziade wrote:
>> ...
>>
>> Since mirrors for PyPI and alternative egg servers are being , what about
>> making the "index" variable in
>> zc.buildout accept multiple values, like what find-links does ?
>>
>>
>>
>> Buildout uses and tries hard to be compatible with setuptools. In
>> particular, it relies on the setuptools.package_index.PackageIndex class,
>> which only allows a single index to be provided.
>>
>>
>> Yes, I was thinking of handling several PackageIndex instances on
>> zc.buildout side as a first thaught.
>>
>
> What you really want/need is to make the PackageIndex support retrieval
> from multiple index urls; the PackageIndex itself aggregates available
> packages from sources such as the local file system, -f urls, and an
> underlying package index.  So having multiple aggregators would duplicate
> processing, and deprive you of a global ordering of package precedences.
>
>
Is this a feature you would like to see in setuptools ? If so I can write a
patch,

Besides this feature, there's one feature we started to add on zc.buildout
but could be put in setuptools's PackageIndex as well I believe :

Adding timeouts for url openings, to speed up the processing. For instance,
when several urls are visited for
a given package, and when a server pointed by one of the url is down, it can
last forever.

urlib2.urlopen does not have a timeout option yet, even if it has been
discussed for Python 2.6 inclusion, 2 years ago  [1]
So we used *socket*.*setdefaulttimeout*() , which looks safe to change in
this use case.

At zc.buildout level, we could wait for up to 5 minutes to finish a buildout
upgrade,
and setting the timeout to a few seconds solved the problem efficiently.

In a shape of a decorator, that could be :

# five seconds
TIMEOUT = 5

def timedout(func):
    def _timedout(*args, **kw):
        old =socket.getdefaulttimeout()
        socket.setdefaulttimeout(TIMEOUT)
        try:
            return func(*args, **kw)
        finally:
            socket.setdefaulttimeout(old)
    return _timedout


Tarek

[1] http://mail.python.org/pipermail/python-dev/2006-July/066965.html

-- 
Tarek Ziad? - Directeur Technique
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royale - B?timent D - 9?me ?tage
92210 Saint Cloud - France
Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une soci?t? du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20080813/977c1329/attachment.htm>

From pje at telecommunity.com  Wed Aug 20 15:43:44 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 20 Aug 2008 09:43:44 -0400
Subject: [Catalog-sig] High-availability for PyPI,
 mirroring  infrastructures?
In-Reply-To: <a26746990808131022l4e0946a0qd6ee63031c8f7b4e@mail.gmail.co
 m>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
	<BA62AA2F-8249-4D11-90FC-680FE2CF8A32@zope.com>
	<a26746990808120141t4f63b622ma24ac8427eb20ca0@mail.gmail.com>
	<148B5531-CBA3-4BB2-AEDB-860EF85E50B3@zope.com>
	<a26746990808120513w34df129ap44c6ea971df1255c@mail.gmail.com>
	<20080812150824.20D4B3A4093@sparrow.telecommunity.com>
	<a26746990808131022l4e0946a0qd6ee63031c8f7b4e@mail.gmail.com>
Message-ID: <20080820134254.7C0493A4079@sparrow.telecommunity.com>

At 07:22 PM 8/13/2008 +0200, Tarek Ziade wrote:
>2008/8/12 Phillip J. Eby <<mailto:pje at telecommunity.com>pje at telecommunity.com>
>What you really want/need is to make the PackageIndex support 
>retrieval from multiple index urls; the PackageIndex itself 
>aggregates available packages from sources such as the local file 
>system, -f urls, and an underlying package index.  So having 
>multiple aggregators would duplicate processing, and deprive you of 
>a global ordering of package precedences.
>
>Is this a feature you would like to see in setuptools ? If so I can 
>write a patch,

Just be aware that I'm likely to be rather picky about how it works.  :)


>Besides this feature, there's one feature we started to add on 
>zc.buildout but could be put in setuptools's PackageIndex as well I believe :

Having the option to set a short timeout for *connections* would be 
useful, I think, just as long as it doesn't end up cutting off slow 
downloads.  I'd prefer it to be controllable from the command line, 
nonetheless.


From joachim.koenig-baltes at emesgarten.de  Thu Aug 28 16:30:27 2008
From: joachim.koenig-baltes at emesgarten.de (=?ISO-8859-15?Q?Joachim_K=F6nig-Baltes?=)
Date: Thu, 28 Aug 2008 16:30:27 +0200
Subject: [Catalog-sig] licensing and accessability of code on pypi
Message-ID: <48B6B683.5090000@emesgarten.de>

Today I got aware of pySSH_Monitor through my RSS reader. Trying to download
the code by clicking on the download link on pypi I got redirected to 
www.pypi.info
that requires registration through invitation only (by whoom anyway?).

Looking a bit closer at the licensing information on pypi for the 
package, the licensing is very restrictive,
e.g.

- "may not be used for any commercial purpose whatsoever ..."
- as long as "... there was never any intent to use this package to 
generate any income of any kind."
- "...may not redistribute this package without prior written permission 
from the author."

see below for details.

Is this kind of licensing something that is intended for 
pypi.python.org? I tried to find
some guidelines for this when uploading stuff, but did not find hints.

What's the community's opinion on that?

Joachim

PS: Excerpt from the pypi.python.org  page of pySSH_Monitor below:
> pySSH_Monitor 1.0
>
> pySSH_Monitor monitors your SSH logins to make sure they are functional.
>
> pySSH_Monitor monitors your SSH logins to make sure they are functional.
>
> Features:
>
> wxPython powered GUI with system tray icon that shows the status of 
> the monitored systems.
>
> Emails sent to the appropriate addresses whenever there is a problem.
>
> See also: http://www.pypi.info
>
> Disclaimer: The author of this program makes no warranty as to the 
> suitability of this program for any purpose whatsoever nor is there 
> any warranty to as to whether this program will be able to properly 
> handle your specific needs.
>
> (c). Copyright 2007-2008, Ray C Horn (raychorn at hotmail.com) and 
> Hierarchical Applications Limited, Inc., All Rights Reserved.
>
> This software package and all contents contained herein may not be 
> used for any commercial purpose whatsoever however it may be used for 
> educational purposes so long as the end-goal or end-product is of a 
> non-commercial purpose and there was never any intent to use this 
> package to generate any income of any kind.
>
> You may not redistribute this package without prior written permission 
> from the author.
[...] additional long detailed license text not copied

From lists at zopyx.com  Thu Aug 28 16:42:38 2008
From: lists at zopyx.com (Andreas Jung)
Date: Thu, 28 Aug 2008 16:42:38 +0200
Subject: [Catalog-sig] licensing and accessability of code on pypi
In-Reply-To: <48B6B683.5090000@emesgarten.de>
References: <48B6B683.5090000@emesgarten.de>
Message-ID: <09D14DA588616E38CEC2AB32@suxmac.local>



--On 28. August 2008 16:30:27 +0200 Joachim K?nig-Baltes 
<joachim.koenig-baltes at emesgarten.de> wrote:

> Today I got aware of pySSH_Monitor through my RSS reader. Trying to
> download
> the code by clicking on the download link on pypi I got redirected to
> www.pypi.info
> that requires registration through invitation only (by whoom anyway?).
>
> Looking a bit closer at the licensing information on pypi for the
> package, the licensing is very restrictive,
> e.g.
>
> - "may not be used for any commercial purpose whatsoever ..."
> - as long as "... there was never any intent to use this package to
> generate any income of any kind."
> - "...may not redistribute this package without prior written permission
> from the author."
>
> see below for details.

The package is released under the Creative Commons license.
And of course it is legitimate to use such a license - even if it
excludes the use for commercial use.


> What's the community's opinion on that?

That's the first time I see the CC in the context of software (I thought 
the CC would be focused on print works, book etc.). Anyway...the exclusion 
of commercial usage is just stupid (possibly it is unintended by the 
author). No idea what the intention of the author is. If one wants some 
revenues from a commercial usage, one can always dual-license a 
software...prohibitting its use for a commercial purpose under all 
circumstances is just odd.

-aj

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20080828/bd37eb58/attachment.pgp>

From nathan at creativecommons.org  Thu Aug 28 16:57:57 2008
From: nathan at creativecommons.org (Nathan Yergler)
Date: Thu, 28 Aug 2008 07:57:57 -0700
Subject: [Catalog-sig] licensing and accessability of code on pypi
In-Reply-To: <09D14DA588616E38CEC2AB32@suxmac.local>
References: <48B6B683.5090000@emesgarten.de>
	<09D14DA588616E38CEC2AB32@suxmac.local>
Message-ID: <c1a864630808280757w3a57f612t54c8417855aea31a@mail.gmail.com>

The author of the package is clearly confused with respect to
licensing.  It appears he's using CC Attribution-Non Commercial which
allows unlimited, non-commercial redistribution.  If you release
something under a CC license, you can't also required permission for
redistribution.  We also specifically discourage the use of CC
licenses for software -- they just weren't designed for that purpose
and there are lots of excellent open source/free software licenses
that were.

For what it's worth.

Nathan


On Thu, Aug 28, 2008 at 7:42 AM, Andreas Jung <lists at zopyx.com> wrote:
>
>
> --On 28. August 2008 16:30:27 +0200 Joachim K?nig-Baltes
> <joachim.koenig-baltes at emesgarten.de> wrote:
>
>> Today I got aware of pySSH_Monitor through my RSS reader. Trying to
>> download
>> the code by clicking on the download link on pypi I got redirected to
>> www.pypi.info
>> that requires registration through invitation only (by whoom anyway?).
>>
>> Looking a bit closer at the licensing information on pypi for the
>> package, the licensing is very restrictive,
>> e.g.
>>
>> - "may not be used for any commercial purpose whatsoever ..."
>> - as long as "... there was never any intent to use this package to
>> generate any income of any kind."
>> - "...may not redistribute this package without prior written permission
>> from the author."
>>
>> see below for details.
>
> The package is released under the Creative Commons license.
> And of course it is legitimate to use such a license - even if it
> excludes the use for commercial use.
>
>
>> What's the community's opinion on that?
>
> That's the first time I see the CC in the context of software (I thought the
> CC would be focused on print works, book etc.). Anyway...the exclusion of
> commercial usage is just stupid (possibly it is unintended by the author).
> No idea what the intention of the author is. If one wants some revenues from
> a commercial usage, one can always dual-license a software...prohibitting
> its use for a commercial purpose under all circumstances is just odd.
>
> -aj
>
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
>

From pje at telecommunity.com  Thu Aug 28 17:14:32 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 28 Aug 2008 11:14:32 -0400
Subject: [Catalog-sig] licensing and accessability of code on pypi
In-Reply-To: <48B6B683.5090000@emesgarten.de>
References: <48B6B683.5090000@emesgarten.de>
Message-ID: <20080828151810.684583A410E@sparrow.telecommunity.com>

At 04:30 PM 8/28/2008 +0200, Joachim K?nig-Baltes wrote:
>Today I got aware of pySSH_Monitor through my RSS reader. Trying to download
>the code by clicking on the download link on pypi I got redirected 
>to www.pypi.info
>that requires registration through invitation only (by whoom anyway?).

That site appears to be infringing on PSF trademarks; it is clearly a 
commercial site (many pages with almost no content besides 
advertising) and is using the Python logo (and the PyPI name) in a 
way that is likely to be confusing as to the origin of the 
materials.  ISTM that it's cut-and-dried trademark infringement under 
US law at least, and that the PSF should send them a cease-and-desist letter.

Oh, and the site includes a fair amount of content either scraped or 
copied and pasted from python.org et al...  and it appears the 
creator of the site also runs pyeggs.com, where the company claims to 
be "The Python Company"...  another possible TM issue.  And on that 
site, they claim to be using the Python trademark by permission.

ISTM that both sites should at minimum be disclaiming ownership or 
association with the PSF, and properly identifying the source of their content.


From 4vinoth at gmail.com  Fri Aug 29 10:50:40 2008
From: 4vinoth at gmail.com (vin vin)
Date: Fri, 29 Aug 2008 14:20:40 +0530
Subject: [Catalog-sig] New Category Request
Message-ID: <6176a14d0808290150k52640a0dobae2f7bb82e66fbb@mail.gmail.com>

HI

I am Vinoth from Nettri.org New Python Web Application Framework.

This will be nice if you provide me a New category on Package index store
named "*Nettri*" for Netrri Development.

Thank  You
Vinoth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20080829/457a3489/attachment.htm>

From me at gustavonarea.net  Sat Aug 30 23:04:44 2008
From: me at gustavonarea.net (Gustavo Narea)
Date: Sat, 30 Aug 2008 23:04:44 +0200
Subject: [Catalog-sig] New category: repoze.who.plugins
Message-ID: <200808302304.44528.me@gustavonarea.net>

Hello,

I'd like to request a category for plugins of the repoze.who framework, which 
can be "Framework :: repoze.who :: Plugins".

I already have a plugin for this framework: 
http://pypi.python.org/pypi/repoze.who.plugins.ldap/

Thanks in advance.
-- 
Gustavo Narea.
http://gustavonarea.net/

Get rid of unethical constraints! Switch to Freedomware:
http://softwareliberty.com/