This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Deprecate platform.dist() and platform.linux_distribution() functions
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.5
process
Status: closed Resolution: fixed
Dependencies: 3937 Superseder:
Assigned To: berker.peksag Nosy List: ShaneHarvey, andymaier, benjamin.peterson, berker.peksag, bgomes, christian.heimes, doko, draghuram, eric.araujo, georg.brandl, lemburg, leycec, mcepl, nir0s, pavel.vinogradov, petr.viktorin, pola, python-dev, sapetnioc, vajrasky, xnox, zooko
Priority: normal Keywords: needs review, patch

Created on 2007-10-24 17:21 by sapetnioc, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
debian_version christian.heimes, 2007-10-26 11:48
lsb-release christian.heimes, 2007-10-26 11:48
platform.py sapetnioc, 2007-10-30 10:49
platform_py25.patch christian.heimes, 2007-10-30 12:04
test_platform_py26.diff pavel.vinogradov, 2008-02-23 16:22 Patch for python 2.6 trunk. Include some additional linux test cases.
test_platform_py26_fix_centos.diff bgomes, 2008-05-12 02:28 Fix to patch test_platform_py26.diff return distname with contents of file
dist.patch.txt zooko, 2008-09-23 19:39 zooko's patch to identify linux platform by parsing /etc/lsb-release or else invoking lsb_release
deprecate_platform_dist.patch vajrasky, 2014-01-06 10:53 review
deprecate_platform_dist_v2.patch vajrasky, 2014-01-07 03:01 review
issue1322.diff berker.peksag, 2014-08-06 04:49 review
Pull Requests
URL Status Linked Edit
PR 6669 mbussonn, 2018-05-02 14:33
Messages (75)
msg56710 - (view) Author: Yann Cointepas (sapetnioc) Date: 2007-10-24 17:21
The distribution name returned by platform.dist() depends on the order
of os.path.listdir( '/etc' ). It selects the first file matching the
regex r'(\w+)[-_](release|version)' and takes part of the file name
(i.e. matchResult.groups()[0]) as distribution name. But there are often
several files matching this pattern (at least on Fedora and Mandriva).
For instance, on a Mandriva 2007.1 official, I can see the following files:

