[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Petr Viktorin]

Petr Viktorin  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Petr Viktorin]

Petr Viktorin  added the comment:

Marc-Andre, if you agree the function can be removed in 3.8.
This is tracked in https://bugs.python.org/issue28167

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Petr Viktorin]

Petr Viktorin  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Matthias Bussonnier]

Change by Matthias Bussonnier :


--
pull_requests: +6387

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Matej Cepl]

Change by Matej Cepl :


--
nosy: +mcepl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Shane Harvey]

Shane Harvey added the comment:

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

--
nosy: +ShaneHarvey

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Andy Maier]

Andy Maier added the comment:

Just for completeness:

The "ld" package is now called "distro" and its v0.6.0 is on PyPI: 
https://pypi.python.org/pypi/distro

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Andy Maier]

Andy Maier added the comment:

@leycec: By the way, the "ld" package *does* use shlex.shlex() to parse the 
os-release file.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Andy Maier]

Andy Maier added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[leycec]

leycec added the comment:

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.

--
nosy: +leycec

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Andy Maier]

Andy Maier added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Nir Cohen]

Nir Cohen added the comment:

I would love some comments (and PRs, of course) on ld. Wanna make it as robust 
as possible.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[STINNER Victor]

Changes by STINNER Victor :


--
nosy:  -haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Berker Peksag]

Berker Peksag added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Nir Cohen]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Matthias Klose]

Matthias Klose added the comment:

this is not "fixable".  and now when parsing os-release you get different 
values then you got before, e.g. changing "Ubuntu" to "ubuntu".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Nir Cohen]

Nir Cohen added the comment:

I didn't mean to say that it was. Still, it's important to have some 
implementation of identifying linux distributions and their properties..

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Nir Cohen]

Nir Cohen added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Dimitri John Ledkov]

Dimitri John Ledkov added the comment:

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.

--
nosy: +xnox

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1322
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Dimitri John Ledkov]

Dimitri John Ledkov added the comment:

Note that things have changed in this space, since the issue was opened in 2007.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1322
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Roundup Robot]

Roundup Robot added the comment:

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

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1322
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Berker Peksag]

Changes by Berker Peksag berker.pek...@gmail.com:


--
resolution:  - fixed
stage: commit review - resolved
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1322
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Petr Viktorin]

Petr Viktorin added the comment:

Issues #17762 and #9514 had patches to improve these functions. Time to close 
them?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1322
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1322
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Petr Viktorin]

Changes by Petr Viktorin encu...@gmail.com:


--
nosy: +encukou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1322
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Berker Peksag]

Changes by Berker Peksag berker.pek...@gmail.com:


--
assignee: lemburg - berker.peksag
stage: patch review - commit review

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1322
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

Thanks, Berker, your patch looks fine.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1322
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Andy Maier]

Andy Maier added the comment:

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1322
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Andy Maier]

Changes by Andy Maier andreas.r.ma...@gmx.de:


--
nosy: +andymaier

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1322
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

[Berker Peksag]

Berker Peksag added the comment:

Marc-Andre, could you please take a look to the latest patch?

--
components:  -Tests
keywords: +needs review
title: platform.dist() has unpredictable result under Linux - Deprecate 
platform.dist() and platform.linux_distribution() functions
type: behavior - enhancement

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1322
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com