homepage

http://www.freedesktop.org/software/systemd/man/os-release.html
is a recent standard describing release information for an operating system. platform.linux_distribution() should know about it.
 - should that be the first file to be parsed?
 - names returned for the ID are different than the ones
 returned from /etc/lsb-release. The os-release thing
 only allows lower case letters for the ID (e.g. Ubuntu
 vs. ubuntu). The list of _supported_distros may
 need to list both.
 - take the version from VERSION_ID
 - there is no real attribute for the code name. The closest
 maybe is VERSION.

os-release finally provides a cross-OS release file with a specification. I think it should be authoritative, then the lsb-release system (it’s officially a script but many OSes just parse a static file), then OS-specific files.

*bump up*
I'd like to see the feature in 3.4. It shouldn't be too hard to implement it. A patch would also solve #1322 and #9514 on most modern systems. 
For the record RHEL 5, RHEL 6.4, SLES 11 and Ubuntu 10.04 don't have /etc/os-release. Ubuntu 12.04 has the file.

I'm working on a patch. Hopefully, it will be ready in a day or two.

I added a patch (my first patch!).
platform.linux_distribution() now first looks in /etc/os-release. If this file is not found, checking continues as before.

Hi Andrei Duma,
I have looked at your patch but have not tested it yet. But it seems to me that your patch is a little bit weak against the case where the file /etc/os-release is found, but not fully functional (either garbage, or only releases NAME information but not VERSION).
But again, I am not so sure we should really bit pedantic about this or not. Need to do some investigation.

On 24.10.2013 16:59, Andrei Dorian Duma wrote:
> 
> I added a patch (my first patch!).
> 
> platform.linux_distribution() now first looks in /etc/os-release. If this file is not found, checking continues as before.
Looks good.

Apparently my fear is unfounded. The dist, version, id have been initialized with empty value. So if the os-release file does not have complete information, it should be okay with the patch from Andrei Duma.

Hi, Andrei.
Could you provide the test? You could take a look at issue 17429 to see how it is done.
http://bugs.python.org/issue17429
We would be grateful if you could test the case where os-release file is non-ascii encoded file (although technically it should be tested in issue 17429). Sometimes the Linux distro version has non-ascii characters, such as Schrödinger's Cat.

Yes, I will provide a patch including tests soon.

New patch. Added tests and fixed uncaught OSError.

Comments on add_os_release_support_2.patch:
- You should not write a huge try/except OSError block. I would prefer something like:
try:
 f = open(...)
except OSError:
 return None
with f:
 ...
- I'm not sure about that, but you might use errors='surrogateescape', just in case if the file is not correctly encoded. Surrogate characters are maybe less annoying than a huge UnicodeDecodeError
- You use /etc/os-release even if the file is empty. Do you know if there is a standard, or something like that explaining if some keys are mandatory? For example, we can ignore os-release if 'ID' or 'VERSION_ID' key is missing
- For the unit test, you should write at least a test on linux_distribution() to check that your private function is used correctly
- You add unit tests for all escaped characters (', ", \), for comments, and maybe also for maformated lines (to have a well defined behaviour, ignore them or raise an error)
- _UNIXCONFDIR looks to be dedicated to unit tests, can't you patch builtin open() instead? It would avoid the need of a temporary directory

my concern here is that platform.linux_distribution returns different values for the tuple, wether os-release is found or the lsb config file is found. I don't know about a good solution, however if the return value has different values, that has to be clearly documented, or maybe unified in some form.

This patch needs to be updated to tip since this commit: http://hg.python.org/cpython/rev/4580976c07cb 

platform.linux_distribution is being deprecated in 3.5 and removed in 3.6 as stated in comment http://bugs.python.org/issue1322#msg207427 in issue #1322
I'm guessing this issue should be closed when that patch is merged in?

The functions have been deprecated in #1322, is it time to close this?

See issue1322 for why we're closing this.