On Thu, Oct 11, 2012 at 11:25 AM, Aaron Meurer <[email protected]> wrote: > On Thu, Oct 11, 2012 at 8:37 AM, Ondřej Čertík <[email protected]> > wrote: >> On Wed, Oct 10, 2012 at 7:03 PM, Aaron Meurer <[email protected]> wrote: >>> On Wed, Oct 10, 2012 at 5:45 PM, Ondřej Čertík <[email protected]> >>> wrote: >>>> 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. :) >>> >>> 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. >> >> 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: > > 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.
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 -- 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.
