On Sun, Nov 18, 2012 at 3:16 PM, Matthew Brett <[email protected]>wrote:
> Hi, > > On Sun, Nov 18, 2012 at 2:06 PM, Aaron Meurer <[email protected]> wrote: > > On Sat, Nov 17, 2012 at 8:46 PM, Matthew Brett <[email protected]> > > wrote: > >> > >> Hi, > >> > >> On Sat, Nov 17, 2012 at 6:51 PM, Aaron Meurer <[email protected]> > wrote: > >> > On Nov 17, 2012, at 7:39 PM, Matthew Brett <[email protected]> > >> > wrote: > >> > > >> >> Hi, > >> >> > >> >> I've been running into trouble installing sympy with easy_install and > >> >> pip on python 2.7 and Python 3.3. > >> > > >> > What issues with pip are you having? I thought we fixed pip to do the > >> > right thing. > >> > >> Ah - I have a strong memory that I had issues with pip, but not now I > >> test it on this machine. Broken for easy_install (via distribute): > > > > > > That's because pip *was* broken, but we figured out how to fix it. The > > trick was adding -py3.2 and so on to the tarball names so that it was > sure > > to download the right one. > > > >> > >> > >> mb312@mikesilver ~]$ mkvirtualenv py27 --no-site-packages > >> New python executable in py27/bin/python > >> Installing setuptools.............done. > >> Installing pip...............done. > >> [mb312@mikesilver ~]$ workon py27 > >> (py27)[mb312@mikesilver ~]$ easy_install sympy > >> Searching for sympy > >> Reading http://pypi.python.org/simple/sympy/ > >> Reading http://code.google.com/p/sympy > >> Reading http://sympy.org > >> Reading http://sympy.org/ > >> Reading > >> http://code.google.com/p/sympy/downloads/detail?name=sympy-0.7.0.tar.gz > >> Best match: sympy 0.7.2-py3.3 > >> Downloading > >> > http://pypi.python.org/packages/source/s/sympy/sympy-0.7.2-py3.3.tar.gz#md5=4645f4bd3c50dac7486ccfaedbb29057 > >> Processing sympy-0.7.2-py3.3.tar.gz > >> Running sympy-0.7.2/setup.py -q bdist_egg --dist-dir > >> > >> > /var/folders/YB/YBjJ+eaQGb0EZfa9PJfcSk+++Tg/-Tmp-/easy_install-n5AKga/sympy-0.7.2/egg-dist-tmp-WFXCnm > >> Traceback (most recent call last): > >> File "/Users/mb312/.virtualenvs/py27/bin/easy_install", line 8, in > >> <module> > >> load_entry_point('setuptools==0.6c11', 'console_scripts', > >> 'easy_install')() > >> File > >> > "/Users/mb312/.virtualenvs/py27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/command/easy_install.py", > >> line 1712, in main > >> File > >> > "/Users/mb312/.virtualenvs/py27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/command/easy_install.py", > >> line 1700, in with_ei_usage > >> File > >> > "/Users/mb312/.virtualenvs/py27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/command/easy_install.py", > >> line 1716, in <lambda> > >> File > >> > "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/core.py", > >> line 152, in setup > >> dist.run_commands() > >> File > >> > "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", > >> line 953, in run_commands > >> self.run_command(cmd) > >> File > >> > "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", > >> line 972, in run_command > >> cmd_obj.run() > >> File > >> > "/Users/mb312/.virtualenvs/py27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/command/easy_install.py", > >> line 211, in run > >> File > >> > "/Users/mb312/.virtualenvs/py27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/command/easy_install.py", > >> line 446, in easy_install > >> File > >> > "/Users/mb312/.virtualenvs/py27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/command/easy_install.py", > >> line 476, in install_item > >> File > >> > "/Users/mb312/.virtualenvs/py27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/command/easy_install.py", > >> line 655, in install_eggs > >> File > >> > "/Users/mb312/.virtualenvs/py27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/command/easy_install.py", > >> line 930, in build_and_install > >> File > >> > "/Users/mb312/.virtualenvs/py27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/command/easy_install.py", > >> line 919, in run_setup > >> File > >> > "/Users/mb312/.virtualenvs/py27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/sandbox.py", > >> line 62, in run_setup > >> File > >> > "/Users/mb312/.virtualenvs/py27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/sandbox.py", > >> line 105, in run > >> File > >> > "/Users/mb312/.virtualenvs/py27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/sandbox.py", > >> line 64, in <lambda> > >> File "setup.py", line 36, in <module> > >> File > >> > "/var/folders/YB/YBjJ+eaQGb0EZfa9PJfcSk+++Tg/-Tmp-/easy_install-n5AKga/sympy-0.7.2/sympy/__init__.py", > >> line 27, in <module> > >> ImportError: It appears 2to3 has been run on the codebase. Use Python > >> 3 or get the original source code. > > > > > > ARGH! I did not know this. It seems that the same solution for pip is > the > > problem for easy_install. It thinks that sympy-0.7.2-py3.3 is the latest > > version. > > > > Any thoughts on how this can be fixed? I've said this before, but it > > deserves reiterating: I as a package maintainer have surprisingly little > > control over what pip or easy_install install. The best I can do is to > > manipulate what links are on PyPI and to use naming trickery to make it > > install the "latest" version. > > > > I created https://code.google.com/p/sympy/issues/detail?id=3511 for > this. > > How about having a sympy3 pypi project? > I hadn't thought of that. If we did this, then it would never do the right thing in Python 3, i.e., the users would have to know to use "pip install sympy3" instead of "pip install sympy" in Python 3. It might also complicated stuff for people whose travis.ini (or whatever) would otherwise just have a single pip install line. > >> We use easy_install much more than pip because pip will not install > >> binaries, and so is more or less useless for compiled packages. > > > > > > My best suggestion for this is to use pip for SymPy and easy_install for > the > > rest. Or you could just pass the url manually to eas_install. If you can > > figure out how to name the tarballs so that pip *and* easy_install do the > > right thing, I'd love to hear it. But I'm very doubtful that a solution > > exists. The Python packaging ecosystem is irrevocably broken as far as > I'm > > concerned. > > Tell it brother :) And yes of course it throws the burden for the > workarounds onto each package maintainer, which is tiring and > wasteful. But nevertheless, it can be made to work, by doing 2to3 in > the setup.py. > > >> > >> > >> >> The fact that easy_install / pip is unlikely to work means that sympy > >> >> is a considerably heavier burden for our (nipy.org/nipy) users to > >> >> install, and I'd very much like to help fix that. > >> >> > >> >> This led me to start editing the sympy setup.py to do the standard > >> >> thing of running 2to3 during setu.py install : (e.g numpy, scipy, > >> >> matplotlib, our projects). > >> >> > >> >> I immediately found why you haven't done this: you depend on running > >> >> > >> >> python setup.py run_tests > >> >> > >> >> and > >> >> > >> >> python setup.py run_benchkmarks > >> >> > >> >> in the source tree. So, there's no way of running these for python > 2 > >> >> and python 3 in the same source tree (unless you go for python 3 > >> >> compatibility in source - a bit much). > >> >> > >> >> So - I'm writing to ask if you'd consider looking at a refactor that > >> >> would change these calls above to: > >> >> > >> >> python setup.py install --user (or whatever) > >> >> cd /somewhere > >> >> python -c 'import sympy; sympy.test()' > >> > > >> > The problem is that setup.py test runs tests that aren't included in > >> > an install, namely the Sphinx doctests. > >> > >> Would it be an option to run these separately? For example with > >> > >> python setup.py run_doctests > >> > >> ? Or maybe with > >> > >> python setup.py run_tests > >> > >> where ``run_tests`` does something like: > >> > >> mkdir tmp > >> cd tmp > >> python -c 'import sympy; sympy.test()' > >> cd .. > >> cd doc > >> make.py doctest > > > > > > setup.py test just runs all combinations of tests, which already have > their > > individual scripts. I think right now it's equivalent to something like > > > > ./bin/test > > ./bin/doctest > > <whatever the sage test script is> > > ./examples/all.py -q > > > > Actually, it just runs sympy.utilities.runtests.run_all_tests(), which is > > itself a wrapper to the above tests. So there is actually no need for > > anything in the setup.py script itself to do tests. It's just a nice > > shortcut for us. > > RIght - I think I'm asking whether you'd consider moving from: > > python setup.py run_tests > > to > > python setup.py install > python setup.py run_tests > > in order to make it possible to processing the source tree (for > compiled code or 2to3) before running? > Am I misunderstanding what you're asking for? Would you run the tests against the installed version or the local version? > > >> - if you see what I mean. This would then fail unless there is an > >> installation somewhere, perhaps with a nice message to run ``python > >> setup.py install`` first. > >> > >> I'm sorry for my ignorance - but how have y'all been doing the edit / > >> debug cycle in python 3? > > > > > > I never use virtualenv to test SymPy, unless I am testing installation. > I > > just run ./bin/use2to3 and cd py3k-sympy and work locally. I guess it's > > easy for us because we don't have any dependencies, especially > dependencies > > that don't work unless installed. > > I probably wasn't clear; I was thinking that it might be tough to have to > do: > > ./bin/use2to3 > cd py3k-sympy > while not Finished: > <edit> > <test> > and then have to backport the changes in py3k-sympy to the sympy tree > - but I probably didn't get the workflow. > Oh, we never develop against the Python 3 code (or at least I don't). I just make all changes against Python 2 and then 99% of the time 2to3 does the right thing and it works in Python 3 as well, and for the remaining 1%, I find out later and fix it using whatever workaround. I guess the take away is that I never personally use Python 3, except for testing to see if it work. My day-to-day workflow is still Python 2. I think I wrote one script for personal use in Python 3. Maybe if some of the other SymPy developers use Python 3 more they do things differently. Aaron Meurer > > Best, > > Matthew > > -- > 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. > > -- 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.
