Am 27.04.2012 23:57, schrieb Aaron Meurer:
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 don't think so. Virtualenv has been described to me as "just a way to
set up your paths", so I just need to run tox in a different interpreter
and it won't even know that it's running inside a virtualenv.
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.
Urk. That is a showstopper for some of the scheduling things I was
having in mind.
Such as increasing granularity so more CPU cores can be put to good use.
(I'm having a four-core machine here, and I have a server with eight at
my disposal. Having to schedule large chunks like bin/test, bin/doctest
and bin/test --slow in a separate process means that towards the end,
only one core will do useful work.)
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.
Looking forward to more feedback on this one then.
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").
Thanks, I'll take a look.
--
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.
