platform.linux_distribution() was deprecated in 3.5, and should be removed.

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

I'm surprised that bpo-26041 removed the removal warnings again after such a long discussion.

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:

• pip should use the distro module: platform.linux_distribution() has been deprecated in Python 3.5 pypa/pip#3823
• Vendor distro==0.6.0 pypa/pip#3906

I think the current consensus is to keep old APIs around to make porting from Python 2 easier. That's why I opened bpo-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

But platform.dist() can be removed. It was deprecated in 2.6.

+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.

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.

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.

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.

there is https://pypi.org/project/distro/

New changeset 9eb40bc by Petr Viktorin (Matthias Bussonnier) in branch 'master':
bpo-28167: bump platform.linux_distribution removal to 3.8 (GH-6669)
9eb40bc

New changeset f4fdb61 by Petr Viktorin (Miss Islington (bot)) in branch '3.7':
bpo-28167: bump platform.linux_distribution removal to 3.8 (GH-6669) (GH-6862)
f4fdb61

New changeset e618e96 by Petr Viktorin in branch '3.6':
bpo-28167: bump platform.linux_distribution removal to 3.8 (GH-6864)
e618e96

Marc-Andre, I opened a PR to remove platform.linux_distribution() in Python 3.8.
How do you feel about this?

Adding Łukasz since he is the release manager of Python 3.8.

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.

New changeset 8b94b41 by Petr Viktorin in branch 'master':
bpo-28167: Remove platform.linux_distribution (GH-6871)
8b94b41

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 :)

Can you please have a look at bpo-33513 which is for Python 2.7: "incorrect detection of information of some distributions python2"?

Thanks for closing that one.

FYI I created bpo-33600: "[EASY DOC] Python 2: document that platform.linux_distribution() has been removed".

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.

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.

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.

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/

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.

New changeset 7cc1fa4 by Victor Stinner in branch 'master':
bpo-28167: Remove platform._dist_try_harder() (GH-10787)
7cc1fa4