[monit] pypi.python.org - Connection failed

Connection failed Service pypi.python.org 

	Date:        Thu, 30 Jun 2011 19:05:27 -0500
	Action:      alert
	Host:        jacobian.org
	Description: failed protocol test [HTTP] at INET[pypi.python.org:80] via TCP

Your faithful employee,
monit

Re: Tab Title customization and Tal to Django/Jinja transition

On Fri, Jul 1, 2011 at 3:01 AM, Richard Jones <richard <at> python.org> wrote:
> On 30 June 2011 04:57, anatoly techtonik <techtonik <at> gmail.com> wrote:
>> Index: pypi/templates/standard_template.pt
>> ===================================================================
>> -      <title tal:content="string:Python Package Index : ${data/title}" />
>> +      <title tal:content="string:${data/title} : Python Package Index" />
>
> Seems like a good idea. I've double-checked that the easy_install
> "API" doesn't depend on this HTML. Done.

Have you seen the second patch? It should be more cool. I've reattached it.

> Can we stop the rather pointless arguing over templating engines now?

Sure. Pointless arguing is a waste of time. I hoped to get an answer
about superior features of TAL, which didn't seem as popular as
Django/Jinja for me. Now I see that majority of PyPI devs are more
familiar with TAL.

So far my biggest concern is template readability. It will help if my
editor had syntax highlighting for this XML language. All I need for
that is XSD schema. Unfortunately, references contain only EBNF
notation.
--
anatoly t.

Index: pypi/templates/display.pt
===================================================================
--- pypi/templates/display.pt	(revision 925)

Re: Tab Title customization and Tal to Django/Jinja transition

On 1 July 2011 16:30, anatoly techtonik <techtonik <at> gmail.com> wrote:
> On Fri, Jul 1, 2011 at 3:01 AM, Richard Jones <richard <at> python.org> wrote:
>> On 30 June 2011 04:57, anatoly techtonik <techtonik <at> gmail.com> wrote:
>>> Index: pypi/templates/standard_template.pt
>>> ===================================================================
>>> -      <title tal:content="string:Python Package Index : ${data/title}" />
>>> +      <title tal:content="string:${data/title} : Python Package Index" />
>>
>> Seems like a good idea. I've double-checked that the easy_install
>> "API" doesn't depend on this HTML. Done.
>
> Have you seen the second patch? It should be more cool. I've reattached it.

I don't believe it's necessary, thanks. The site is consistent with
the code as above.

    Richard

Re: Tab Title customization and Tal to Django/Jinja transition

On 30 June 2011 04:57, anatoly techtonik <techtonik <at> gmail.com> wrote:
> Index: pypi/templates/standard_template.pt
> ===================================================================
> -      <title tal:content="string:Python Package Index : ${data/title}" />
> +      <title tal:content="string:${data/title} : Python Package Index" />

Seems like a good idea. I've double-checked that the easy_install
"API" doesn't depend on this HTML. Done.

Can we stop the rather pointless arguing over templating engines now?

     Richard

Re: Tab Title customization and Tal to Django/Jinja transition

Le 01/07/2011 02:01, Richard Jones a écrit :
> Seems like a good idea. I've double-checked that the easy_install
> "API" doesn't depend on this HTML. Done.

Thanks Richard!

still-finding-that-the-colon-is-strange’ly yours,
Éric
_______________________________________________
Catalog-SIG mailing list
Catalog-SIG <at> python.org
http://mail.python.org/mailman/listinfo/catalog-sig

disallowing the removal of packages?

Hi there,

My development project relied on a certain version of a package that is 
hosted on pypi. Unfortunately the package mainatainer had decided that 
certain older versions of the package were not longer supported and had 
removed them from PyPI altogether.

This broke the build procedure for my project: I had carefully pinned 
down that I wanted this version (as that's what we tested with), and it 
wasn't available anymore.

So, the removal of old packages from PyPI means that other people who 
rely on these packages with their installation instructions ("install 
Foo 3.3") or build tools (installation instructions, automated), 
suddenly have to deal with breakage.

I thought perhaps PyPI can help and handle this problem at the source.

What are the possible use cases for removing a release from PyPI?

a) mistakes: the upload was accidental - we weren't supposed to release 
this at all! I.e. I uploaded private code that I never meant to 
distribute in the first place.

b) actively hostile: the upload actually contains deliberately malicious 
code and protecting people against this *should* break their builds

c) legal issues: some party claims that this code is not PyPI's to 
distribute in the first place, and for legal issues it'd need to be 
taken down.

Re: disallowing the removal of packages?

