On Wed, Oct 10, 2012 at 3:14 PM, Matthew Brett <[email protected]> wrote: > Hi, > > On Wed, Oct 10, 2012 at 7:35 PM, Ondřej Čertík <[email protected]> > wrote: >> On Tue, Oct 9, 2012 at 10:53 PM, Aaron Meurer <[email protected]> wrote: >>> On Tue, Oct 9, 2012 at 11:43 PM, Ondřej Čertík <[email protected]> >>> wrote: >>>> On Tue, Oct 9, 2012 at 10:42 PM, Ondřej Čertík <[email protected]> >>>> wrote: >>>>> On Mon, Oct 8, 2012 at 11:20 PM, Aaron Meurer <[email protected]> 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 >>>> >>>> series -> serious. >>>> >>>> Ondrej >>> >>> 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. >> >> So this looks like that pip is seriously broken... Don't worry about this >> then. >> Let's release and then worry about this. > > Wasn't this predictable though? Hence my previous suggestion to try
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 -- 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.
