On Wed, Oct 10, 2012 at 2:50 PM, Ondřej Čertík <[email protected]> wrote: > On Wed, Oct 10, 2012 at 11:52 AM, Aaron Meurer <[email protected]> wrote: >> On Wed, Oct 10, 2012 at 12:46 PM, Aaron Meurer <[email protected]> wrote: >>> On Wed, Oct 10, 2012 at 12: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. >>>> >>>> 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. >>> >>> 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 >> >> 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. > > 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.
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 -- 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.
