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 <[email protected]> wrote: > On Thu, Sep 10, 2009 at 8:00 AM, "Martin v. Löwis" <[email protected]> > 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 > <http://foobar.com>`_ > > 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
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
