classification
Title: remove platform.linux_distribution()
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.8
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: berker.peksag, christian.heimes, doko, lemburg, lukasz.langa, mbussonn, ned.deily, petr.viktorin, rb, serhiy.storchaka, vstinner
Priority: normal Keywords: patch

Created on 2016-09-15 09:50 by doko, last changed 2018-11-29 02:14 by vstinner. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 6669 merged mbussonn, 2018-05-01 04:43
PR 6862 merged miss-islington, 2018-05-15 15:18
PR 6864 merged petr.viktorin, 2018-05-15 15:41
PR 6871 merged petr.viktorin, 2018-05-15 18:43
PR 10787 merged vstinner, 2018-11-29 01:51
Messages (26)
msg276541 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2016-09-15 09:50
platform.linux_distribution() was deprecated in 3.5, and should be removed.

Can't be kept up to date, see #18872, #19213, #20454, #1180267, plus uncounted issues closed as won't fix.

I'm surprised that #26041 removed the removal warnings again after such a long discussion.
msg276542 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-09-15 10:22
> platform.linux_distribution() was deprecated in 3.5, and should be removed.

Is it replaced with the distro package?

FYI I reported the issue to pip and it seems like pip now embeds and uses distro:

* https://github.com/pypa/pip/issues/3823
* https://github.com/pypa/pip/pull/3906
msg276543 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2016-09-15 10:30
I think the current consensus is to keep old APIs around to make porting from Python 2 easier. That's why I opened issue 26041.

See also msg256111 and "Deprecation policy PEP" proposed at https://mail.python.org/pipermail/python-committers/2016-January/003706.html

If Marc-Andre (platform module maintainer) and Ned give their +1s, I don't have a strong objection against the removal of the function.

Also, it looks like I forgot to remove deprecated-removed directive in 5d9f961edc30: https://docs.python.org/3.6/library/platform.html#platform.linux_distribution
msg285004 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-01-08 19:04
But platform.dist() can be removed. It was deprecated in 2.6.
msg285030 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-09 09:59
+1 to remove platform.linux_distribution().

Linux distributions are moving much faster than the Python stdlib, so using the distro module which is hosted on PyPI is much simpler. In 2017, it became very easy to have dependencies, pip became the de factor standard.
msg315983 - (view) Author: Matthias Bussonnier (mbussonn) * Date: 2018-05-01 04:32
In the docs it is marked as "going to be removed in 3.7", and emitting PendingDeprecationWarning. I supposed it should either be updated to change to 3.8 and switch PendingDeprecationWarning to DeprecationWarning, or be actually removed.
msg316055 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-05-02 08:50
IMHO it's now too late to remove it from Python 3.7.

Moreover, if the current warning is *PendingDeprecationWarning*, the warning must first become in Python N, to then remove the feature in Python N+1.

I'm ok to just change the warning and schedule a removal from Python 3.8.
msg316056 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2018-05-02 08:58
We still don't have a suitable replacement for the feature. Five years, Matthias suggested to add a parser for freedesktop's os-release file.
msg316065 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2018-05-02 10:17
there is https://pypi.org/project/distro/
msg316666 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-05-15 15:17
New changeset 9eb40bc38de83e6ad3fad1931bba1cd36ae88c24 by Petr Viktorin (Matthias Bussonnier) in branch 'master':
bpo-28167: bump platform.linux_distribution removal to 3.8 (GH-6669)
https://github.com/python/cpython/commit/9eb40bc38de83e6ad3fad1931bba1cd36ae88c24
msg316682 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-05-15 17:30
New changeset f4fdb619ddb5b00178c79c2b90adc45075b5f17d by Petr Viktorin (Miss Islington (bot)) in branch '3.7':
bpo-28167: bump platform.linux_distribution removal to 3.8 (GH-6669) (GH-6862)
https://github.com/python/cpython/commit/f4fdb619ddb5b00178c79c2b90adc45075b5f17d
msg316683 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-05-15 17:31
New changeset e618e96581a711f2bc4f9bbcff6069bea15f0177 by Petr Viktorin in branch '3.6':
bpo-28167: bump platform.linux_distribution removal to 3.8 (GH-6864)
https://github.com/python/cpython/commit/e618e96581a711f2bc4f9bbcff6069bea15f0177
msg316694 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-05-15 18:58
Marc-Andre, I opened a PR to remove platform.linux_distribution() in Python 3.8.
How do you feel about this?
msg316763 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2018-05-16 05:05
Adding Łukasz since he is the release manager of Python 3.8.
msg316769 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2018-05-16 06:27
Hi Petr, I'm fine with this. Maintaining the necessary logic Python is not really possible in the stdlib. It's better to have a PyPI module for this which can be updated much more easily.

