Use distro


I suggest using nir0s/distro for discovering the facts about linux distribution (name, version, codename).


Hi @FooBarQuaxx,

I noticed the deprecation of useful code from the Python standard library platform module (platform.dist()) and the mention of the distro module, but read the code and was disappointed in the recommendation as well as the deprecation in Python 3. I believe the python maintainers made the wrong choice, but this was probably done without a background in systems management tools, where the core maintainers didn't realize how much that module might be used.

In particular, distro didn't handle OS X the last time I checked, which is a fairly common control point for configuration management systems, since about.... forever. It appears they've done this now, but it's just a bad sign. We have bugs open from 6+ months ago for failing tests for OpenSuSE.

The strategy for OpsMop is to have reliable and minimal dependencies, and this library doesn't look up to snuff for me.

Ultimately, the amount of checks we have to do are small, and once we sort through them, there's no need for an extra dependency for something this small.

Further, the way we are using mitogen, we also want to minimize external deps and rely on shell tools for modules that are likely to be transferred.

Ultimately, just relying on python, the operating system, and a small handful of libraries seems more reliable.

Looking through the code of what's there, it seems to be largely based on the assumption of release-files being present, but doesn't really account for the possibility of those being in different formats. I'm not sure how well that will work. (This is of course not to say our code couldn't be cleaner, as it could)

On the subject of limiting dependencies, it isn't true that we will always be confined to this set, however, as in some cases we may block some imports from mitogen to use libraries that are conditionally accessed.

I strongly want to avoid fragility in dependencies when they change upstream without notice.

So, ultimately, something like this belongs in core.

By including everything directly in OpsMop, I can guarantee that when a new distro gets out, a patch can be merged in a very short amount of time, and I don't have to track another upstream.

In short, this is going to be more reliable, faster, easier, and more future-proof...

If there are specific problems you are seeing, I'd like to address them directly. (Or send me a pull request to add a new distro, if one happens to be missing).