Upgrade to unittest2

[GoogleCodeExporter]

unittest was updated in Python 2.7 in order to include new handy APIs such as 
the @unittest.skip decorator, assertIn, assertRaisesWithRegex and others.

Since we intend to support Python 2.4 I explicitly avoided to rely on these new 
APIs and replicated some of them straight into test_psutil.py.

These are dirty hacks though and I'm sick of them.
I think it's better for psutil 1.0 to get rid of them and just require users 
who are still on python < 2.7 and are willing to run tests to install unittest2 
from pypi https://pypi.python.org/pypi/unittest2

Original issue reported on code.google.com by g.rodola on 10 Jun 2013 at 12:32

[GoogleCodeExporter]

Just a thought: for OS X at least, 10.6 and 10.7 ship with < Python 2.7 and it 
comes with the OS. I'm not sure about other platforms but that's something to 
consider since most Linux distros ship with Python also. Even on RedHat 6.2 
which we use at my day job, it's still on only Python 2.6.6 as the default 
version.

Obviously it's up to you if you want to force the move to unittest2 anyway. 
However, if you have a workaround in place and since psutil is supposed to 
support those earlier versions anyway, it might make sense to wait another 
release cycle or two until Python 2.7 is more ubiquitous.

Original comment by jlo...@gmail.com on 10 Jun 2013 at 12:43

[GoogleCodeExporter]

True, thanks for the insight. 
We must consider a couple of things though:

- aside from us I expect tests to be rarely executed in general

- they are intended more for developers willing to work on the lib rather than 
for end users

- psutil per-se won't require any extra dep in order to work (as in 'unittest2' 
won't appear in setup.py)

- installing unittest2 is easy ("easy_install-2.6 unittest2" will do it) and it 
can be mentioned in the error message 

- explicitly avoiding to use unittest2 facilities as we're doing right now 
translates into less clear failure messages and clunky code (see for example 
the "assert x in y, (x, y)" occurrences all over the place

I'll see whether leaving the current workarounds in place and adding the 
missing ones is doable, but sooner or later I expect we'll need to make a 
cleanup anyway.

Original comment by g.rodola on 10 Jun 2013 at 1:07

[GoogleCodeExporter]

Yeah I think it's a reasonable change, and I can see a good point for doing it 
either way. My thinking was if it's working as is with the workaround then 
there's no particular urgency to make the switch and if we wait another 
generation or two of releases it'll be a smoother transition. 

One last note, these are dev tools so not a huge deal for users, but I wouldn't 
be surprised if they're also run as part of the build/packaging process for 
some of the distributions that are including psutil.

Original comment by jlo...@gmail.com on 10 Jun 2013 at 1:17

[GoogleCodeExporter]

I ended up maintaining compatibility with old unittest as you suggested.
After all it didn't require too much effort.

Original comment by g.rodola on 16 Jun 2013 at 10:07

• Changed state: FixedInHG

[GoogleCodeExporter]

Original comment by g.rodola on 11 Jul 2013 at 8:54

• Changed state: Fixed