On Tue, Apr 24, 2012 at 1:40 AM, Joachim Durchholz <j...@durchholz.org> wrote: > Am 23.04.2012 09:28, schrieb Aaron Meurer: > >> On Sun, Apr 22, 2012 at 2:18 PM, Joachim Durchholz<j...@durchholz.org> >> wrote: >>> >>> Am 17.04.2012 18:41, schrieb Aaron Meurer: >>> >>>> By the way, if you're just using virtualenv to run the tests and >>>> nothing else, >>> >>> >>> >>> Indeed. >>> >>> >>>> you should use tox, which does all of this for you >>>> >>>> automatically (see the tox.ini.sample file in the sympy repo). >>> >>> >>> >>> Just a heads-up here: >>> pip install tox won't work for most people with a package-manager-managed >>> Python install, because tox isn't in the usual package lists. >> >> >> pip is separate from other package managers. It just downloads the >> package and setup.py installs it. You may have to install pip, though >> (the easiest way is to do "easy_install pip"). >> >> Granted, if a Python package like tox is in your Linux package >> manager, and isn't ridiculously out of date, it's probably better to >> install it using that, as that gives you more features like >> dependencies and the ability to uninstall the package. > > > It's just the other way round: I don't have tox in the package list, so I > need to use pip or easy_install, which means using virtualenv so I have an > environment I can install tox into. > > Uninstalling tox is then easy, just throw away the virtual environment :-)
I'm not sure if you want to do that. Then you would have to have nested virtualenvs to use tox (does that even work?). > > >>> I guess virtualenv is required to build a local Python install first. I'm >>> a >>> bit confused about what tox can do for me after that; a few virtualenv >>> calls >>> to cycle through installed Pythons and running a few commands doesn't >>> sound >>> rocket-sciency enough to me to warrant installing yet another tool like >>> tox. >>> What am I overlooking? >> >> >> It does everything for you automatically. You just create a simple >> file, and type "tox" and everything happens on its own. The very fact >> that I've used tox but still don't really know how to use virtualenv >> completely is testament to this. It's especially great if you do it a >> lot, because you don't have to repeat all the steps with the >> virtualenv. Plus your console PATH is never modified (the virtualenv >> is never activated). And if you try to do things manually, there's a >> lot of room for error. > > > What I'm missing in tox is a way to control the number of background > processes it uses. Say, I want to run the full test suite: all Python > versions, all tests, all ground types (that's going to take quite a while, > so I want this to run in the background, with a lower priority, so I can > continue to work). > This seems to be an underdeveloped area of tox. In fact tox assumes that it > can leave that to pytest, but that won't work if I want to configure it for > multiple Python versions. Yeah, they don't really have any of that implemented. You'll have to use your built-in OS services to reduce the priority, and you'll have to run multiple instances of tox to do things in parallel. > > Hm. That leads me to another question: > What were the reasons that we forked pytest for our own purposes? > Do these reasons still hold, or should we now go back to using pytest? > The issue was mentioned on the list, but I don't recall details. I think Ondrej is the only one who can answer that, as everyone else was not around when it happened. And Ronan recently submitted a pull request that worked on making py.test work again, so he can probably comment on the current state of things. > > In general, I'd like to work on the testing infrastructure. We currently > have a rather haphazard collection of tools and dependencies, and the > documentation doesn't cover all bases (such as my scenario where I need > virtualenv to even start using the toolset). > I see that several people are making movements in the same direction; how > about collecting the requirements, looking into the tools available, and > laying out a strategy? > References to existing issues would also be helpful, but I think we need a > strategy; a lot of discussion on the testing framework has been moving in > circles (Yours Truly certainly being a part of that). There is a label in the issue tracker, "Testing", that should be on all testing related issues (just search for "label:Testing"). Aaron Meurer > > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > 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 sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
