Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade to unittest2 #391

Closed
giampaolo opened this issue May 23, 2014 · 5 comments
Closed

Upgrade to unittest2 #391

giampaolo opened this issue May 23, 2014 · 5 comments

Comments

@giampaolo
Copy link
Owner

From g.rodola on June 10, 2013 02:32:26

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: http://code.google.com/p/psutil/issues/detail?id=391

@giampaolo giampaolo self-assigned this May 23, 2014
@giampaolo
Copy link
Owner Author

From [email protected] on June 09, 2013 17:43:59

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.

@giampaolo
Copy link
Owner Author

From g.rodola on June 09, 2013 18:07:05

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.

@giampaolo
Copy link
Owner Author

From [email protected] on June 09, 2013 18:17:21

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.

@giampaolo
Copy link
Owner Author

From g.rodola on June 16, 2013 15:07:45

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

Status: FixedInHG

@giampaolo
Copy link
Owner Author

From g.rodola on July 11, 2013 01:54:35

Status: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant