[Catalog-sig] Tweaks to edit screen

[Ian Bicking]

Since you are in this code for other PyPI changes, can this be fixed too?
The concise request at this point:

Change wrap="HARD" to wrap="SOFT" in edit textareas.

When displaying non-ReST package descriptions, change <PRE> to <PRE
style="white-space: pre-wrap">



On Mon, Sep 14, 2009 at 11:40 AM, Ian Bicking <ianb at colorstudy.com> wrote:

> On Thu, Sep 10, 2009 at 8:00 AM, "Martin v. Löwis" <martin at v.loewis.de>
> wrote:
> >> The edit screen (e.g.,
> >>
> http://pypi.python.org/pypi?:action=submit_form&name=virtualenv&version=1.3.3
> )
> >> uses wrap="HARD" in textareas, which causes corruption of otherwise OK
> >> ReST (uploaded via setup.py register) by introducing unwanted
> >> newlines.  wrap="SOFT" would be better.
> >
> > Would that have any negative consequences, e.g. when the text being
> > entered is not ReST?
>
> At first I would say not.. but then it occurred to me that if the text
> is formatted as <pre> with no wrapping then you could get really long
> lines.
>
> Huh, I notice now that PyPI is treating non-ReST as markup.  That is,
> when I have `link <http://foobar.com>`_, and it's not valid ReST, it
> gets rewritten as `link <HTTP://FOOBAR.COM>`_.  That doesn't seem
> right at all, and it seems like a cross-site-scripting attack could be
> done this way (I haven't attempted one, though; it might be tricky to
> make use of).  It would be better to quote, i.e., `link
> &lt;http://foobar.com&gt;`_
>
> Anyway, I did a test on a local file, and found if you change:
>
> <PRE>text...</PRE>
>
> to:
>
> <PRE style="white-space: pre-wrap">text</PRE>
>
> Then long lines will get wrapped, while maintaining other
> pre/whitespace formatting.  I think that would resolve any issues with
> not wrapping text on input.
>
> >> Also, it's tricky to updated ==dev links, because links from all
> >> versions are displayed on /simple/<package>, and the last link is
> >> used, which is the oldest link.  Just inverting the order of the links
> >> would fix this; or at least inverting the links that are scraped from
> >> the descriptions.
> >
> > I don't understand that request. Can you please provide a reference to
> > a package where things are not as they should be, and indicate how they
> > should be?
> >
> > Notice that, in r598, I was asked specifically to change the order to
> > put file urls before the homepage url. So I'm hesitant to change
> > anything without an independent confirmation that this would be a good
> > change.
>
> This happened to me when I was moving around the virtualenv
> repository.  The old links were like:
>
> http://svn.colorstudy.com/virtualenv/trunk#egg=virtualenv-dev
>
> I wanted to put in a new link:
>
> http://bitbucket.org/ianb/virtualenv/get/tip.gz#egg=virtualenv-dev
>
> Unfortunately when I do that, then both links appear on the simple
> index, and the one that easy_install selects is to svn.
>
> These are the links in the body of the text, not any structured field.
>  I believe these links are generally put last anyway.  If you look at
> the page now, I've used virtualeng-hg for the new tip because of this
> problem:
>
> http://pypi.python.org/simple/virtualenv/
>
> Though damn, I realize I actually got it wrong -- easy_install is
> selecting the last link, not the first one.  Bah.  Maybe the right fix
> in this case is in easy_install and pip.
>
> --
> Ian Bicking  |  http://blog.ianbicking.org  |
> http://topplabs.org/civichacker
>



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