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 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.
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.
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).
--
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.