Thanks.
msg316823 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-05-16 15:51
New changeset 8b94b41ab7b12f745dea744e8940631318816935 by Petr Viktorin in branch 'master':
bpo-28167: Remove platform.linux_distribution (GH-6871)
https://github.com/python/cpython/commit/8b94b41ab7b12f745dea744e8940631318816935
msg316824 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-05-16 15:54
platform.linux_distribution is removed from Python 3.8. Thanks for everyone involved!

If there are any complaints or other fallout you don't want to deal with, feel free to point people to me :)
msg316889 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-05-17 07:08
Can you please have a look at bpo-33513 which is for Python 2.7: "incorrect detection of information of some distributions python2"?
msg317176 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-05-20 15:05
Thanks for closing that one.
msg317283 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-05-22 13:41
FYI I created bpo-33600: "[EASY DOC] Python 2: document that platform.linux_distribution() has been removed".
msg327345 - (view) Author: (rb) Date: 2018-10-08 11:59
> Maintaining the necessary logic Python is not really possible in the stdlib. It's better to have a PyPI module for this which can be updated much more easily.

The /etc/os-release syntax is stable, the file is implemented nearly everywhere and is unlikely to change, so I don't see why it'll be difficult to maintain. Just parse and give us the key/value pairs, please!

It's disappointing to have to add Yet Another Dependency to get this functionality, contrary to Python's "batteries included" philosophy.
msg327347 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-10-08 12:11
In the recommended library, distro, real-world issues blew the code size up to 1000 lines of code and the open issue count to 15 – so while it's definitely useful, it doesn't seem either fully complete or trivial to maintain: https://github.com/nir0s/distro/blob/master/distro.py
If you can do better, please make a library to implement the simple name/value parsing, publish it on PyPI (sadly, as Yet Another Dependency at this point), make sure it's unit-tested, documented and widely useful in the real world, and *then* suggest inclusion in the standard library. That's how things get into the stdlib nowadays.

If that sounds like a lot of work, please consider your tone when asking others to do it.
msg327348 - (view) Author: (rb) Date: 2018-10-08 12:33
Apologies for my tone. I wasn't aware that starting out with a PyPI module is the only accepted process for getting functionality into stdlib. That certainly is a lot of work for what would be a trivial handful of lines to parse key/value pairs and handle error paths, etc (and corresponding tests of course).

As a distribution developer, from my perspective we've already (finally) managed to reach widespread standardization and unification on a simple key/value pair specification, so it is particularly surprising to me that as a Python developer I cannot easily get to it.

IMHO, forcing the PyPI route seems like a recipe for scope creep to me in this case. Looking at that module, it tries to do so much more. /etc/os-release is widely accepted nowadays, and I think it would be widely useful to the majority of users to simply pass the values through to a Python dictionary, reflecting "this is what the OS says it is" over "this is my promised stable view". Many of the issues there are because it's trying to be "clever", IMHO, rather than just passing through the provided information from the platform. My proposed API promise would simply be "this is what os-release says" or "os-release information not available".

Of course the most popular PyPI module to solve a particular problem will always be the one with the widest scope, so there seems little point in writing a parallel minimal one. The cost of adding Yet Another Dependency has to be paid in either case.
msg327349 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-10-08 12:58
> I wasn't aware that starting out with a PyPI module is the only accepted process for getting functionality into stdlib.

It's the main way things should get in. (Other ways exist, for example, dataclasses were added as simplification/merging of several existing libraries.)

> That certainly is a lot of work for what would be a trivial handful of lines to parse key/value pairs and handle error paths, etc (and corresponding tests of course).

Releasing on PyPI is trivial once you have the tests and documentation. I'll be glad to help with that.


> IMHO, forcing the PyPI route seems like a recipe for scope creep to me in this case.