[login@localhost ~]$ ls -l /etc/*-release
-rw-r--r-- 1 root root 137 jan 18  2007 /etc/lsb-release
lrwxrwxrwx 1 root root  16 oct  7 17:32 /etc/mandrakelinux-release ->
mandriva-r                                                             
                              elease
lrwxrwxrwx 1 root root  16 oct  7 17:32 /etc/mandrake-release ->
mandriva-releas                                                        
                                   e
-rw-r--r-- 1 root root  50 avr  2  2007 /etc/mandriva-release
lrwxrwxrwx 1 root root  16 oct  7 17:32 /etc/redhat-release ->
mandriva-release

Therefore, the result for platform.distrib()[0] could be mandriva,
mandrake, redhat or even lsb. The first match wins !

Ignoring symlinks could remove part of the problem. On Mandriva, it
would leave only lsb-release and mandriva-release. It is possible to
select the good one by ignoring lsb-release or by verifying the file's
content (mandriva-release has one line and lsb-release has several
lines). I do not know if the second method is portable.
msg56712 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-10-24 18:18
Do you have a patch? That would help tremendously.
msg56747 - (view) Author: Raghuram Devarakonda (draghuram) (Python triager) Date: 2007-10-25 14:31
I think it is safe to ignore lsb-release. In fact, there seems to be a
command "lsb_release" that gives information about distribution. On my
SuSE box, this is what I get:

marvin:~# lsb_release -i
Distributor ID: SUSE LINUX
marvin:~# lsb_release -d
Description:    SUSE LINUX 10.1 (i586)
marvin:~# lsb_release -r
Release:        10.1

sapetnioc, can you check if this command exists on your system and if
so, it's output? platform.dist() can check for this command's existence
and if present, can perhaps use it to glean distro information. Please
let me know if you want to write the patch. I will do it otherwise.
msg56748 - (view) Author: Yann Cointepas (sapetnioc) Date: 2007-10-25 16:29
I can easily do the patch to ignore symlinks and /etc/lsb-release but I am
not sure of the appropriate way to look for lsb_update command, is
distutils.spawn.find_executable( 'lsb_release' ) ok ?
If you need the patch earlier than begining of next week, you should do it.
Otherwise I can make it.

On Mandriva 2007.1, the command exists if the package "lsb-release" is
installed. I do not know if it is always installed (I selected a checkbox
"LSB" during install, this checkbox is unchecked by default).
The output is:

[yann@localhost ~]$ lsb_release -a
LSB Version:
lsb-3.1-ia32:lsb-3.1-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:cxx-3.0-ia32:cxx-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:lsb-3.0-ia32:lsb-3.0-noarch:qt4-3.1-ia32:qt4-3.1-noarch
Distributor ID: MandrivaLinux
Description:    Mandriva Linux
Release:        2007.1
Codename:       Official

[yann@localhost ~]$ lsb_release -i
Distributor ID: MandrivaLinux

[yann@localhost ~]$ lsb_release -d
Description:    Mandriva Linux

[yann@localhost ~]$ lsb_release -r
Release:        2007.1

On Fedora 4 (rather old) , the command is in the package "redhat-lsb".

yc176684:src$ lsb_release -a
LSB Version:    1.3
Distributor ID: FedoraCore
Description:    Fedora Core release 4 (Stentz)
Release:        4
Codename:       Stentz

yc176684:src$ lsb_release -i
Distributor ID: FedoraCore

yc176684:src$ lsb_release -d
Description:    Fedora Core release 4 (Stentz)

yc176684:src$ lsb_release -r
Release:        4

On Fedora 7, the command is in the package "redhat-lsb" and seem to be
installed by default.

gargamel:riviere% lsb_release -a
LSB
Version:    :core-3.1-ia32:core-3.1-noarch:
graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: Fedora
Description:    Fedora release 7 (Moonshine)
Release:        7
Codename:       Moonshine

gargamel:riviere% lsb_release -i
Distributor ID: Fedora

gargamel:riviere% lsb_release -d
Description:    Fedora release 7 (Moonshine)

gargamel:riviere% lsb_release -r
Release:        7

On 10/25/07, Raghuram Devarakonda < report@bugs.python.org> wrote:
>
>
> Raghuram Devarakonda added the comment:
>
> I think it is safe to ignore lsb-release. In fact, there seems to be a
> command "lsb_release" that gives information about distribution. On my
> SuSE box, this is what I get:
>
> marvin:~# lsb_release -i
> Distributor ID: SUSE LINUX
> marvin:~# lsb_release -d
> Description:    SUSE LINUX 10.1 (i586)
> marvin:~# lsb_release -r
> Release:        10.1
>
> sapetnioc, can you check if this command exists on your system and if
> so, it's output? platform.dist() can check for this command's existence
> and if present, can perhaps use it to glean distro information. Please
> let me know if you want to write the patch. I will do it otherwise.
>
> ----------
> nosy: +draghuram
>
> __________________________________
> Tracker <report@bugs.python.org >
> <http://bugs.python.org/issue1322 >
> __________________________________
>
msg56749 - (view) Author: Raghuram Devarakonda (draghuram) (Python triager) Date: 2007-10-25 16:46
On 10/25/07, Yann Cointepas <report@bugs.python.org> wrote:
> I can easily do the patch to ignore symlinks and /etc/lsb-release but I am
> not sure of the appropriate way to look for lsb_update command, is
> distutils.spawn.find_executable( 'lsb_release' ) ok ?

You can just execute the command and if there is any error, default to
the current code. There is no need to explicitly check for the
binary's existence.

> If you need the patch earlier than begining of next week, you should do it.
> Otherwise I can make it.

I don't "need" the patch :-). If you can't get to it some time next
week, I will try to come up with the patch.

>
> On Mandriva 2007.1, the command exists if the package "lsb-release" is
> installed. I do not know if it is always installed (I selected a checkbox
> "LSB" during install, this checkbox is unchecked by default).
> The output is:
>
> [yann@localhost ~]$ lsb_release -a
> LSB Version:
> lsb-3.1-ia32:lsb-3.1-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:cxx-3.0-ia32:cxx-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:lsb-3.0-ia32:lsb-3.0-noarch:qt4-3.1-ia32:qt4-3.1-noarch
> Distributor ID: MandrivaLinux
> Description:    Mandriva Linux
> Release:        2007.1
> Codename:       Official
>
> [yann@localhost ~]$ lsb_release -i
> Distributor ID: MandrivaLinux
>
> [yann@localhost ~]$ lsb_release -d
> Description:    Mandriva Linux
>
> [yann@localhost ~]$ lsb_release -r
> Release:        2007.1
>
> On Fedora 4 (rather old) , the command is in the package "redhat-lsb".
>
> yc176684:src$ lsb_release -a
> LSB Version:    1.3
> Distributor ID: FedoraCore
> Description:    Fedora Core release 4 (Stentz)
> Release:        4
> Codename:       Stentz
>
> yc176684:src$ lsb_release -i
> Distributor ID: FedoraCore
>
> yc176684:src$ lsb_release -d
> Description:    Fedora Core release 4 (Stentz)
>
> yc176684:src$ lsb_release -r
> Release:        4
>
> On Fedora 7, the command is in the package "redhat-lsb" and seem to be
> installed by default.
>
> gargamel:riviere% lsb_release -a
> LSB
> Version:    :core-3.1-ia32:core-3.1-noarch:
> graphics-3.1-ia32:graphics-3.1-noarch
> Distributor ID: Fedora
> Description:    Fedora release 7 (Moonshine)
> Release:        7
> Codename:       Moonshine
>
> gargamel:riviere% lsb_release -i
> Distributor ID: Fedora
>
> gargamel:riviere% lsb_release -d
> Description:    Fedora release 7 (Moonshine)
>
> gargamel:riviere% lsb_release -r
> Release:        7
>
> On 10/25/07, Raghuram Devarakonda < report@bugs.python.org> wrote:
> >
> >
> > Raghuram Devarakonda added the comment:
> >
> > I think it is safe to ignore lsb-release. In fact, there seems to be a
> > command "lsb_release" that gives information about distribution. On my
> > SuSE box, this is what I get:
> >
> > marvin:~# lsb_release -i
> > Distributor ID: SUSE LINUX
> > marvin:~# lsb_release -d
> > Description:    SUSE LINUX 10.1 (i586)
> > marvin:~# lsb_release -r
> > Release:        10.1
> >
> > sapetnioc, can you check if this command exists on your system and if
> > so, it's output? platform.dist() can check for this command's existence
> > and if present, can perhaps use it to glean distro information. Please
> > let me know if you want to write the patch. I will do it otherwise.
> >
> > ----------
> > nosy: +draghuram
> >
> > __________________________________
> > Tracker <report@bugs.python.org >
> > <http://bugs.python.org/issue1322 >
> > __________________________________
> >
>
> Added file: http://bugs.python.org/file8609/unnamed
>
> __________________________________
> Tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1322>
> __________________________________
>
msg56773 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-10-26 03:08
Ony my Ubuntu box lsb_release is just a small Python script that parses
/etc/lsb-release. I suggest that your read the LSB standards about the
file and use the information to parse it instead of invoking a program.
msg56774 - (view) Author: Raghuram Devarakonda (draghuram) (Python triager) Date: 2007-10-26 03:33
> Ony my Ubuntu box lsb_release is just a small Python script that parses
> /etc/lsb-release. I suggest that your read the LSB standards about the
> file and use the information to parse it instead of invoking a program.

Can you please check if it supports all the options mentioned
previously in the bug report? I agree that reading from a file is
preferable to running a command, if issues OP mentioned can be
addressed.
msg56775 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-10-26 03:43
heimes@seneca:~$ /usr/bin/lsb_release -a
LSB Version:   
core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-2.0-ia32:core-3.0-ia32:core-3.1-ia32:cxx-2.0-noarch:cxx-3.0-noarch:cxx-3.1-noarch:cxx-2.0-ia32:cxx-3.0-ia32:cxx-3.1-ia32:graphics-2.0-noarch:graphics-3.0-noarch:graphics-3.1-noarch:graphics-2.0-ia32:graphics-3.0-ia32:graphics-3.1-ia32:desktop-3.1-noarch:desktop-3.1-ia32
Distributor ID: Ubuntu
Description:    Ubuntu 7.10
Release:        7.10
Codename:       gutsy
heimes@seneca:~$ /usr/bin/lsb_release -i
Distributor ID: Ubuntu
heimes@seneca:~$ /usr/bin/lsb_release -d
Description:    Ubuntu 7.10
heimes@seneca:~$ /usr/bin/lsb_release -c
Codename:       gutsy
heimes@seneca:~$ /usr/bin/lsb_release -r
Release:        7.10

Please read http://linux.die.net/man/1/lsb_release. It explains the
content of /etc/*-release in detail.
msg56784 - (view) Author: Yann Cointepas (sapetnioc) Date: 2007-10-26 11:39
I am writing a patch but I have a few questions:

1) There are at most three places where the distribution name can be
found. What is the priority order to select only one name ?
The three places are:
  a) Inside the /etc/lsb-release file
  b) In the name of the /etc/<distrib>-release file
  c) In the content of the /etc/<distrib>-release file
For instance, on Mandriva 2007.1 the possible names are:
  a) 'MandrivaLinux'
  b) 'mandriva'
  c) 'Mandriva Linux'
I would suggest to put a) first to be compatible with LSB
but on most systems it would change the value returned by
platform.dist after the patch (is it a problem ?).
I would have liked to use c) as second choice but this space
in the name set by Mandriva could be a problem (It's possible
to suppress spaces in the result though).

2) Can I remove supported_dists parameter of platform.dist ?
There could be a list of supported distributions but why
as a parameter of this function ?
msg56785 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-10-26 11:45
> I am writing a patch but I have a few questions:
> 
> 1) There are at most three places where the distribution name can be
> found. What is the priority order to select only one name ?
> The three places are:
>   a) Inside the /etc/lsb-release file
>   b) In the name of the /etc/<distrib>-release file
>   c) In the content of the /etc/<distrib>-release file

As far as I remember the specs a /etc/*-release file has a higher
priority than /etc/lsb-release.

> 2) Can I remove supported_dists parameter of platform.dist ?
> There could be a list of supported distributions but why
> as a parameter of this function ?

I agree. A module global list is better than a list as a function argument.

Can you also use a global variable instead of "/etc"? Something like
ETC_DIR = "/etc" for example. It would allow you to ship samples from
several distribution and run unit tests against each.

Christian
msg56786 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-10-26 11:48
> Can you also use a global variable instead of "/etc"? Something like
> ETC_DIR = "/etc" for example. It would allow you to ship samples from
> several distribution and run unit tests against each.

I've attached the two relevant files from Ubuntu 7.10 Gutsy.
msg56958 - (view) Author: Yann Cointepas (sapetnioc) Date: 2007-10-30 10:49
I joined a modified version of platform.py. Here is a summary of the
modification:
- replaced '/etc' by global variable _etc_dir
- removed supported_dists parameter of dist()
- each element of dist() result is searched in the following places
  (the first value found is kept):
  1) First line of /etc/<distribname>-release
  2) Contents of /etc/lsb-release
  3) Extract <distribname> from /etc/<distribname>-release

I tested it on Mandriva 2007.1, Fedora 4 and on a faked /etc directory
containing the Ubuntu files send by tiran. Results are:
  Mandriva 2007.1: ('MandrivaLinux', '2007.1', 'Official')
  Fedora 4: ('FedoraCore', '4', 'Stentz')
  Faked Ubuntu: ('Ubuntu', '7.10', 'gutsy')
msg56959 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-10-30 12:03
Yann Cointepas wrote:
> I joined a modified version of platform.py. Here is a summary of the
> modification:
> - replaced '/etc' by global variable _etc_dir
> - removed supported_dists parameter of dist()
> - each element of dist() result is searched in the following places
>   (the first value found is kept):
>   1) First line of /etc/<distribname>-release
>   2) Contents of /etc/lsb-release
>   3) Extract <distribname> from /etc/<distribname>-release

Here is an updated patch against Python 2.5 (your file was based on
Python 2.5's platform.py, wasn't it?).

CHANGES:

 * Added unit tests
 * Add Lib/test/platform directory for unit tests
 * removed usage of string
 * minor cleanups

Now for the funny part. You have to port the patch to the svn trunk. The
file can't be altered in the 2.5 release cycle. The changes are too
great. Unfortunately the patch doesn't apply cleanly.

Please add more test data to the platform/ directory and test_platform.py

In order to build the trunk:
svn co http://svn.python.org/projects/python/trunk
cd trunk
./configure
make
patch -p0 < patchfile
./python Lib/test/test_platform.py
svn diff > patchfile

Christian
msg58350 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-12-10 15:41
I'm mentoring a task for GHOP which is going to fix the problem.
msg62764 - (view) Author: Pavel Vinogradov (pavel.vinogradov) * Date: 2008-02-23 16:22
I'm work on this issue in
GHOP(http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=216&can=1&colspec=ID%20Status%20ClaimedBy%20Due%20NeedsReview%20Summary)
I'm attach updated patch for python trunk. This patch fixes issue and
add additional test for some other Linux distributions.
msg62774 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-02-23 17:04
Thanks Pavel!
First I need confirmation from the GHOP project and Georg that you have
submitted the contributor form. Then I'm going to merge your patch.
msg62782 - (view) Author: Pavel Vinogradov (pavel.vinogradov) * Date: 2008-02-23 17:32
You can see confirmation from Georg on thread in GHOP:
http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=216&can=1&colspec=ID%20Status%20ClaimedBy%20Due%20NeedsReview%20Summary#c20

I can update patch for 3.0 (it don't applies now) if you are ready to
commit them.
msg66702 - (view) Author: Bruno Gomes (bgomes) Date: 2008-05-12 02:28
In this fix I removed the use of the file name in order to return the
distname. Now, only the file contents
is taken into account.

On Centos, the file name is the same as on Redhat, but its contents is
different:
$ cat /etc/redhat-release 
CentOS release 5 (Final)

Compare:

With test_platform_py26.diff:
Python 2.6a3+ (trunk:62996M, May 10 2008, 16:38:41) 
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.dist()
('redhat', '5', 'Final')
>>> 

With the new fix:
Python 2.6a3+ (trunk:62996M, May 10 2008, 16:38:41) 
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.dist()
('CentOS', '5', 'Final')
>>> 

I have tested this fix on Ubuntu, Centos5 and RHEL 5 and it works fine.
Ubuntu: ('Ubuntu', '8.04', 'hardy')
Fedora: ('fedora', '8', 'Werewolf')
msg67046 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-05-18 21:32
Christian was reviewing this for GHOP.
msg69186 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2008-07-03 09:43
Please see the top of platform.py:

#    This module is maintained by Marc-Andre Lemburg <mal@egenix.com>.
#    If you find problems, please submit bug reports/patches via the
#    Python SourceForge Project Page and assign them to "lemburg".
#
#    Note: Please keep this module compatible to Python 1.5.2.

I wonder why the ticket wasn't assigned to me.

Regarding the patch: 

 * the dist() function has been superseded by linux_distribution().

 * the supported_dists argument is a documented feature of
linux_distributions(), so should not be removed

 * the Windows name normalization should not be removed (it fixes a bug
in Vista)

 * the change from using string functions to using string methods breaks
1.5.2 compatibility (*)

 * the _ETC_DIR global just makes things harder to read and there's no
apparent need for it

(*) It's probably time to drop 1.5.2 compatibility and only keep the
module compatible to Python 2.1, so this is not much of an issue.

Overall, I think it's better to define a fixed search order for the
release files than to try to figure out and parse random release files
that happen to match the release file RE.

For that to work, it would help a lot if you could provide the file name
and contents of various platform release files.
msg69187 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2008-07-03 09:53
Also note that linux_distribution() will use the parsed distro name from
the release file per default (full_distribution_name=1), so the problem
described in the original ticket description should no longer be
relevant: all release files point to the same lsb-release file in the end.

I don't have access to Mandriva. Could you please let me know whether
the current SVN version of platform.py still exhibits the mentioned
problem ?

Thanks.
msg73652 - (view) Author: Zooko O'Whielacronx (zooko) Date: 2008-09-23 17:39
Please see also #3937 for a patch which first tries to parse
"/etc/lsb-release", then tries to execute "lsb_release", then falls back
to the old behavior of platform.dist().  (Note that parsing the file
named /etc/lsb-release is not guaranteed to work by the Linux Standard
Base spec, but that executing "lsb_release" is.  On the other hand, the
former currently seems to work on more Debian/Ubuntu installations than
the latter does, and invoking lsb_release in a subprocess takes
significantly more time.)

Please see the links to the Linux Standard Base specifications which I
posted in #3937.  (The specification was originally published in 2001,
so most of the Linux systems that future versions of Python will be
deployed on were developed long after that specification was written.)

My patch, in #3937, is against the python-release25-maint branch.  I
tested the patch locally and it worked, and then I wrote a patch for my
project -- allmydata.org "Tahoe" -- which does something similar:

http://allmydata.org/trac/tahoe/browser/src/allmydata/__init__.py?rev=2976

I committed that change to Tahoe, and it was automatically tested on
eleven different systems by our buildbot:

http://allmydata.org/buildbot/waterfall

The resulting distribution-identification can be seen in the logs of
those tests.  For any machine on the waterfall, click on the "test.log"
hyperlink and search in text for "tahoe versions:".  For example, here
is the one for our Debian etch machine -- "debian", "4.0":

http://allmydata.org/buildbot/builders/etch/builds/1205/steps/test/logs/test.log

here is the one for the Ubuntu dapper machine -- "Ubuntu", "6.06":

http://allmydata.org/buildbot/builders/dapper/builds/1773/steps/test/logs/test.log

and here is the result for my Ubuntu hardy workstation -- "Ubuntu", "8.04":

http://allmydata.org/buildbot/builders/zooko%20yukyuk%20hardy/builds/216/steps/test/logs/test.log
msg73656 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2008-09-23 19:19
Zooko, I think the main reason for the parser in platform.py to fail on
Ubuntu is that Ubuntu doesn't ship with a /etc/ubuntu-release file and
instead uses the optional override parameters in /etc/lsb-release to
setup the distribution values.

E.g. on my Ubuntu box it has these lines:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu 7.10"

I guess we'll need to add a special parser for lsb-release files which
then gets tried *after* having tried the /etc/<distro>-release files
(this is how the lsb_release command works as well) and overrides any
settings found in the <distro>-release file.

If that doesn't work either, the function will need to fallback to
_dist_try_harder().

There's no need to start a subprocess for running lsb_release. 

Please also note that the subprocess module is not available in Python
2.1, so it's not an option anyway (platform.py defines it's own popen()
helper which should be used instead).
msg73659 - (view) Author: Zooko O'Whielacronx (zooko) Date: 2008-09-23 19:38
Okay, per MAL's request over on #3937, I tried
platform.get_linux_distribution() on the current svn trunk (which I
assume is the version that is about to become python 2.6).  It gave the
same not-so-great answer as platform.dist() used to: ('debian',
'lenny/sid', '').  I then ported my patch to trunk (attached), and it
gave the answer I wanted: ('Ubuntu', '8.04', 'hardy').

Note that technique of parsing /etc/lsb-release or invoking lsb_release
is more standard and generic and easier to maintain than the current
technique of trying a series of specific file parses for specific
"supported" distributions.  For example, if some new Linux distribution
is invented, or if this is tried on a distribution that isn't in the
supported list (has anyone tried this on Foresight Linux yet?), then my
technique has a good chance of working on that distribution, where the
current technique has a higher chance of accidentally mis-identifying it
as some other distribution, for example the way that the current trunk
mis-identifies Ubuntu 8.04 as Debian lenny/sid.
msg73660 - (view) Author: Zooko O'Whielacronx (zooko) Date: 2008-09-23 19:49
MAL:  why do you say it is better to look for
/etc/$supportedplatform-release files first instead of looking for
/etc/lsb-release first?

I do not know if /etc/lsb-release is suitably generic -- I've tried it
only on a few platforms.  I do know that executing lsb_release is
suitably generic since it is standard, but I prefer not to try it first
since it imposes about half-a-second delay.
msg73662 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2008-09-23 20:05
On 2008-09-23 21:49, Zooko O'Whielacronx wrote:
> Zooko O'Whielacronx <zooko@zooko.com> added the comment:
> 
> MAL:  why do you say it is better to look for
> /etc/$supportedplatform-release files first instead of looking for
> /etc/lsb-release first?

Because that's exactly what lsb_release does as well. The data
in /etc/lsb-release can only override data already parsed from
the /etc/<distro>-release file.

> I do not know if /etc/lsb-release is suitably generic -- I've tried it
> only on a few platforms.  I do know that executing lsb_release is
> suitably generic since it is standard, but I prefer not to try it first
> since it imposes about half-a-second delay.

lsb_release is standard on LSB compliant Linuxes, but the much
older /etc/<distro>-release file approach is still valid and in
wide use.

E.g. on SuSE, /etc/lsb-release doesn't contain any usable
distribution information. On Fedora, that file doesn't exist at
all.

It's better to follow the approach taken by lsb_release and then
add calling lsb_release as one of the methods taken by
_dist_try_harder() (using platform.popen()) should the parsers
fail.

This avoids spawning a process in most cases.
msg73663 - (view) Author: Zooko O'Whielacronx (zooko) Date: 2008-09-23 20:19
> Because that's exactly what lsb_release does as well.

You must know something about common lsb_release implementations that I
don't.  As far as I saw in the LSB documentation, it is required to
print out information in a certain format, but how it is implemented is
totally up to the distribution in question.

You give examples of SuSE and Fedora as not having /etc/lsb-release
files, and I'm sure you are right, but I happen to know that both of
them have compliant lsb_release executables (and that they have had for
many releases).  So, the patch that I've submitted will definitely work
correctly for those two distributions, although it will pay the price of
having to spawn a subprocess and then wait for the lsb_release
executable to do its work (however it does it).

However, presumably your SuSE- and Fedora- specific techniques will give
correct answers on those platforms faster than the generic lsb_release
would.
msg73666 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2008-09-23 20:38
On 2008-09-23 22:19, Zooko O'Whielacronx wrote:
> Zooko O'Whielacronx <zooko@zooko.com> added the comment:
> 
>> Because that's exactly what lsb_release does as well.

I have to correct that: lsb_release will only look at the other
release files in case it doesn't already enough information from
the lsb-release file.

> You must know something about common lsb_release implementations that I
> don't.  As far as I saw in the LSB documentation, it is required to
> print out information in a certain format, but how it is implemented is
> totally up to the distribution in question.

Just do a "man lsb_release" or look at the lsb_release shell script.

> You give examples of SuSE and Fedora as not having /etc/lsb-release
> files,

Fedora doesn't have that file, so lsb_release has to read the results
from /etc/fedora-release. SuSE does, but doesn't override
the default set in /etc/SuSE-release.

> and I'm sure you are right, but I happen to know that both of
> them have compliant lsb_release executables (and that they have had for
> many releases).  So, the patch that I've submitted will definitely work
> correctly for those two distributions, although it will pay the price of
> having to spawn a subprocess and then wait for the lsb_release
> executable to do its work (however it does it).
> 
> However, presumably your SuSE- and Fedora- specific techniques will give
> correct answers on those platforms faster than the generic lsb_release
> would.

Yep and the same is true for all other _supported_dists. I always try
to avoid spawning external processes whenever I can.
msg73744 - (view) Author: Zooko O'Whielacronx (zooko) Date: 2008-09-24 18:23
Well, for what it is worth I've updated the custom "detect linux
distribution" code in Tahoe yet again.  The current version first tries
to parse /etc/lsb-version (fast, gives a good answer on Ubuntu, and
hopefully at least semi-standardized), then invokes platform.dist()
(fast, customized, but gives a bad answer on Ubuntu), and then if
platform.dist() returns an empty distribution or empty release (which
I'm not sure if that is even possible), it invokes lsb_release -a in a
subprocess (slow, totally standardized).

Here's the patch:

http://allmydata.org/trac/tahoe/changeset/2981

Running it on the Tahoe buildbot shows that we currently have the
followings kinds of buildslaves:

http://allmydata.org/buildbot/waterfall?show_events=true

Linux-Ubuntu_6.06-i686-32bit, Linux-Ubuntu_6.10-i686-32bit,
Linux-Ubuntu_7.10-i686-32bit, SunOS-5.11-i86pc-i386-32bit,
Linux-Ubuntu_7.04-i686-32bit, Linux-debian_4.0-i686-32bit,
Linux-Ubuntu_8.04-i686-32bit, Darwin-9.4.0-i386-32bit,
Linux-Ubuntu_8.04-x86_64-64bit, Windows-XP-5.1.2600-SP2,
CYGWIN_NT-5.1-1.5.25-0.156-4-2-i686-32bit-WindowsPE
msg74336 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2008-10-05 08:42
/etc/lsb-release is not yet specified by the lsb.

See
https://lists.linux-foundation.org/pipermail/lsb-discuss/2008-March/004842.html
https://lists.linux-foundation.org/pipermail/lsb-discuss/2008-March/004843.html
https://lists.linux-foundation.org/pipermail/lsb-discuss/2008-March/004845.html
msg83762 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2009-03-18 17:13
MAL, please can we add zooko's patch in some form? The current
implementation assumes an implementation, which doesn't exist on all
platforms, and just dividing linux distributions in "unsupported" and
"supported" seems to be odd.

You cite some URL's in platform.py:

 - http://linuxmafia.com/faq/Admin/release-files.html
 
   "Linux System Base-compliant systems should have a file called
   /etc/lsb_release, which may be in addition to a distribution-
   specific file."

   The standard doesn't say anything like this.

 - http://linux.die.net/man/1/lsb_release
   This is one implementation, not more. The current platform.py
   implementation seems to require this particular implementation.

The only relevant URL is missing in this file:
http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html
msg83765 - (view) Author: Zooko O'Whielacronx (zooko) Date: 2009-03-18 17:36
doko: thanks for your interest encouraging more formal and generic
solutions to this.


For what it is worth, the current version of my patch (used in Tahoe) is
here:

http://allmydata.org/trac/tahoe/browser/src/allmydata/__init__.py?rev=20081125155118-92b7f-f74fc964ebd9d3c59afde68b6688c56ce20cca39#L31

I had to add a special case for Arch Linux, which gets triggered after
the three main cases.  The cases currently are, in order:

1.  Parse /etc/lsb-release (fast, semi-de-facto-standard, generic,
hopefully a future de-jure-standard).
2.  Invoke the Python Standard Library's platform.dist() (pros: fast,
has lots of customized special cases for different linux distros, cons:
has lots of customized special cases for different linux distros, gives
bogus answers for Ubuntu and Arch Linux)
3.  Subprocess execute "lsb_release" (pros: a real de-jure-standard!
cons: slow, and is not actually a de-facto-standard since many important
Linux installations don't come by default with the package that provides
the de-jure-standard "lsb_release" executable, even though they do come
by default with the de-facto-semi-standard "/etc/lsb-release" file).
4.  Arch Linux
msg83860 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2009-03-20 12:42
On 2009-03-18 18:13, Matthias Klose wrote:
> Matthias Klose <doko@debian.org> added the comment:
> 
> MAL, please can we add zooko's patch in some form? The current
> implementation assumes an implementation, which doesn't exist on all
> platforms, and just dividing linux distributions in "unsupported" and
> "supported" seems to be odd.

I've already mentioned what needs to be done to make Zooko's patch
suitable for platform.py (see further up on this ticket discussion).

The patch still doesn't meet those requirement, so cannot be applied.

Furthermore, I would prefer that piping to lsb_release only be used
as fallback solution. This should not be the default mechanism.

Regarding the problems on Ubuntu: That's mainly due to the way Ubuntu
decided to use the LSB standard. Most other Linux platforms work
just fine with the existing platform.py parser.

In order to support Ubuntu as well, we'll have to parse the
DISTRIB_* "variables" in /etc/lsb-release.

> You cite some URL's in platform.py:
> 
>  - http://linuxmafia.com/faq/Admin/release-files.html
>  
>    "Linux System Base-compliant systems should have a file called
>    /etc/lsb_release, which may be in addition to a distribution-
>    specific file."
> 
>    The standard doesn't say anything like this.
> 
>  - http://linux.die.net/man/1/lsb_release
>    This is one implementation, not more. The current platform.py
>    implementation seems to require this particular implementation.
> 
> The only relevant URL is missing in this file:
> http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html

Thanks, I'll add that. Note that the link doesn't mention anything
about the file format of the /etc/lsb_release file or how it should
be parsed. That's why I added the other URLs.

BTW: Here's what "man lsb_release" says on OpenSUSE:

"""
       If the installation is LSB  compliant,  the  "/etc/lsb-release"  file
should  contain  the
       LSB_VERSION  field.   The  value of the field should be a colon separated
list of supported
       module versions indicating the LSB specification modules to which the
installation is  com‐
       pliant. If the installation is not compliant, the above field should not
be present.

       Optional  fields are DISTRIB_ID, DISTRIB_RELEASE, DISTRIB_CODENAME,
DISTRIB_DESCRIPTION and
       can be used to override information which is parsed from the
"/etc/distrib-release" file.

       If the "/etc/lsb-release.d" directory exists, it is searched for
filenames which are  taken
       as additional module-version strings to add to LSB_VERSION.

       The "/etc/distrib-release" file contains a description line which is
parsed to get informa‐
       tion (especially on currently non-LSB compliant systems).
"""

It is interesting to note that Ubuntu's /etc/lsb_release file does not
contain the LSB_VERSION field. That would suggest, that Ubuntu is not
LSB compliant.
msg83861 - (view) Author: Zooko O'Whielacronx (zooko) Date: 2009-03-20 13:48
I just read back through this ticket, but I didn't understand exactly
what MAL wanted to have different from what this Python function
currently does:

http://allmydata.org/trac/tahoe/browser/src/allmydata/__init__.py?rev=20081125155118-92b7f-f74fc964ebd9d3c59afde68b6688c56ce20cca39#L31

MAL, could you please restate the changes you want?

By the way I think there is some confusion about what is standardized by
LSB.  As far as I know this one page is the complete spec:
http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html
and it doesn't specify the existence of any file that we can parse.  So
the quote you mention: "Linux System Base-compliant systems should have
a file called /etc/lsb_release, which may be in addition to a
distribution-specific file." is just wrong.  More's the pity -- most
implementations use a file named /etc/lsb-release, and we can parse
that, and if we do it is much faster than executing the lsb_release
executable in a subprocess.  The slowness of invoking subprocess is why
I was forced to back off from my original patch of merely using only
what the LSB offers.

A second problem with relying on LSB is, as I've mentioned, that some
Linux distributions don't come (by default) with the de-facto-standard
"lsb_release" executable although they do come with an /etc/lsb-release
file.

That's why my current strategy is:

1.  Parse the de-facto-nearly-standard /etc/lsb-release file.

2.  Ad-hoc techniques encoded into the Python Standard Library's
platform.dist().

3.  Execute the de-jure-standard "lsb_release" in a subprocess.

4.  Arch Linux
msg134157 - (view) Author: Pola (pola) Date: 2011-04-20 15:03
Has there been any progress on incorporating the suggested here patch?  

A suggested patch is found here also:

http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=216


And a patch is applied to python in ubuntu packages:
see reference - https://bugs.launchpad.net/python/+bug/196526

But the original platform still doesn't support this and it can't be counted on. 
Will the patch given by zooko be applied? If not, what is missing in it?
msg134193 - (view) Author: Zooko O'Whielacronx (zooko) Date: 2011-04-21 03:55
For what it is worth, here is the current version of this code that we are using in Tahoe-LAFS:

http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/__init__.py?annotate=blame&rev=5033#L36

You can see the results on our buildbot:

http://tahoe-lafs.org/buildbot/waterfall?show_events=false

In the tahoe-version build step, e.g.:

http://tahoe-lafs.org/buildbot/builders/Eugen%20lenny-amd64/builds/820/steps/tahoe-version/logs/stdio

Which says:

platform: Linux-debian_5.0.6-x86_64-64bit
msg134219 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-04-21 15:15
[Zooko]
> I just read back through this ticket, but I didn't understand exactly
> what MAL wanted to have different from what this Python function
> currently does:

It may be this:

> It's better to follow the approach taken by lsb_release and then
> add calling lsb_release as one of the methods taken by
> _dist_try_harder() (using platform.popen()) should the parsers
> fail.
> This avoids spawning a process in most cases.
msg134255 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2011-04-21 22:02
Éric Araujo wrote:
> 
> Éric Araujo <merwok@netwok.org> added the comment:
> 
> [Zooko]
>> I just read back through this ticket, but I didn't understand exactly
>> what MAL wanted to have different from what this Python function
>> currently does:
> 
> It may be this:
> 
>> It's better to follow the approach taken by lsb_release and then
>> add calling lsb_release as one of the methods taken by
>> _dist_try_harder() (using platform.popen()) should the parsers
>> fail.
>> This avoids spawning a process in most cases.

Indeed.

You also need to make sure that the function doesn't suddenly
return different output for setups that are supported and work
as advertised.

Note that the Debian mention in the string output is not really
incorrect, given that Ubuntu and other distros are based on the
work done by the Debian project.

Looking back, I shouldn't have added the function to begin
with and just use "Linux" in the platform string. It's causing
too much maintenance overhead.
Perhaps deprecating it altogether is more appropriate.
msg134269 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-04-22 16:37
The hard part was supporting distro-specific release files; I think that now most of them provide the lsb_release info.  If it proves more complicated than that, then let’s deprecate the function.
msg134277 - (view) Author: Zooko O'Whielacronx (zooko) Date: 2011-04-22 18:49
There seems to be some mistake, re #msg134219 and #msg134255. The current version of may patch *does* avoid the cost of a subprocess in the common case. I described this new strategy in #msg73744 and as far as I know it satisfies all of MAL's earlier objection about that.

To recap, this code here: http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/__init__.py?annotate=blame&rev=5033#L36 does the following strategy:

1. Parse the /etc/lsb-release file. /etc/lsb-release is not part of the de jure standard, but it is a de facto standard that is available on many distributions. Parsing it is fast and gives the right answer on many distributions.

2. If that didn't work (which can happen on some distributions, including common ones when a certain optional "lsb base" package isn't installed), then invoke the current platform.dist() code. This is a lot of code, its code has to be changed before it can recognize any new distribution or a change in a distribution, and it gives answers on Ubuntu and Arch Linux which users say are the wrong answer, but it is fast and it gives the answer users want in most cases.

3. If that didn't work (which presumably only happens on distributions that the authors of platform.dist() didn't know about or didn't bother to support), then invoke the de jure standard executable "lsb_release". This works on any LSB-compliant system, but it costs a subprocess.

4. If that didn't work, check for /etc/arch-release to signal Arch Linux.
msg137281 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-05-30 14:21
FTR, doko applied this patch for Debian and Ubuntu: http://patch-tracker.debian.org/patch/series/view/python3.2/3.2.1~rc1-1/platform-lsbrelease.diff
msg137287 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-05-30 15:04
http://patch-tracker.debian.org/patch/series/view/python3.2/3.2.1~rc1-1/platform-lsbrelease.diff

This patch fails if "(?:DISTRIB_CODENAME\s*=)\s*(.*)" regex doesn't match (_u_id variable is not set).
msg207397 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2014-01-05 19:46
Victor, what should be returned if the code name is not set? None, empty string, or the description field of the lsb-release file?
msg207415 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2014-01-06 08:57
None of the linked patch URLs work anymore.

Could someone please upload a current patch to the ticket for review ?

As mentioned before, I don't believe that changing the function to first try the lsb-release will result in the same results as what the functions returns now (for the distributions where it gives correct results).

Furthermore, the file does not appear to be available on all major platforms. Only the lsb-release binary has become somewhat of a standard, so trying the file first, then the lsb-release binary will in most cases result in spawning a process. As example, on openSUSE 11.4, the lsb-release binary reads the /etc/SuSE-release file and then returns these results:

> lsb-release -a
LSB Version:    n/a
Distributor ID: SUSE LINUX
Description:    openSUSE 11.4 (x86_64)
Release:        11.4
Codename:       Celadon

Note that taking these results would result in platform.dist() to return ('SUSE LINUX', '11.4', 'x86_64') instead of the current ('SuSE', '11.4', 'x86_64').

Finally, I think after all these years, the whole concept of linux_distribution() has failed due to the distributions using too many different ways of describing themselves.

I'd be +1 on deprecating the functionality altogether and remove linux_distribution()/dist() in the long run. The functionality is better left to a package which can be updated more easily on PyPI.
msg207421 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2014-01-06 10:24
Another example on openSUSE 12.3:

# lsb-release -a
LSB Version:    n/a
Distributor ID: openSUSE project
Description:    openSUSE 12.3 (x86_64)
Release:        12.3
Codename:       Dartmouth

This would result in ('openSUSE project', '11.4', 'x86_64'). I don't think
such distribution name changes are useful in practice. The existing
linux_distribution() code always returns 'SuSE' for these (and likewise
for other distributions).
msg207422 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2014-01-06 10:26
sure, then please let's deprecate that for 3.4, and remove in 3.5.  /etc/os-release introduce the next set of different names.
msg207426 - (view) Author: Vajrasky Kok (vajrasky) * Date: 2014-01-06 10:53
Here is the patch to deprecate platform.dist and platform.linux_distribution.
msg207427 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2014-01-06 11:07
On 06.01.2014 11:53, Vajrasky Kok wrote:
> 
> Here is the patch to deprecate platform.dist and platform.linux_distribution.
> 
> ----------
> nosy: +vajrasky
> Added file: http://bugs.python.org/file33324/deprecate_platform_dist.patch

Thanks. I think we'll need to do this in three steps:

1. pending deprecation in 3.4
2. deprecation in 3.5
3. removal in 3.6

Please also add a note to these steps to the warning text and a deprecation
notice to the documentation.
msg207500 - (view) Author: Vajrasky Kok (vajrasky) * Date: 2014-01-07 03:01
Thanks for the review. Attached the patch to address Marc-Andre Lemburg's concern.
msg224903 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2014-08-06 04:49
Here's an updated patch (based on Vajrasky's patch, thanks!).

Changes:

- Updated deprecation schedule
  1. pending deprecation in 3.5
  2. deprecation in 3.6
  3. removal in 3.7
- Added tests
- Added a whatsnew entry
- Moved warnings import to dist() and linux_distribution() functions
- Used a deprecate-removed directive in the documentation (see also issue 22150)
- Fixed a stacklevel bug. With deprecate_platform_dist_v2.patch the output of platform.dist() was:

  >>> import platform as p
  >>> p.dist()
  /home/berker/projects/cpython/default/Lib/platform.py:373: PendingDeprecationWarning: The dist()/linux_distribution() function will be deprecated in Python 3.5 and removed in Python 3.6
    full_distribution_name=0)
  ('debian', 'wheezy/sid', '')

  With the current patch:

  >>> import platform as p
  >>> p.dist()
  __main__:1: PendingDeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5 and will be removed in Python 3.6
  ('debian', 'wheezy/sid', '')
msg228533 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2014-10-05 03:05
Marc-Andre, could you please take a look to the latest patch?
msg236794 - (view) Author: Andy Maier (andymaier) * Date: 2015-02-27 17:12
Do we really think that a package on pypi solves the problem better? The discussion only shows that it is more likely we end up with multiple different packages on pypi, instead of one that is commonly agreed.

I agree it is tough to get to an agreed upon approach, but having this in the Python base at least ensures that it is the one approach everybody uses.

The /etc/os-release format seems to be used more often now, so I'm wondering why we cannot come up with a reasonable approach that is backwards compatible, supports /etc/os-release, and (if still needed), also /etc/lsb-release and the lsb_release script.

Again: If we ever want to end up with just one package on pypi, that very discussion needs to happen.

It seems to me that if the approach should be compatible, then we cannot use the new generic files (lsb* and os-release) first. The currently implemented approach needs to be used first. Then the new generic files.
msg242751 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2015-05-08 08:55
Thanks, Berker, your patch looks fine.
msg243063 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2015-05-13 09:32
New changeset 9c606c573ec0 by Berker Peksag in branch 'default':
Issue #1322: platform.dist() and platform.linux_distribution() functions are now deprecated.
https://hg.python.org/cpython/rev/9c606c573ec0
msg243090 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2015-05-13 14:18
Issues #17762 and #9514 had patches to improve these functions. Time to close them?
msg243093 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2015-05-13 14:21
On 13.05.2015 16:18, Petr Viktorin wrote:
> 
> Issues #17762 and #9514 had patches to improve these functions. Time to close them?

Yes. I just did. Thanks for the reminder.
msg244109 - (view) Author: Dimitri John Ledkov (xnox) * Date: 2015-05-26 15:34
Why not change them to parse os-release files as defined by 

http://www.freedesktop.org/software/systemd/man/os-release.html

A lot of things use these functions to check what one is running on, despite the problems, and do different things at install time.

This deprecation and eventual removal, will result in a pypi module created with such functionality anyway, that everyone will try to pull in.... or falling that copying in.

Here in https://clearlinux.org team we have patches to switch these to parse /etc/os-release;/usr/lib/os-release files instead. Would you be open to deprecate parsing any other files but os-release going forward? As that is standard across all linux distributions for quite some time now.

Regards,

Dimitri.
Debian Developer, Ubuntu Core Developer, Clear Linux* Project Developer.
msg244110 - (view) Author: Dimitri John Ledkov (xnox) * Date: 2015-05-26 15:36
Note that things have changed in this space, since the issue was opened in 2007.
msg256016 - (view) Author: Nir Cohen (nir0s) Date: 2015-12-06 17:12
I have a premliminary implementation of it: https://github.com/nir0s/ld

Would love some help. It tries to use adhere to the standards (os-release first, lsb-release later, then, distro-specific release files).

It also returns more types of values then there were before.
msg256017 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2015-12-06 17:15
this is not "fixable".  and now when parsing os-release you get different values then you got before, e.g. changing "Ubuntu" to "ubuntu".
msg256018 - (view) Author: Nir Cohen (nir0s) Date: 2015-12-06 17:28
I didn't mean to say that it was. Still, it's important to have some implementation of identifying linux distributions and their properties..
msg256026 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2015-12-06 19:49
> This deprecation and eventual removal, will result in a pypi module created with such functionality anyway, that everyone will try to pull in.... or falling that copying in.

That's the plan, right.

The stdlib is not the right place for things that change this often. Just look at how many semi standards we've seen in the last few years. There's no point in trying to follow these in a slow moving code base as the Python stdlib. It's much better to put the functionality into a PyPI module which can be updated much more frequently.

Perhaps you could upload your code to PyPI and then reference it here for people to find ?!

Thanks.
msg256027 - (view) Author: Nir Cohen (nir0s) Date: 2015-12-06 19:58
Apologies.

This can be simply installed by running `pip install ld` (from https://pypi.python.org/pypi/ld).

Some notes:

* I've just now started writing tests
* Haven't tested on versions other than 2.7.x and 2.6.x
* There's some stray code there. This works.. but it's obviously WIP.
* I'm all into getting as many pull requests to make this as robust as possible as fast as possible.
msg256111 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2015-12-08 10:27
We should probably delete the "will be removed in Python 3.7" part from the deprecation message to make porting from Python 2 easier. For example, we will add inspect.getargspec() back in 3.6. See issue 25486.
msg256333 - (view) Author: Nir Cohen (nir0s) Date: 2015-12-13 20:22
I would love some comments (and PRs, of course) on ld. Wanna make it as robust as possible.
msg256702 - (view) Author: Andy Maier (andymaier) * Date: 2015-12-18 19:36
Nir, 
I appreciate very much what you are doing. I was about to do the same ;-)

I'll review your code shortly. I like the idea to use /etc/os-release, as it has the most complete information. Stay tuned.
Andy

Am 6. Dezember 2015 18:12:52 MEZ, schrieb Nir Cohen <report@bugs.python.org>:
>
>Nir Cohen added the comment:
>
>I have a premliminary implementation of it: https://github.com/nir0s/ld
>
>Would love some help. It tries to use adhere to the standards
>(os-release first, lsb-release later, then, distro-specific release
>files).
>
>It also returns more types of values then there were before.
>
>----------
>nosy: +nir0s
>
>_______________________________________
>Python tracker <report@bugs.python.org>
><http://bugs.python.org/issue1322>
>_______________________________________
msg263312 - (view) Author: leycec (leycec) Date: 2016-04-13 07:35
Deprecating platform.linux_distribution() while retaining platform.win32_ver() and platform.mac_ver() is non-orthogonal, unjustifiable, and (arguably) discriminatory.

Platform version detection is no more a moving target under Linux than under Windows or OS X -- possibly less so, given the numerous significant revisions to platform.win32_ver() implementations over the dreary years. If Linux is arbitrarily unentitled to platform-specific lookup functions, then other platforms deserve the same.

Unlike both Windows and OS X, the overwhelming majority of Linux distributions provide a trivially parsable plaintext file publishing high-level platform metadata in "="-delimited shell variable assignment format: the systemd-mandated and freedesktop.org-maintained "/etc/os-release" file. Under edge-case Linux distributions ideologically rejecting this standard (e.g., Gentoo Linux), a subset of the named tuple returned by platform.uname() is trivially returnable.

Do not parse multiple possibly conflicting files, commands, or standards. Doing so is neither necessary nor desirable. If "/etc/os-release" exists, parse that; else, fallback to platform.uname(). Done. Fait accompli. Quite simple. No moving target exists.

A robust platform.linux_distribution() implementation adhering to this scheme is implementable in less than 50 lines of code -- possibly less than 20, assuming aggressive cleverness. How? If "/etc/os-release" exists, this file is guaranteed to be POSIX shell-compatible and hence Pythonically parsable via the stdlib shlex.shlex() function. (In brief: iteratively search for tokens containing "=", split these tokens on "=", ignore irrelevant variable names, and retain the remainder. That's it.) The fallback alternative is even briefer.

Removing core functionality invites third-party API explosion. This is the height of irresponsibility. Brace for heavyweight dependencies, end-user confusion, multiple competing non-standards, and poorly selected PyPi names conflicting with the long-standing GNU toolchain. (See nir0s' "ld", also referred to as "What was nir0s thinking?")

None of these are good things. Given the unremarkable simplicity of implementing this function correctly, this cul-de-sac of Cthulhian insanity needn't have happened in the first place.

It did. Now we languish.
msg263313 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2016-04-13 07:51
The idea is to have similar functionality implemented as a PyPI
package, which can be updated more often than the stdlib.

Unlike Windows and Mac OS X, the approach to finding out
the distribution version is changing too often on Linux (w/r to how
Python release cycles work). The problem is not complexity, it's
maintainability.

If you're confident that you can write the one and only implementation,
feel free to do so. Put it on PyPI and we can point people to it
once it has picked up a reasonable following we can point to it
in the documentation.

PS: I agree that the package name "ld" is not very intuitive. Perhaps
Nir could change it to something more easily recognizable, such as
"linux_distribution" :-)

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com
msg263724 - (view) Author: Andy Maier (andymaier) * Date: 2016-04-19 10:07
Nir currently proposes to change the package name from "ld" to "dist". See https://github.com/nir0s/ld/issues/103
Comments on this name change proposal are welcome (over there).

On "Given the unremarkable simplicity of implementing this function correctly ...":

It seems to me that this is over-simplifying the task somewhat. Nir's "ld" package needs to understand all of the (currently) three different formats on Linux, and goes for a precedence-based approach to consolidate the information. Also, determining supposedly simple things like a reliable distro ID, or a precise distro version is not trivial, given that some Linux distros provide their data quite inconsistently between the different data sources and sometimes change things like distro ID incompatibly in a new minor release.

Overall, I can only encourage people to try out the "ld" package (v0.5.0 is currently on PyPI) and give feedback (on its GitHub project).

Does the deprecation and removal of these functions discriminate Linux compared to Windows and OS-X? Maybe, but I'm pragmatic here, and for me the important criteria is the one that was stated from the beginning in this discussion: The higher change rate in Linux fits quite well with the approach of having a separate package that is not part of the standard Python.

Does that mean that less batteries are now included in Python out of the box: Yes, a very small part of the batteries is now no longer included. But maybe one day when the "ld" package is perfect and does not require a high change rate anymore, it gets added to standard Python.

Also, there are many packages the average Python project needs these days that are no longer coming with standard Python (six, setuptools, pbr, better unit testers, lxml, M2Crypto, Sphinx, lxml, ........). If you look at the long backlog of pull requests and open issues in standard Python, it is a good thing actually, not to overload the community maintaining the standard Python even further. But that is a bit off-topic for this issue, I am just mentioning it in order to beg for acceptance for the approach taken for linux distro information.
msg263725 - (view) Author: Andy Maier (andymaier) * Date: 2016-04-19 10:15
@leycec: By the way, the "ld" package *does* use shlex.shlex() to parse the os-release file.
msg263896 - (view) Author: Andy Maier (andymaier) * Date: 2016-04-21 08:35
Just for completeness:

The "ld" package is now called "distro" and its v0.6.0 is on PyPI: https://pypi.python.org/pypi/distro
msg299869 - (view) Author: Shane Harvey (ShaneHarvey) * Date: 2017-08-07 20:52
When are these functions going to be deprecated? In 3.5, 3.6, and master they still raise PendingDeprecationWarning, not DeprecationWarning:
https://github.com/python/cpython/blob/v3.5.3/Lib/platform.py#L305-L306
https://github.com/python/cpython/blob/v3.6.2/Lib/platform.py#L304-L305
https://github.com/python/cpython/blob/5c4b0d0/Lib/platform.py#L304-L305
msg316660 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-05-15 14:32
I talked to Ned, the release manager for 3.7.
It's too late to remove this in 3.7, so I'll update the docs and make the deprecation notice more current/useful, and link to the distro library.
msg316696 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-05-15 19:00
Marc-Andre, if you agree the function can be removed in 3.8.
This is tracked in https://bugs.python.org/issue28167
msg316876 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-05-16 23:46
For the record, I opened an issue on `distro` about the vicious circle of distro detection instead of feature detection: https://github.com/nir0s/distro/issues/221
History
Date User Action Args
2022-04-11 14:56:27adminsetgithub: 45663
2018-05-16 23:46:42petr.viktorinsetmessages: + msg316876
2018-05-15 19:00:02petr.viktorinsetmessages: + msg316696
2018-05-15 14:32:57petr.viktorinsetmessages: + msg316660
2018-05-02 14:33:04mbussonnsetpull_requests: + pull_request6387
2018-03-05 12:14:20mceplsetnosy: + mcepl
2017-08-07 20:52:48ShaneHarveysetnosy: + ShaneHarvey
messages: + msg299869
2016-04-21 08:35:51andymaiersetmessages: + msg263896
2016-04-19 10:15:02andymaiersetmessages: + msg263725
2016-04-19 10:07:04andymaiersetmessages: + msg263724
2016-04-13 07:51:07lemburgsetmessages: + msg263313
2016-04-13 07:35:51leycecsetnosy: + leycec
messages: + msg263312
2015-12-18 19:36:33andymaiersetmessages: + msg256702
2015-12-13 20:59:53vstinnersetnosy: - vstinner
2015-12-13 20:22:08nir0ssetmessages: + msg256333
2015-12-08 10:27:25berker.peksagsetmessages: + msg256111
2015-12-06 19:58:20nir0ssetmessages: + msg256027
2015-12-06 19:49:25lemburgsetmessages: + msg256026
2015-12-06 17:28:25nir0ssetmessages: + msg256018
2015-12-06 17:15:39dokosetmessages: + msg256017
2015-12-06 17:12:52nir0ssetnosy: + nir0s
messages: + msg256016
2015-05-26 15:36:05xnoxsetmessages: + msg244110
2015-05-26 15:34:54xnoxsetnosy: + xnox
messages: + msg244109
2015-05-13 14:21:42lemburgsetmessages: + msg243093
2015-05-13 14:18:38petr.viktorinsetmessages: + msg243090
2015-05-13 09:33:20berker.peksagsetstatus: open -> closed
resolution: fixed
stage: commit review -> resolved
2015-05-13 09:32:06python-devsetnosy: + python-dev
messages: + msg243063
2015-05-12 13:27:49berker.peksagsetassignee: lemburg -> berker.peksag
stage: patch review -> commit review
2015-05-12 13:10:54petr.viktorinsetnosy: + petr.viktorin
2015-05-08 08:55:59lemburgsetmessages: + msg242751
2015-02-27 17:12:33andymaiersetmessages: + msg236794
2015-02-27 17:05:47andymaiersetnosy: + andymaier
2014-10-05 03:05:36berker.peksagsettitle: platform.dist() has unpredictable result under Linux -> Deprecate platform.dist() and platform.linux_distribution() functions
messages: + msg228533

components: - Tests
keywords: + needs review
type: behavior -> enhancement
2014-08-06 04:49:22berker.peksagsetfiles: + issue1322.diff
versions: + Python 3.5, - Python 2.7, Python 3.2, Python 3.3
nosy: + berker.peksag

messages: + msg224903

stage: patch review
2014-01-07 03:01:31vajraskysetfiles: + deprecate_platform_dist_v2.patch

messages: + msg207500
2014-01-06 11:07:49lemburgsetmessages: + msg207427
2014-01-06 10:53:01vajraskysetfiles: + deprecate_platform_dist.patch
nosy: + vajrasky
messages: + msg207426

2014-01-06 10:26:10dokosetmessages: + msg207422
2014-01-06 10:24:27lemburgsetmessages: + msg207421
2014-01-06 08:57:08lemburgsetmessages: + msg207415
2014-01-05 19:46:30dokosetmessages: + msg207397
2011-05-30 15:04:55vstinnersetnosy: + vstinner
messages: + msg137287
2011-05-30 14:21:49eric.araujosetmessages: + msg137281
versions: + Python 3.3, - Python 3.1
2011-04-22 18:49:57zookosetmessages: + msg134277
2011-04-22 16:37:35eric.araujosetmessages: + msg134269
2011-04-21 22:02:41lemburgsetmessages: + msg134255
2011-04-21 15:15:25eric.araujosetmessages: + msg134219
2011-04-21 03:55:37zookosetmessages: + msg134193
2011-04-20 15:03:59polasetnosy: + pola
messages: + msg134157
2010-09-18 14:15:09BreamoreBoysetversions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6, Python 3.0
2010-08-01 01:01:22eric.araujolinkissue3937 superseder
2010-08-01 01:01:22eric.araujounlinkissue3937 dependencies
2010-06-25 22:23:56eric.araujosetnosy: + eric.araujo
2010-06-25 22:21:49eric.araujosetfiles: - unnamed
2009-03-20 13:48:47zookosetmessages: + msg83861
2009-03-20 12:42:52lemburgsetmessages: + msg83860
2009-03-18 17:36:04zookosetmessages: + msg83765
2009-03-18 17:13:47dokosetnosy: lemburg, georg.brandl, doko, zooko, draghuram, christian.heimes, sapetnioc, benjamin.peterson, pavel.vinogradov, bgomes
2009-03-18 17:13:30dokosetmessages: + msg83762
2008-10-05 08:42:55dokosetnosy: + doko
messages: + msg74336
2008-09-24 18:23:18zookosetmessages: + msg73744
2008-09-23 20:38:52lemburgsetmessages: + msg73666
2008-09-23 20:19:10zookosetmessages: + msg73663
2008-09-23 20:05:23lemburgsetmessages: + msg73662
2008-09-23 19:49:04zookosetmessages: + msg73660
2008-09-23 19:39:01zookosetfiles: + dist.patch.txt
2008-09-23 19:38:20zookosetmessages: + msg73659
2008-09-23 19:19:23lemburgsetmessages: + msg73656
2008-09-23 17:39:44zookosetnosy: + zooko
messages: + msg73652
2008-09-23 17:36:38gregory.p.smithsetdependencies: + platform.dist(): detect Linux distribution version in a robust, standard way
2008-09-23 17:36:31gregory.p.smithlinkissue3937 dependencies
2008-07-03 09:53:02lemburgsetmessages: + msg69187
2008-07-03 09:43:32lemburgsetassignee: christian.heimes -> lemburg
messages: + msg69186
nosy: + lemburg
2008-05-18 21:32:06benjamin.petersonsetassignee: georg.brandl -> christian.heimes
messages: + msg67046
nosy: + benjamin.peterson
2008-05-12 02:29:02bgomessetfiles: + test_platform_py26_fix_centos.diff
nosy: + bgomes
messages: + msg66702
2008-02-23 17:32:47pavel.vinogradovsetmessages: + msg62782
2008-02-23 17:06:32christian.heimessetkeywords: + patch
assignee: christian.heimes -> georg.brandl
nosy: + georg.brandl
2008-02-23 17:04:41christian.heimessetmessages: + msg62774
2008-02-23 16:22:36pavel.vinogradovsetfiles: + test_platform_py26.diff
nosy: + pavel.vinogradov
messages: + msg62764
2007-12-10 15:41:22christian.heimessetpriority: normal
assignee: christian.heimes
messages: + msg58350
versions: + Python 3.0
2007-10-30 12:04:49christian.heimessetfiles: + platform_py25.patch
components: + Library (Lib), Tests
versions: + Python 2.6, - Python 2.5
2007-10-30 12:03:56christian.heimessetmessages: + msg56959
2007-10-30 10:49:34sapetniocsetfiles: + platform.py
messages: + msg56958
2007-10-26 11:48:51christian.heimessetfiles: + debian_version, lsb-release
messages: + msg56786
2007-10-26 11:45:56christian.heimessetmessages: + msg56785
2007-10-26 11:39:38sapetniocsetmessages: + msg56784
2007-10-26 03:43:43christian.heimessetmessages: + msg56775
2007-10-26 03:33:30draghuramsetmessages: + msg56774
2007-10-26 03:08:19christian.heimessetnosy: + christian.heimes
messages: + msg56773
2007-10-25 22:44:13gvanrossumsetnosy: - gvanrossum
2007-10-25 16:46:07draghuramsetmessages: + msg56749
2007-10-25 16:29:48sapetniocsetfiles: + unnamed
messages: + msg56748
2007-10-25 14:31:59draghuramsetnosy: + draghuram
messages: + msg56747
2007-10-24 18:18:05gvanrossumsetnosy: + gvanrossum
messages: + msg56712
2007-10-24 17:21:04sapetnioccreate