Andreas Jung | 1 Aug 17:05 2009

Re: package with the longest version string

On 31.07.09 03:23, Sridhar Ratnakumar wrote:
> .. must be this:
>
>  
> http://pypi.python.org/pypi/softwarefabrica.django.crud/1.0dev-BZR-r79-panta-elasticworld.org-20090316230356-bp41wibodhmypvep

PyPI, the package toilet :->

Andreas
Attachment (lists.vcf): text/x-vcard, 316 bytes
_______________________________________________
Catalog-SIG mailing list
Catalog-SIG <at> python.org
http://mail.python.org/mailman/listinfo/catalog-sig
Chris Withers | 19 Aug 13:54 2009
Picon

Problems uploading a .msi

Sverker Nilsson wrote:
> Yes, I could see you attachaed a Windows installer.
> But I could not upload it. PyPi complained:
> 
> Error processing form
> 
> invalid distribution file

This was a .msi and I experienced the same thing.
Is this a known problem?

Chris

--

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk
"Martin v. Löwis" | 19 Aug 21:39 2009
Picon

Re: Problems uploading a .msi

> This was a .msi and I experienced the same thing.
> Is this a known problem?

PyPI didn't support MSI files, but it does now.

Please try again.

Regards,
Martin
"Martin v. Löwis" | 21 Aug 16:33 2009
Picon

HTML in long description

Should PyPI support HTML in the long_description field?

The current implementation tries to pass the long_description
to docutils, with the settings raw_enabled=0, file_insertion_enabled=0,
halt_level=2, report_level=5. If parsing fails, it will wrap
the long_description with a <PRE> element.

As a side effect of that, HTML in long_description seems to work,
but it isn't really supported.

Which way should PyPI go: escape all markup if ReST rendering fails?
Or else allow arbitrary HTML to be embedded? I'm worried that somebody
would create a cross-site attack out of that...

Regards,
Martin
Fred Drake | 21 Aug 16:35 2009
Picon

Re: HTML in long description

On Fri, Aug 21, 2009 at 10:33 AM, "Martin v. Löwis"<martin <at> v.loewis.de> wrote:
> Which way should PyPI go: escape all markup if ReST rendering fails?
> Or else allow arbitrary HTML to be embedded? I'm worried that somebody
> would create a cross-site attack out of that...

Same here; the text in the <pre> should be properly escaped.

  -Fred

--

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller
Tarek Ziadé | 21 Aug 16:51 2009
Picon

Re: HTML in long description

On Fri, Aug 21, 2009 at 4:35 PM, Fred Drake<fdrake <at> gmail.com> wrote:
> On Fri, Aug 21, 2009 at 10:33 AM, "Martin v. Löwis"<martin <at> v.loewis.de> wrote:
>> Which way should PyPI go: escape all markup if ReST rendering fails?
>> Or else allow arbitrary HTML to be embedded? I'm worried that somebody
>> would create a cross-site attack out of that...
>
> Same here; the text in the <pre> should be properly escaped.

FWIW lxml.html is pretty convenient to remove any dangerous tag, it's
a one-liner
that will get rid of any <form> <script> <embed> etc..

But in any case, I find the current situation fuzzy :

The reStructuredText format is an implicit rule from pypi and trying an
rst2html process on server side, no matter what long_description contains,
seem like a bad practice to me.

I'd like to see the nature of long_description explicitely declared in
the metadata

For example we could have a "long_description_format" field that would
be 'text',
'html' or 'restructuredtext'

If present, PyPI could use this info to decide what it should do with
long_description
(although this does not remove the need to clean it up on server side
for security reasons
of course)
(Continue reading)

"Martin v. Löwis" | 21 Aug 17:05 2009
Picon

Re: HTML in long description

> FWIW lxml.html is pretty convenient to remove any dangerous tag, it's
> a one-liner
> that will get rid of any <form> <script> <embed> etc..

Hmm. Is there a library whose *explicit* purpose is to create "safe"
HTML. I would be hesitating to implement it myself.

> The reStructuredText format is an implicit rule from pypi and trying an
> rst2html process on server side, no matter what long_description contains,
> seem like a bad practice to me.

I think it's not too bad. Since the long_description is either plain
text or ReST, the cost of misinterpretation is really low - ReST may
get mis-rendered as preformatted plain text, in which case it will
remain readable still.

> I'd like to see the nature of long_description explicitely declared in
> the metadata
> 
> For example we could have a "long_description_format" field that would
> be 'text', 'html' or 'restructuredtext'

Sounds fairly complex to me. I think I could accept it - but if html
is removed from the list of allowed formats (which I think it should),
then I don't think this this overhead is really needed.

> Last, notice that there's a new command in distutils called "check" ,
> that can be used
> to check if the long_description field content compiles well in reStructuredText
> This client-side process is convenient to avoid any error or warning
(Continue reading)

Tarek Ziadé | 21 Aug 17:15 2009
Picon

Re: HTML in long description

2009/8/21 "Martin v. Löwis" <martin <at> v.loewis.de>:
>> FWIW lxml.html is pretty convenient to remove any dangerous tag, it's
>> a one-liner
>> that will get rid of any <form> <script> <embed> etc..
>
> Hmm. Is there a library whose *explicit* purpose is to create "safe"
> HTML. I would be hesitating to implement it myself.

Well, that's *one* of the explicit goal of lxml.html, see
http://codespeak.net/lxml/lxmlhtml.html#cleaning-up-html

I used to do it myself using SGMLParser (based on the well known
active state recipe), then I discovered this one,
which do the work fine.

>> The reStructuredText format is an implicit rule from pypi and trying an
>> rst2html process on server side, no matter what long_description contains,
>> seem like a bad practice to me.
>
> I think it's not too bad. Since the long_description is either plain
> text or ReST, the cost of misinterpretation is really low - ReST may
> get mis-rendered as preformatted plain text, in which case it will
> remain readable still.
>

Sure we can live with it,

> [..]
>
> That could be done, either way, IMO. It might also be useful to have a
(Continue reading)

Chris Withers | 24 Aug 18:00 2009
Picon

Re: Problems uploading a .msi

Martin v. Löwis wrote:
>> This was a .msi and I experienced the same thing.
>> Is this a known problem?
> 
> PyPI didn't support MSI files, but it does now.
> 
> Please try again.

Cool, it works :-)

Chris

--

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk
Mark Ramm-christensen | 26 Aug 02:10 2009

SourceForge mirroring

I've been working at SourceForge for the last few months, and we've
got an interest in helping out the python community as much as we can.
   And now that big sections of SourceForge run on python, using
packages from pypi, we've got a vested interest in making sure that
there is a high availability global mirror network for pypi packages.
 Fortunately we've got a network of people who have volunteered to
host open source projects for sourceforge.net.  And at EuroPython
somebody mentioned to me that we could work together to improve pypi
package delivery, which seems obvious in retrospect.

So, here's my proposal, we could mirror any open source packages on
pypi onto the sourceforge.net mirror network.   We can get most of the
data we need from the DOAP feed, and we could get the rest from
crawling the site, though it would be great if we could add an api for
getting the files for a project and perhaps a bit more project
metadata from pypi directly.

We can then provide a consistent link structure with a redirector to
the "best" mirror based on geo-ip data and mirror utilization, so that
you can programatically know how to get packages from our mirror
network.

My goal here is to help increase the robustness and reliability of the
pypi end of our package delivery system, and to help give back to the
python community.

Anyway, I just wanted to raise the idea here and see if there is any
interest in this idea.

--Mark Ramm
(Continue reading)


Gmane