Sometimes an Ubuntu package of a Python module is probably good enough

December 9, 2022

Recently I ran across a Python program we're interested in, and discovered that it required prometheus-client. Normally this would mean creating a virtual environment and installing the module into it, possibly along with the program (although you don't have to put the program inside the venv it uses). But when I looked out of curiosity, I saw that Ubuntu packages this module, which got me to thinking.

I'm generally a sceptic of relying on the Ubuntu packaged version of a Python module (or any OS's packaged version); I wrote about this years ago in the context of Django. Linux distribution packaging of Python modules is famously out of date, and Ubuntu makes it worse by barely fixing bugs at the best of times. However, this feels like a somewhat different situation. The program isn't doing anything much with the prometheus-client module, and the module itself isn't very demanding; probably quite a lot of versions will do, and there's unlikely to be a bug that affects us. Indeed, some quick testing of the program with the Ubuntu version suggests that it works fine.

(Although now that I look, the Ubuntu version is rather out of date. Ubuntu 22.04 LTS packages 0.9.0, from 2020-11-26, and right now according to the module's releases page it's up to 0.15.0, with quite a few changes.)

Provided that Ubuntu's version of the module works, which it seems to, using the Ubuntu packaged version is the easy path. It's not an ideal situation, but for something with simple needs (and which isn't a high priority), it's rather tempting to say that it's okay. And if the Ubuntu version proves unsatisfactory, changing over to the latest version in a virtual environment is (at one level) only a matter of changing the path to Python 3 in the program's '#!' line.

(We have another program that requires a Python module, pyserial, that we get from Ubuntu, but I didn't think about it much at the time. This time around I first built a scratch venv for the program to test it, then discovered the Ubuntu package.)

Comments on this page:

By Andrew at 2022-12-13 01:53:32:

I spent a lot of years supporting people doing similar things for Perl, and our mantra was as follows: The distro Perl library packages aren't for you. They're there for the benefit of distro-packaged apps that happen to be written in Perl. If you want to use one for a one-off, and it works, fine. But if it breaks some day, don't be surprised. And if a library is out of date, or one you need is missing, your reaction shouldn't be to put together a bunch of machinery to create more distro packages. Just use the tools that Perl gives you to bundle together your dependencies in a place that the distro doesn't know or care about, and insulate yourself from all of its silliness.

IMO the same thing applies for Python. Works fine today is fine for today, but don't build a process around it :)

Written on 09 December 2022.
« Python version upgrades and deprecations
Unix's special way of marking login shells goes back to V2 Unix (at least) »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Dec 9 21:20:16 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.