Not necessarily. You just need to carefully define the scope of the PyPI module – same as you would for the stdlib module. There's not much difference between stdlib and PyPI here:
after all, I'd argue the main reason platform.linux_distribution() was removed is that its scope was too wide to be maintainable.

> The cost of adding Yet Another Dependency has to be paid in either case.

Indeed. But it will be hard to get in otherwise.

BTW, another way a PyPI release help is that the functionality would be useful for previous versions of Python. At this point new features are targetting Python 3.8.
So, even if this does get into stdlib, a backport on PyPI would still be useful. Consider prior art like:
https://pypi.org/project/dataclasses/
https://pypi.org/project/asyncio/
msg327350 - (view) Author: Petr Viktorin (petr.viktorin) * (Python committer) Date: 2018-10-08 13:07
Actually, the scope (right balance between usefulness and maintainability) is probably the hardest real problem to solve here.
PyPI lets you iterate on that. For a straight-to-stdlib module, you'd need to get it exactly right on the first time.
msg330660 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-11-29 02:14
New changeset 7cc1fa40b76de34a0fe86162667c87ce7a18f33d by Victor Stinner in branch 'master':
bpo-28167: Remove platform._dist_try_harder() (GH-10787)
https://github.com/python/cpython/commit/7cc1fa40b76de34a0fe86162667c87ce7a18f33d
History
Date User Action Args
2018-11-29 02:14:08vstinnersetmessages: + msg330660
2018-11-29 01:51:25vstinnersetpull_requests: + pull_request10031
2018-10-08 13:13:05yan12125setnosy: - yan12125
2018-10-08 13:07:16petr.viktorinsetmessages: + msg327350
2018-10-08 12:58:52petr.viktorinsetmessages: + msg327349
2018-10-08 12:33:10rbsetmessages: + msg327348
2018-10-08 12:11:49petr.viktorinsetmessages: + msg327347
2018-10-08 11:59:32rbsetnosy: + rb
messages: + msg327345
2018-05-22 13:41:10vstinnersetmessages: + msg317283
2018-05-20 15:05:48petr.viktorinsetmessages: + msg317176
2018-05-20 11:34:30berker.peksagsetpull_requests: - pull_request6650
2018-05-20 02:59:36mrandybusetpull_requests: + pull_request6650
2018-05-17 07:08:09vstinnersetmessages: + msg316889
2018-05-16 15:54:53petr.viktorinsetstatus: open -> closed
resolution: fixed
messages: + msg316824

stage: patch review -> resolved
2018-05-16 15:51:24petr.viktorinsetmessages: + msg316823
2018-05-16 06:27:56lemburgsetmessages: + msg316769
2018-05-16 05:05:11berker.peksagsetversions: + Python 3.8
nosy: + lukasz.langa

messages: + msg316763

components: + Library (Lib)
type: enhancement
2018-05-15 18:58:31petr.viktorinsetnosy: + lemburg
messages: + msg316694
2018-05-15 18:43:52petr.viktorinsetpull_requests: + pull_request6545
2018-05-15 17:31:51petr.viktorinsetmessages: + msg316683
2018-05-15 17:30:15petr.viktorinsetmessages: + msg316682
2018-05-15 15:41:26petr.viktorinsetpull_requests: + pull_request6538
2018-05-15 15:18:21miss-islingtonsetpull_requests: + pull_request6536
2018-05-15 15:17:02petr.viktorinsetnosy: + petr.viktorin
messages: + msg316666
2018-05-02 10:17:55dokosetmessages: + msg316065
2018-05-02 08:58:32christian.heimessetnosy: + christian.heimes
messages: + msg316056
2018-05-02 08:50:20vstinnersetmessages: + msg316055
2018-05-01 04:43:15mbussonnsetkeywords: + patch
stage: patch review
pull_requests: + pull_request6363
2018-05-01 04:32:56mbussonnsetnosy: + mbussonn
messages: + msg315983
2017-01-09 09:59:52vstinnersetmessages: + msg285030
2017-01-08 19:04:52serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg285004
2016-09-15 10:30:52berker.peksagsetmessages: + msg276543
2016-09-15 10:22:11vstinnersetnosy: + vstinner
messages: + msg276542
2016-09-15 10:04:33yan12125setnosy: + yan12125
2016-09-15 09:50:07dokocreate