On Tue, Oct 16, 2012 at 6:13 AM, Julien Rioux <[email protected]> wrote: > Hi, > > > On Tuesday, 16 October 2012 01:09:00 UTC+2, Aaron Meurer wrote: >> >> It won't fix it. I've already tried this. The problem is that it searches >> the home page link on all versions on PyPI, not just the recent one. So I'd >> have to go through and remove all links from all versions uploaded on PyPI. >> Frankly, it might not be such a bad idea to do that, since it would forever >> fix our pip issues, but of course the downside is that it would be nice to >> have the various links on PyPI. Also, editing the old versions seems like >> something that shouldn't be done for historical purposes (and also I am too >> lazy to do it so far). >> > > > You're right, it actually uses http://pypi.python.org as index by default, > so it starts out at http://pypi.python.org/simple/sympy/ which lists the old > home pages. > > If you use the default index, it ends up on the google home page eventually. > I just removed the "Featured" label from sympy-0.7.2.rc1.python3.tar.gz, and > pip stopped picking up that version.
Except if you remove the featured label, it no longer shows up on the Google Code homepage, meaning fewer people will find it. > > If you specify a different index when running pip, you can also stop it from > picking up "Featured" downloads, e.g. pip install -i > "http://pypi.python.org/pypi/";. Of course. But we should aim to make things work for the 95% of users who will just do "pip install sympy" without any extra arguments. > > So there are multiple solutions to have pip not install our release > candidates, I trust that you now make your decision on which solution you > prefer. I'll figure it out with the next release. Probably just naming the tarballs differently will be the cleanest solution. By the way, we ought to move our tarball hosting from Google Code to GitHub (but that's another thing I want to worry about later, unless someone volunteers). > >>> >>> >>> Another think is, that we should use PEP 386 convention for naming our >>> tarballs, so "0.7.2rc1". This doesn't affect pip at the moment though, since >>> it doesn't seem to care about PEP 386 for now. >> >> >> I'm a little confused by that PEP by what exactly we should be using in >> the future. If you're referring to StrictVersion, it doesn't seem to >> support rc at all: >> >> > > > No, not StrictVersion, but NormalizedVersion. Please read PEP 386 again, I > doubt that I can write it out in more explicit details than what is in > there. Anyway, it's not a big issue, but could be considered next time. I see it now. That pep is very confusing. So should the correct way really be 0.7.2c1 (without the r)? Anyway, if we ever get our release process automated the way that I would like, we can probably do away with release candidates entirely. Aaron Meurer > > Regards, > Julien > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/sympy/-/KN13JlzvGRYJ. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
