classification
Title: platform.linux_distribution() should honor /etc/os-release
Type: enhancement Stage: needs patch
Components: Library (Lib) Versions: Python 3.4
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: lemburg Nosy List: Arfrever, christian.heimes, doko, elixir, eric.araujo, ezio.melotti, jaywink, jwilk, lemburg, petr.viktorin, vajrasky, vstinner
Priority: normal Keywords: easy, patch

Created on 2013-04-16 15:01 by doko, last changed 2015-05-13 14:21 by lemburg. This issue is now closed.

Files
File name Uploaded Description Edit
add_os_release_support.patch elixir, 2013-10-24 14:59 review
add_os_release_support_2.patch elixir, 2013-11-02 21:02 review
Messages (17)
msg187089 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2013-04-16 15:01
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.
msg187389 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2013-04-19 22:08
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.
msg201013 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-10-23 11:05
*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.
msg201023 - (view) Author: -- (elixir) * Date: 2013-10-23 13:47
I'm working on a patch. Hopefully, it will be ready in a day or two.
msg201144 - (view) Author: -- (elixir) * Date: 2013-10-24 14:59
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.
msg201152 - (view) Author: Vajrasky Kok (vajrasky) * Date: 2013-10-24 16:20
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.
msg201154 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2013-10-24 16:31
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.
msg201518 - (view) Author: Vajrasky Kok (vajrasky) * Date: 2013-10-28 09:09
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.
msg201543 - (view) Author: Vajrasky Kok (vajrasky) * Date: 2013-10-28 14:23
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.
msg201603 - (view) Author: -- (elixir) * Date: 2013-10-29 05:09
Yes, I will provide a patch including tests soon.
msg201987 - (view) Author: -- (elixir) * Date: 2013-11-02 21:02
New patch. Added tests and fixed uncaught OSError.
msg202394 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-11-07 23:15
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
msg202395 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2013-11-07 23:33
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.
msg205773 - (view) Author: Vajrasky Kok (vajrasky) * Date: 2013-12-10 07:21
This patch needs to be updated to tip since this commit: http://hg.python.org/cpython/rev/4580976c07cb
msg224548 - (view) Author: Jason Robinson (jaywink) * Date: 2014-08-02 10:53
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?
msg243088 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2015-05-13 14:15
The functions have been deprecated in #1322, is it time to close this?
msg243092 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2015-05-13 14:21
See issue1322 for why we're closing this.
History
Date User Action Args
2015-05-13 14:21:06lemburgsetmessages: + msg243092
2015-05-13 14:19:56lemburgsetstatus: open -> closed
resolution: wont fix
2015-05-13 14:15:27petr.viktorinsetmessages: + msg243088
2015-05-12 13:15:14petr.viktorinsetnosy: + petr.viktorin
2014-08-02 10:53:54jaywinksetnosy: + jaywink
messages: + msg224548
2013-12-10 11:07:02jwilksetnosy: + jwilk
2013-12-10 07:21:26vajraskysetmessages: + msg205773
2013-11-07 23:33:25dokosetmessages: + msg202395
2013-11-07 23:15:52vstinnersetmessages: + msg202394
2013-11-03 07:37:22elixirsetnosy: + vstinner
2013-11-02 21:02:09elixirsetfiles: + add_os_release_support_2.patch

messages: + msg201987
2013-10-29 05:09:20elixirsetmessages: + msg201603
2013-10-28 23:12:22Arfreversetnosy: + Arfrever
2013-10-28 14:23:17vajraskysetmessages: + msg201543
2013-10-28 09:09:20vajraskysetmessages: + msg201518
2013-10-24 16:31:05lemburgsetmessages: + msg201154
2013-10-24 16:20:28vajraskysetnosy: + vajrasky
messages: + msg201152
2013-10-24 14:59:41elixirsetfiles: + add_os_release_support.patch
keywords: + patch
messages: + msg201144
2013-10-23 13:47:51elixirsetnosy: + elixir
messages: + msg201023
2013-10-23 11:05:10christian.heimessetkeywords: + easy

messages: + msg201013
2013-04-20 22:36:13christian.heimessetnosy: + christian.heimes
2013-04-19 22:08:15eric.araujosetassignee: lemburg

messages: + msg187389
nosy: + eric.araujo, lemburg
2013-04-16 15:03:10ezio.melottisetnosy: + ezio.melotti
type: enhancement
2013-04-16 15:01:08dokocreate