On Sat, Apr 28, 2012 at 5:38 AM, Joachim Durchholz <j...@durchholz.org> wrote: > 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.)
Maybe you could look at using the IPython parallel framework in our tests. Ondrej played with this a while ago, but that was with the old framework. The idea is to run each test independently, and in parallel. Back when we tested it before, there was a speedup. The speedup was along the lines of n - 1/2, where n is the number of cores (the -1/2 was because one core was used for the controller). They've completely rewritten their parallel engine, so this will have to be redone, but it might be worth trying if you want this. Aaron Meurer > > >>> 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. > -- 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.
