API backward compatibility
Stefano Maggiolo
I am using psutil for a project of mine. I started supporting a mix of
psutil 0.2.0 and 0.1.3 writing a very small code to handle the
differences between the two versions. I wasn't very happy when 0.2.1
came out and there were some more incompatibilities (e.g.,
get_system_cpu_times returned an internal type instead of a dict). But
I adapted my code to support this other version.
Now, several other versions came out, and I already saw that
get_system_cpu_times vanished. I did not investigate on other changes
to the public APIs. I would only like to know if you are planning to
have a core set of APIs that we can trust to be supported on future
versions, or if you are still doing heavy changes to them and we
cannot trust them to remain stable.
Thank you.
Giampaolo Rodolà
Ciao Stefano,
as far as I can recall, prior to 0.2.0 version psutil.cpu_times(),
psutil.Process.get_memory_info() and psutil.Process.get_cpu_times()
were returning plain tuples.
After 0.2.0 version, according to:
http://code.google.com/p/psutil/source/browse/tags/release-0.4.1/HISTORY#168
....we introduced namedtuples instead, which are basically the same
except you can access fields by name instead of just position index.
As such, compatibility shouldn't have been broken.
> Now, several other versions came out, and I already saw that
> get_system_cpu_times vanished.
get_system_cpu_times() is still there but it is an *internal* function
which is NOT supposed to be used.
You have to use psutil.cpu_times() instead.
Basically, the namespace you have to rely on is all inside "psutil"
(import psutil; psutil.something) and it is summarized here, in
__all__:
http://code.google.com/p/psutil/source/browse/tags/release-0.4.1/psutil/__init__.py#17
Maybe 0.1.3 were exposing get_system_cpu_times() into psutil
namespace? I can't recall.
> I did not investigate on other changes
> to the public APIs. I would only like to know if you are planning to
> have a core set of APIs that we can trust to be supported on future
> versions, or if you are still doing heavy changes to them and we
> cannot trust them to remain stable.
Generally we care a lot about backward compatibility (in fact we still
support python 2.4) and I can't recall any heavy change or public API
breakage.
private APIs breakage (since you mentioned get_system_cpu_times())
surely occurred, and more than once, but again, you are not supposed
to use private APIs in the first place (and you don't need to).
As for your specific case, versions 0.1.3/0.2.0 are quite old, so I
can't recall all the API changes occurred since then.
You can take a look at current HISTORY file and search for "api
changes" and figure out by yourself whether an upgrade might break
your code:
http://code.google.com/p/psutil/source/browse/tags/release-0.4.1/HISTORY
I personally think it's unlikely though.
Best regards,
--- Giampaolo
Giampaolo Rodolà
because of "from foo import *" statements:
http://code.google.com/p/psutil/source/browse/tags/release-0.1.2/psutil/_psutil.py#40
This was fixed later in 0.3.0:
http://code.google.com/p/psutil/source/browse/tags/release-0.3.0/psutil/__init__.py#42
--- Giampaolo
Stefano Maggiolo
thank you for your reply. I hope I didn't sound too harsh in my first
post.
As for the point you raised.
- I always used "import psutil", so the get_system_cpu_times was
exported even in that case. Usually private methods are prefixed with
a _, so when I saw that function without the underscore I thought it
was public.
- Yes, 0.1.3 and 0.2.x are old but nevertheless my up to date Ubuntu
11.10 ships with 0.2.1. And on production machines we have also older
distributions (back to 10.04) that IIRC have 0.1.3.
Anyway, I'll try to update my code to use 0.3 and see what happens to
previous versions. Compatibility with 0.1.3 seems a bit overkill, so
I'll be happy if it'll work against 0.2.x. I'll let you know.
Grazie!
Stefano
Giampaolo Rodolà
> Ciao Giampaolo,
> thank you for your reply. I hope I didn't sound too harsh in my first
> post.
No, not at all.
It's my reply which maybe was too long.
> As for the point you raised.
>
> - I always used "import psutil", so the get_system_cpu_times was
> exported even in that case. Usually private methods are prefixed with
> a _, so when I saw that function without the underscore I thought it
> was public.
I would have thought the same.
> - Yes, 0.1.3 and 0.2.x are old but nevertheless my up to date Ubuntu
> 11.10 ships with 0.2.1. And on production machines we have also older
> distributions (back to 10.04) that IIRC have 0.1.3.
Personally, I see no point in using apt-get for installing python
libs, especially for those ones such as psutil which are not as "big"
as stuff like twisted, django, PIL, etc.
Can't you just use pip / easy_install / python setup.py install?
If you don't want to mess with system paths you might try virtualenv.
Another option is "python setup.py install --user" which will install
psutil in ~/.local/lib/python2.7/site-packages/
Also:
giampaolo@ubuntu:~/svn/psutil$ apt-rdepends --reverse
--follow=python-psutil python-psutil
Reading package lists... Done
Building dependency tree
Reading state information... Done
python-psutil
Reverse Depends: eucalyptus-admin-tools (2.0.1+bzr1256-0ubuntu8)
...it seems "eucalyptus-admin-tools" is the only package depending on psutil.
> Anyway, I'll try to update my code to use 0.3 and see what happens to
> previous versions. Compatibility with 0.1.3 seems a bit overkill, so
> I'll be happy if it'll work against 0.2.x. I'll let you know.
Both 0.1.3 and 0.2.x are pretty rusty.
If you can avoid using apt-get just stick with 0.4.1.
Giampaolo
Stefano Maggiolo
> Anyway, I'll try to update my code to use 0.3 and see what happens to
> previous versions. Compatibility with 0.1.3 seems a bit overkill, so
> I'll be happy if it'll work against 0.2.x. I'll let you know.
Indeed, using only methods of >= 0.3.0 made it work also for 0.2.x, so
I'm happy. Thank you for the clarifications (and also for the work you
are doing), I'm sorry that my first impression originated from a small
misunderstanding.
Cheers,
Stefano
Stefano Maggiolo
> Personally, I see no point in using apt-get for installing python
> libs, especially for those ones such as psutil which are not as "big"
> as stuff like twisted, django, PIL, etc.
> Can't you just use pip / easy_install / python setup.py install?
You are right (I tried the several versions using easy_install and it
was very slick), bit I guess that it is easier to tell people to do an
apt-get install instead of asking them to install a Python package.
Nevertheless, as I said in the other message, I managed to make my
code work back to 0.2.0 so that pretty much cover the range I'm
interested in.
Thank you again!
Stefano
Giampaolo Rodolà
You're welcome. ;-)
G.