On Mon, Jul 4, 2011 at 11:41 AM, Martijn Faassen <faassen <at> startifact.com> wrote:
> Hi there,
>
> My development project relied on a certain version of a package that is
> hosted on pypi. Unfortunately the package mainatainer had decided that
> certain older versions of the package were not longer supported and had
> removed them from PyPI altogether.
>
> This broke the build procedure for my project: I had carefully pinned down
> that I wanted this version (as that's what we tested with), and it wasn't
> available anymore.
>
> So, the removal of old packages from PyPI means that other people who rely
> on these packages with their installation instructions ("install Foo 3.3")
> or build tools (installation instructions, automated), suddenly have to deal
> with breakage.
>
> I thought perhaps PyPI can help and handle this problem at the source.
>
> What are the possible use cases for removing a release from PyPI?
>
> a) mistakes: the upload was accidental - we weren't supposed to release this
> at all! I.e. I uploaded private code that I never meant to distribute in the
> first place.
>
> b) actively hostile: the upload actually contains deliberately malicious
> code and protecting people against this *should* break their builds
>
> c) legal issues: some party claims that this code is not PyPI's to
> distribute in the first place, and for legal issues it'd need to be taken

Re: disallowing the removal of packages?

At 05:41 PM 7/4/2011 +0200, Martijn Faassen wrote:
>I'd argue d) and e) are not up to the package maintainer to decide 
>but to the person who integrates this package into their system.

Sure...  but that doesn't mean the package maintainer is obligated to 
support the integrator in that decision.

>The person who integrates the package is the one who will need to 
>make the judgment call to continue to use old unsupported or broken 
>stuff. Integrators should be allowed to make such decisions in their 
>own time at their own convenience; the package developer shouldn't 
>be able to force such decisions by removing an old release.

Then the package integrator should darn well keep their own copy 
instead of relying on it still being downloadable from a public 
server.  Not keeping a file uploaded is not equal to forcing anybody 
else to do anything.

Note that there is nothing in your proposal that keeps a package 
maintainer from simply never uploading packages to PyPI in the first 
place...  and is likely to have the perverse effect of encouraging 
package authors who are concerned about this issue to make other 
hosting arrangements.

(Certainly, if it looks like your proposal will be adopted, I would 
be strongly motivated to *immediately* remove any package from PyPI 
that I thought I might need to remove later, but would be unable to 
if the proposal were implemented!)

In short, this proposal is asking PyPI to do a job that is properly 

Re: disallowing the removal of packages?

Am 04.07.2011 20:59, schrieb P.J. Eby:
> At 05:41 PM 7/4/2011 +0200, Martijn Faassen wrote:
>>I'd argue d) and e) are not up to the package maintainer to decide 
>>but to the person who integrates this package into their system.
> 
> Sure...  but that doesn't mean the package maintainer is obligated to 
> support the integrator in that decision.
> 
> 
>>The person who integrates the package is the one who will need to 
>>make the judgment call to continue to use old unsupported or broken 
>>stuff. Integrators should be allowed to make such decisions in their 
>>own time at their own convenience; the package developer shouldn't 
>>be able to force such decisions by removing an old release.
> 
> Then the package integrator should darn well keep their own copy 
> instead of relying on it still being downloadable from a public 
> server.  Not keeping a file uploaded is not equal to forcing anybody 
> else to do anything.
> 
> Note that there is nothing in your proposal that keeps a package 
> maintainer from simply never uploading packages to PyPI in the first 
> place...  and is likely to have the perverse effect of encouraging 
> package authors who are concerned about this issue to make other 
> hosting arrangements.
> 
> (Certainly, if it looks like your proposal will be adopted, I would 
> be strongly motivated to *immediately* remove any package from PyPI 
> that I thought I might need to remove later, but would be unable to 
> if the proposal were implemented!)

Re: disallowing the removal of packages?

On Mon, Jul 4, 2011 at 2:25 PM, Georg Brandl <g.brandl <at> gmx.net> wrote:
> I have to agree.  Any hosting service that doesn't allow me to remove
> uploaded content looks extremely fishy to me.

It pains me, but I have to agree as well.

If I had a nickel for each time I've been bitten by a package
disappearing off PyPI... well, I'd be able to buy a few beers, at
least. I believe, as I've argued in the past, that PyPI's raison
d'être is to be a cataloging resource *for package authors* — if we
want to prevent fragmentation, then we have to make PyPI the "path of
least resistance" for packagers. This means PyPI can't be in the
business of making these sorts of decisions on authors' behalf.

Not that we shouldn't get upset when a package vanishes. I'd be all
for some public chastisement in those cases... (80% joking).

Jacob