SymPy 0.7.2.rc1

[Aaron Meurer]

I'm happy to announce that we finally have a release candidate for
SymPy 0.7.2. Go to http://code.google.com/p/sympy/downloads/list to
see them.

Please test this, and make sure that everything works. SymPy 0.7.2
adds support for Python 3, and we also have support for PyPy, assuming
you are running a recent nightly. So please test this, make sure the
tarball includes everything it should (and nothing it shouldn't), that
it installs, etc. If someone could test the windows installer in
particular, that would be great.

Also, I couldn't make a Windows installer for Python 3, because I got
this error:

Warning: Can't read registry to find the necessary compiler setting
Make sure that Python modules winreg, win32api or win32con are installed.
Traceback (most recent call last):
File "./setup.py", line 286, in <module>
classifiers = classifiers,
File "/sw/lib/python3.3/distutils/core.py", line 148, in setup
dist.run_commands()
File "/sw/lib/python3.3/distutils/dist.py", line 917, in run_commands
self.run_command(cmd)
File "/sw/lib/python3.3/distutils/dist.py", line 936, in run_command
cmd_obj.run()
File "/sw/lib/python3.3/distutils/command/bdist_wininst.py", line 179, in run
self.create_exe(arcname, fullname, self.bitmap)
File "/sw/lib/python3.3/distutils/command/bdist_wininst.py", line
262, in create_exe
cfgdata = cfgdata.encode("mbcs")
LookupError: unknown encoding: mbcs

meaning it has to be run in Windows to work. So I may need someone to
help me out with that (unless I can get Python working on my Windows
machine).

I will let the release candidate sit for at least a week, and if there
are no major problems, I will do the full release. I will announce
the release notes at that time.

In the meanwhile, we do need help writing the release notes still, so
if you made any major contributions to SymPy in the past year, please
make sure it is mentioned at
https://github.com/sympy/sympy/wiki/Release-Notes-for-0.7.2.

Aaron Meurer

[Aaron Meurer]

Oh, and I forgot one thing. We are also shipping a pdf version of the
docs now, in addition to the html docs. See
http://code.google.com/p/sympy/downloads/detail?name=sympy-0.7.2.rc1.pdf.

Aaron Meurer

[Chris Smith]

On Tue, Oct 9, 2012 at 12:11 PM, Aaron Meurer <asme...@gmail.com> wrote:
> Oh, and I forgot one thing. We are also shipping a pdf version of the
> docs now, in addition to the html docs. See
> http://code.google.com/p/sympy/downloads/detail?name=sympy-0.7.2.rc1.pdf.

Are things like links pretty much guaranteed to be right because of
how Sphinx works?

[Ondřej Čertík]

They should be, but if you find any that don't work, report it.
Btw, I use Evince in Ubuntu 12.04, and neither link actually does anything
in the pdf, but I assume this is bug in Evince.

Aaron, I tested both the 2.x in 2.7 and 3.x in 3.2 Pythons in Ubuntu
12.04 64 bit, everything
works.

Ondrej

[Sachin Joglekar]

I run Python 2.7 on Windows 7. I would like to be a part of the process for testing of rc1. Any ways I could help?

[Aaron Meurer]

Just installing and telling me if you can run it would help a lot. I otherwise have to just trust that the .exe installer was made correctly. 

If you have the time, once you install, run

import sympy

sympy.test()

sympy.doctest()

And let us know if there are any failures.  And by the way, at the top of the test run, can you tell us if it says 32-bit or 64-bit?

Aaron Meurer

Sent from my iPad

--
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/-/5I-ZjhO8EGYJ.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.

[Aaron Meurer]

Well, I already know about a ton of formatting issues, which are not
super important, but are there. The main issue is that any \tt
(monospace) text does not wrap, so a lot of lines are too long. Unless
there are serious issues, though, like entire parts that are missing,
it's not something that needs to be fixed for 0.7.2 final.

Aaron Meurer

>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.

[Aaron Meurer]

On Oct 9, 2012, at 8:26 AM, "Ondřej Čertík" <ondrej...@gmail.com> wrote:

> On Tue, Oct 9, 2012 at 2:04 AM, Chris Smith <smi...@gmail.com> wrote:
>> On Tue, Oct 9, 2012 at 12:11 PM, Aaron Meurer <asme...@gmail.com> wrote:
>>> Oh, and I forgot one thing. We are also shipping a pdf version of the
>>> docs now, in addition to the html docs. See
>>> http://code.google.com/p/sympy/downloads/detail?name=sympy-0.7.2.rc1.pdf.
>>
>> Are things like links pretty much guaranteed to be right because of
>> how Sphinx works?
>
> They should be, but if you find any that don't work, report it.
> Btw, I use Evince in Ubuntu 12.04, and neither link actually does anything
> in the pdf, but I assume this is bug in Evince.

Wait, what happens? Is evince a web browser or a PDF viewer? Note
that the above link is not a direct link, but rather a link to the
download page.

Aaron Meurer

>
> Aaron, I tested both the 2.x in 2.7 and 3.x in 3.2 Pythons in Ubuntu
> 12.04 64 bit, everything
> works.
>
> Ondrej
>

[Ondřej Čertík]

On Tue, Oct 9, 2012 at 11:06 AM, Aaron Meurer <asme...@gmail.com> wrote:
> On Oct 9, 2012, at 8:26 AM, "Ondřej Čertík" <ondrej...@gmail.com> wrote:
>
>> On Tue, Oct 9, 2012 at 2:04 AM, Chris Smith <smi...@gmail.com> wrote:
>>> On Tue, Oct 9, 2012 at 12:11 PM, Aaron Meurer <asme...@gmail.com> wrote:
>>>> Oh, and I forgot one thing. We are also shipping a pdf version of the
>>>> docs now, in addition to the html docs. See
>>>> http://code.google.com/p/sympy/downloads/detail?name=sympy-0.7.2.rc1.pdf.
>>>
>>> Are things like links pretty much guaranteed to be right because of
>>> how Sphinx works?
>>
>> They should be, but if you find any that don't work, report it.
>> Btw, I use Evince in Ubuntu 12.04, and neither link actually does anything
>> in the pdf, but I assume this is bug in Evince.
>
> Wait, what happens? Is evince a web browser or a PDF viewer? Note
> that the above link is not a direct link, but rather a link to the
> download page.

Evince is the default pdf viewer in Ubuntu. The hyperlinks in the pdf
don't seem to work for me.
However, the pdf looks good otherwise.

Ondrej

[Ronan Lamy]

Must be something in your config. It works for me (evince/Ubuntu 12.04):
clicking the hyperlinks opens the pages in Firefox.

> However, the pdf looks good otherwise.

Yes, it does. But 1520 pages??!


> Ondrej
>

[Ondřej Čertík]

Thanks. So all is good.

Ondrej

[Aaron Meurer]

Well, that just tells you how much documentation we have. That's all
of it (minus the stuff that's not even included in Sphinx). If you
know of some way to make Sphinx split it up, that would be cool. But
probably it's not something that you want to print.

That reminds me, we also have the cheat sheet from GCI. I should see
if that's still relevant and perhaps ship it as well.

Aaron Meurer

[Aaron Meurer]

It looks OK. The plotting stuff should probably be updated for the
new module, but that's it.

I'll upload it when I do the final release. If someone wants to send
in updates for it until then, I'll accept them.

Aaron Meurer

[Ondřej Čertík]

On Mon, Oct 8, 2012 at 11:20 PM, Aaron Meurer <asme...@gmail.com> wrote:
> I'm happy to announce that we finally have a release candidate for
> SymPy 0.7.2. Go to http://code.google.com/p/sympy/downloads/list to
> see them.
>
> Please test this, and make sure that everything works. SymPy 0.7.2
> adds support for Python 3, and we also have support for PyPy, assuming
> you are running a recent nightly. So please test this, make sure the
> tarball includes everything it should (and nothing it shouldn't), that
> it installs, etc. If someone could test the windows installer in
> particular, that would be great.

So there is some problem with pip:

ondrej@hawk:/tmp$ virtualenv-2.7 xx
New python executable in xx/bin/python
cInstalling setuptools............done.
Installing pip...............done.
ondrej@hawk:/tmp$ source xx/bin/activate
(xx)ondrej@hawk:/tmp$ pip install sympy
Downloading/unpacking sympy
Downloading sympy-0.7.2.rc1.python3.tar.gz (5.3Mb): 5.3Mb downloaded
Running setup.py egg_info for package sympy

Traceback (most recent call last):

File "<string>", line 14, in <module>
File "/tmp/xx/build/sympy/setup.py", line 36, in <module>
import sympy
File "sympy/__init__.py", line 27, in <module>
raise ImportError("It appears 2to3 has been run on the codebase. Use "
ImportError: It appears 2to3 has been run on the codebase. Use
Python 3 or get the original source code.
Complete output from command python setup.py egg_info:

Traceback (most recent call last):

File "<string>", line 14, in <module>

File "/tmp/xx/build/sympy/setup.py", line 36, in <module>

import sympy

File "sympy/__init__.py", line 27, in <module>

raise ImportError("It appears 2to3 has been run on the codebase. Use "

ImportError: It appears 2to3 has been run on the codebase. Use Python
3 or get the original source code.

----------------------------------------
Command python setup.py egg_info failed with error code 1 in /tmp/xx/build/sympy
Storing complete log in /home/ondrej/.pip/pip.log





This actually is series *right* now, because it causes "pip install
sympy" to fail. I found it the hard way:

https://travis-ci.org/#!/certik/hfsolver/jobs/2730535

I quiet the logs, but I suspected sympy right a way.

Aaron, is there any way to make only the latest release version as the
default version?

Why is it picking the python3 tarball for Python 2.7?

Ondrej

[Ondřej Čertík]

series -> serious.

Ondrej

[Aaron Meurer]

I guess I didn't follow the right naming scheme for the tarball.

You see, pip (easy_install too) uses an algorithm that very
aggressively searches websites for the most recent version of a
package. It's impossible for me, as a package maintainer to change
this algorithm, and the only way for me to prevent it from searching
Google Code is to go through all old versions of SymPy on PyPI and
remove all references to Google Code. See
http://mail.python.org/pipermail/catalog-sig/2012-June/004518.html for
more information. So what's happening is that pip thinks that the
Python 3 0.7.2.rc1 tarball is the latest version of SymPy (for Python
2).

So on the one hand, I think we should push for this feature that I
requested again, because it's the only way that package maintainers
like myself will be truly able to prevent this kind of issue. Namely,
there should be a flag in PyPI that package maintainers can check that
would tell pip/easy_install to only install packages from PyPI, and
nowhere else.

On the other hand, for the here and now, we should figure out how to
name the tarballs so that pip-2 installs the Python 2 tarball and
pip-3 installs the Python 3 tarball. We probably should also rename
the release candidate tarballs to "trick" pip into not installing them
in general.

And by the way, SymPy wouldn't be the first package that isn't pip
installable. Neither Pyglet nor gmpy can be installed by pip, for
exactly the same reason. And I've only really ever tried installing
perhaps a couple dozen packages with pip. My guess is that there are
tens if not hundreds of packages with this very same issue.

Aaron Meurer

[Sachin Joglekar]

There were some errors . The architecture said '32-bit'.I have attached a file of the relevant output. Please check and let me know if theres anything I can help with.

[Sachin Joglekar]

[Aaron Meurer]

It looks like you didn't correctly attach the file.

Aaron Meurer

> --
> 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/-/Sm1PAMBkPj4J.

[Aaron Meurer]

Oh, never mind. It wasn't loading for some reason, but I see it now.

Aaron Meurer

[Aaron Meurer]

This is a very strange failure. Where is this "boolalg - copy.py"
file coming from?

Aaron Meurer

[Sachin Joglekar]

I'll reinstall sympy and check again. The boolalg-copy file is my mistake I guess. And the 'elliptic' file error?

[mario]

On Wednesday, October 10, 2012 9:22:10 AM UTC+2, Sachin Joglekar wrote:

I'll reinstall sympy and check again. The boolalg-copy file is my mistake I guess. And the 'elliptic' file error?

 I  also get errors there running the test `N=20000` times instead of `N=5` times;  giving a bit more
precision it passes it

```
        # Abramowitz Table 16.5
        # cn(K, q) = 0; K is K(k), first complete elliptic integral
        equality = jcn(K, m)
        mp.prec -= 3
        assert(equality.ae(0))
        mp.prec += 3
```

[Aaron Meurer]

That's a known failure in certain random seeds. The fix should be made upstream. 

Aaron Meurer

--
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/-/Y85E6EqtF0UJ.

[Ondřej Čertík]

So this looks like that pip is seriously broken... Don't worry about this then.
Let's release and then worry about this.

I am going to fix this by forcing pip to simply install a particular
version of sympy that works,
and I should have done that in the first place anyway.

Ondrej

[Ondřej Čertík]

I reported the bug upstream:

https://github.com/pypa/pip/issues/701

Ondrej

[Aaron Meurer]

The whole ecosystem is broken, and it's not going to be fixed because
they are afraid of any kind of change that might break "backwards
compatibility", even if that means being compatibile with a terrible
decision made a long time ago. What pip really should do is install
only from PyPI (or from a direct link given in PyPI). It would then be
the package maintainer's responsibility to make sure that their
package is pip installable and up-to-date on PyPI. But this won't
happen, because the Python packaging community is either unwilling or
unable to deal with the backlash of such a change.

Another reference:
https://groups.google.com/d/topic/python-virtualenv/PZNj9pC6aKA/discussion.

Aaron Meurer

>
> Ondrej

>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.

[Aaron Meurer]

Oh, and while I'm still in a ranting mood, the other fundamental
problem is that the pip community and the PyPI community are not the
same. So if you suggest a useful change (like the one I suggested),
the answer in pip is "PyPI should change" and the answer in PyPI is
"pip should change". It's not an issue of people being lazy or
whatever, just really, for packaging to really work well, the
packaging software and the packaging site should both have the same
community.

Or at least that's my perspective.

[Ondřej Čertík]

I just read the thread that you mentioned on the pip mailinglist. Now,
that's amazingly broken... However, at least if they installed from pypi
instead of google code (if pypi is available),
that would be a step in the right direction. Here:

http://pypi.python.org/pypi/sympy

it shows 0.7.1 as it should.

Ondrej

[Ondřej Čertík]

Ok, I posted about this into my G+:

https://plus.google.com/u/0/104039945248245758823/posts/imi8RwNYNUC

I think this needs more attention than just a simple bug report.

Ondrej

[Matthew Brett]

Hi,

Wasn't this predictable though? Hence my previous suggestion to try
and use 2to3 in setup.py rather than release separate source tarballs.
Sorry, I'd really be happy to do this, I believe it would not be very
difficult, but I'm in the middle of various family things and have no
time. Example in nibabel:

https://github.com/nipy/nibabel/blob/master/setup.py#L30
https://github.com/nipy/nibabel/blob/master/nisext/py3builder.py#L16

where any logic about code on which 2to3 should not be run can go around:

https://github.com/nipy/nibabel/blob/master/nisext/py3builder.py#L40

by filtering 'files'. I think.

Cheers,

Matthew

[Ondřej Čertík]

Not for me. :)

> and use 2to3 in setup.py rather than release separate source tarballs.
> Sorry, I'd really be happy to do this, I believe it would not be very
> difficult, but I'm in the middle of various family things and have no
> time. Example in nibabel:
>
> https://github.com/nipy/nibabel/blob/master/setup.py#L30
> https://github.com/nipy/nibabel/blob/master/nisext/py3builder.py#L16
>
> where any logic about code on which 2to3 should not be run can go around:
>
> https://github.com/nipy/nibabel/blob/master/nisext/py3builder.py#L40
>
> by filtering 'files'. I think.

Ok, I think we should definitely make this automatic, somehow, so that
the git source can be just "setup.py installed" in both 2.x and 3.x.
I thought it's not possible.

However, the translation takes a long time, so that's why I think
it's better to have two tarballs.

Ondrej

[Aaron Meurer]

I was afraid it might happen, but I thought that there should at least
be a way to name the packages so that pip installs the right one in
Python 2 or Python 3. In fact, I still do not know for sure that this
is indeed not possible, so I would like to investigate this option
further before giving up on it.

I did know that pip would be installing the release candidates, but
there's nothing I can do about that, except rename the tarballs to
trick it.

>
>> and use 2to3 in setup.py rather than release separate source tarballs.
>> Sorry, I'd really be happy to do this, I believe it would not be very
>> difficult, but I'm in the middle of various family things and have no
>> time. Example in nibabel:
>>
>> https://github.com/nipy/nibabel/blob/master/setup.py#L30
>> https://github.com/nipy/nibabel/blob/master/nisext/py3builder.py#L16
>>
>> where any logic about code on which 2to3 should not be run can go around:
>>
>> https://github.com/nipy/nibabel/blob/master/nisext/py3builder.py#L40
>>
>> by filtering 'files'. I think.
>
> Ok, I think we should definitely make this automatic, somehow, so that
> the git source can be just "setup.py installed" in both 2.x and 3.x.
> I thought it's not possible.
>
> However, the translation takes a long time, so that's why I think
> it's better to have two tarballs.
>
> Ondrej
>

[Ondřej Čertík]

I released two beta version of new numpy:

http://sourceforge.net/projects/numpy/files/NumPy/1.7.0b2/
http://sourceforge.net/projects/numpy/files/NumPy/1.7.0b1/

But pip is still installing the latest release:

(xx)ondrej@hawk:/tmp$ pip install numpy
Downloading/unpacking numpy
Downloading numpy-1.6.2.zip (2.9Mb): 745Kb downloaded

So maybe there is some way to force pip do the right thing?

Ondrej

[Aaron Meurer]

I guess pip doesn't search that site. If you do "pip install numpy
--log log" (e.g., in a virtualenv), the log will show you exactly
where it looks for tarballs. In short, it crawls all websites
referenced in PyPI, including in old versions.

Aaron Meurer

>
> (xx)ondrej@hawk:/tmp$ pip install numpy
> Downloading/unpacking numpy
> Downloading numpy-1.6.2.zip (2.9Mb): 745Kb downloaded
>
> So maybe there is some way to force pip do the right thing?
>
> Ondrej
>

[Ondřej Čertík]

For SymPy, it searches all bunch of things, until it finds
the wrong binary. Unfortunately I don't now what to do with this.

Ondrej

[Julien Rioux]

Hi,

On Wednesday, 10 October 2012 22:03:27 UTC-4, Aaron Meurer wrote:

I was afraid it might happen, but I thought that there should at least
be a way to name the packages so that pip installs the right one in
Python 2 or Python 3.  In fact, I still do not know for sure that this
is indeed not possible, so I would like to investigate this option
further before giving up on it.

The naming of the tarball needs to include the python version in the format "-py2.7". Unfortunately, specifying only major version as in "-py2" and "-py3" won't work, as pip will reject the tarball as providing a python version that doesn't match with the requested one. So we need tarball (or symlinks) for each supported version.
 

I did know that pip would be installing the release candidates, but
there's nothing I can do about that, except rename the tarballs to
trick it.

pip starts out at http://pypi.python.org/pypi/sympy and it finds the "Home Page" link and the "Download URL" link. It then crawls those pages for links that include the text "homepage" and "download". From http://sympy.org (currently listed as the home page on pypi) it finds the download link and eventually the google page.

Form all the pages that it has crawled, pip identifies source tarballs, compare their versions, and choose the latest. Currently, this is

sympy0.7.2.rc1.python3.tar.gz

since it considers the version as "0.7.2.rc1.python3" and this is lexically greater than "0.7.2.rc1". I suggest removing the "Home Page" link from http://pypi.python.org/pypi/sympy and see if that does not fix it.

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.

Regards,
Julien

[Aaron Meurer]

On Mon, Oct 15, 2012 at 1:35 PM, Julien Rioux <julien...@gmail.com> wrote:

Hi,

On Wednesday, 10 October 2012 22:03:27 UTC-4, Aaron Meurer wrote:

I was afraid it might happen, but I thought that there should at least
be a way to name the packages so that pip installs the right one in
Python 2 or Python 3.  In fact, I still do not know for sure that this
is indeed not possible, so I would like to investigate this option
further before giving up on it.

The naming of the tarball needs to include the python version in the format "-py2.7". Unfortunately, specifying only major version as in "-py2" and "-py3" won't work, as pip will reject the tarball as providing a python version that doesn't match with the requested one. So we need tarball (or symlinks) for each supported version.

Well, at least it will work.  I'll see if we can upload just the two files on Google Code and the specific files on PyPI, with the Google Code files named in such a way that pip installs the PyPI files first.

 

 

I did know that pip would be installing the release candidates, but
there's nothing I can do about that, except rename the tarballs to
trick it.

pip starts out at http://pypi.python.org/pypi/sympy and it finds the "Home Page" link and the "Download URL" link. It then crawls those pages for links that include the text "homepage" and "download". From http://sympy.org (currently listed as the home page on pypi) it finds the download link and eventually the google page.

Form all the pages that it has crawled, pip identifies source tarballs, compare their versions, and choose the latest. Currently, this is

sympy0.7.2.rc1.python3.tar.gz

since it considers the version as "0.7.2.rc1.python3" and this is lexically greater than "0.7.2.rc1". I suggest removing the "Home Page" link from http://pypi.python.org/pypi/sympy and see if that does not fix it.

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). 

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:

In [1]: from distutils.version import StrictVersion as V

In [2]: V("0.7.2.rc1")

---------------------------------------------------------------------------

ValueError                                Traceback (most recent call last)

<ipython-input-2-8d10e2780004> in <module>()

----> 1 V("0.7.2.rc1")

/sw/lib/python2.7/distutils/version.pyc in __init__(self, vstring)

     38     def __init__ (self, vstring=None):

     39         if vstring:

---> 40             self.parse(vstring)

     41 

     42     def __repr__ (self):

/sw/lib/python2.7/distutils/version.pyc in parse(self, vstring)

    105         match = self.version_re.match(vstring)

    106         if not match:

--> 107             raise ValueError, "invalid version number '%s'" % vstring

    108 

    109         (major, minor, patch, prerelease, prerelease_num) = \

ValueError: invalid version number '0.7.2.rc1'

In [3]: V("0.7.2rc1")

---------------------------------------------------------------------------

ValueError                                Traceback (most recent call last)

<ipython-input-3-187fc828a9f1> in <module>()

----> 1 V("0.7.2rc1")

/sw/lib/python2.7/distutils/version.pyc in __init__(self, vstring)

     38     def __init__ (self, vstring=None):

     39         if vstring:

---> 40             self.parse(vstring)

     41 

     42     def __repr__ (self):

/sw/lib/python2.7/distutils/version.pyc in parse(self, vstring)

    105         match = self.version_re.match(vstring)

    106         if not match:

--> 107             raise ValueError, "invalid version number '%s'" % vstring

    108 

    109         (major, minor, patch, prerelease, prerelease_num) = \

ValueError: invalid version number '0.7.2rc1' 

And from what I can tell, verlib doesn't either.  

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/-/FfjVDxZIkSEJ.

[Julien Rioux]

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.

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/".

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.
 

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.

Regards,
Julien

[Julien Rioux]

On Tuesday, 16 October 2012 14:13:25 UTC+2, Julien Rioux wrote:

You're right, it actually uses http://pypi.python.org as index by default

I mean http://pypi.python.org/simple/

[Aaron Meurer]

On Tue, Oct 16, 2012 at 6:13 AM, Julien Rioux <julien...@gmail.com> 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.

[Julien Rioux]

On Tuesday, 16 October 2012 20:41:15 UTC+2, Aaron Meurer wrote:

I see it now.  That pep is very confusing. So should the correct way
really be 0.7.2c1 (without the r)?

You're reading it correctly, it recommends using 0.7.2c1, but as I understand 0.7.2rc1 is also valid and deviates less from the naming scheme that you have been using.

I noticed that you decided against adding the "-py2.5" naming scheme to the python 2 tarball. python3 pip install might pick up the wrong version now, since it considers both sympy-0.7.2.tar.gz and sympy-0.7.2-py3.x.tar.gz as compatible and equivalent versions, and who knows which one it will sort first.

Regards,
Julien

[Aaron Meurer]

Well it seems to be doing the right thing. If someone reports that it doesn't, I'll try to fix it. But uploading three python 2 tarballs didn't seem worth the trouble and confusion if it wasn't needed.  

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/-/W4njF5R4m0UJ.