STINNER Victor <vstin...@python.org> added the comment:
Marc-Andre Lemburg: > The main reason why it failed was the Linux distros keep inventing new ways > to identify themselves, sometimes misuse existing mechanisms to maintain > compatibility (e.g. as a Ubuntu or RedHat based OS) or ship with two > different release files. > (...) > Then the LSB standardized this and wanted everyone to use lsb_release. Guess > what... The tool is not even installed anymore by default on recent OpenSUSE > releases. Experience shows that these things change too often to make the > stdlib a good place to maintain support for this. Please read the discussion. os-release is a standardize file: fixed filename, only 2 possible locations, standardize format. It's a freedesktop specification. In my experience, freedesktop standards are well adopted, whereas LSB standards look like a failed attempt. This is no need to bet on the future. os-release file is already available on all major Linux distribution, as, again, explained in depth in previous comments. There is no need to install a lsb_release program or anything. It's part of the *base* image on these systems. As you wrote, lsb_release isn't installed on many operating systems. For example, I just checked on my Fedora 33, it's not installed... Moreover, I'm not comfortable with running an external program which causes its own set of issue. Reading a plain text file is safer and faster. > To get a sense of the complexity involved in all this, have a look at how Ansible does this: > https://github.com/ansible/ansible/blob/ea119d30894478b84b5fbe271f580cb2b0401b86/lib/ansible/module_utils/facts/system/distribution.py Ansible has a high-level API similar to what the Python distro module does: it calls uname, parse /etc/*release files, try to normalize values, has special cases, etc. Not everybody needs like kind of advanced API. For my own use cases (see previous comments), I'm perfectly fine with basic and incomplete information. > It's not just about the file name, the content also needs a lot > of massaging to make it useful for a general purpose API. (...) I strongly suggest to keep platform.freedesktop_os_release() as simple as possible: just parse the file, no special case at all. For example, I'm against treating ID_LIKE variable differently in PR 23492. Users would expect if another space separated variable is added tomorrow, the function would also specialize it, and so we would come back to the linux_distribution() maintenance issue. IHMO a dummy text parser remains very useful. The file format is not as trivial as it looks, there are single quote and double quotes, and escaped characters. If someone wants a more complete API, I suggest to develop it on PyPI on top of the new function. It's fine to provide any API where some variables can miss if the there are not provided by the operating system. For me, it's like the os and select modules which are thin wrappers to operating system functions (syscalls). And then there are more high-level module like shutil and selectors. But we don't need to ship a high-level API for os-release. Platform was always a thin wrapper to OS functions. For example, there is no unified API to retrieve OS name and version on Windows, macOS or Linux. You need to pick the proper function. For me, freedesktop_os_release() just follows this trend. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28468> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
