Deprecate platform.dist() and platform.linux_distribution() functions #45663
Comments
|
The distribution name returned by platform.dist() depends on the order [login@localhost ~]$ ls -l /etc/*-release Therefore, the result for platform.distrib()[0] could be mandriva, Ignoring symlinks could remove part of the problem. On Mandriva, it |
|
Do you have a patch? That would help tremendously. |
|
I think it is safe to ignore lsb-release. In fact, there seems to be a marvin: sapetnioc, can you check if this command exists on your system and if |
|
I can easily do the patch to ignore symlinks and /etc/lsb-release but I am On Mandriva 2007.1, the command exists if the package "lsb-release" is [yann@localhost ~]$ lsb_release -a [yann@localhost ~]$ lsb_release -i [yann@localhost ~]$ lsb_release -d [yann@localhost ~]$ lsb_release -r On Fedora 4 (rather old) , the command is in the package "redhat-lsb". yc176684:src$ lsb_release -a yc176684:src$ lsb_release -i yc176684:src$ lsb_release -d yc176684:src$ lsb_release -r On Fedora 7, the command is in the package "redhat-lsb" and seem to be gargamel:riviere% lsb_release -a gargamel:riviere% lsb_release -i gargamel:riviere% lsb_release -d gargamel:riviere% lsb_release -r On 10/25/07, Raghuram Devarakonda < report@bugs.python.org> wrote:
|
|
On 10/25/07, Yann Cointepas <report@bugs.python.org> wrote:
You can just execute the command and if there is any error, default to
I don't "need" the patch :-). If you can't get to it some time next
|
|
Ony my Ubuntu box lsb_release is just a small Python script that parses |
Can you please check if it supports all the options mentioned |
|
heimes@seneca: Please read http://linux.die.net/man/1/lsb_release. It explains the |
|
I am writing a patch but I have a few questions:
|
As far as I remember the specs a /etc/*-release file has a higher
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 Christian |
I've attached the two relevant files from Ubuntu 7.10 Gutsy. |
|
I joined a modified version of platform.py. Here is a summary of the
I tested it on Mandriva 2007.1, Fedora 4 and on a faked /etc directory |
|
Yann Cointepas wrote:
Here is an updated patch against Python 2.5 (your file was based on CHANGES:
Now for the funny part. You have to port the patch to the svn trunk. The Please add more test data to the platform/ directory and test_platform.py In order to build the trunk: Christian |
tiran
added
stdlib
|
I'm mentoring a task for GHOP which is going to fix the problem. |
|
I'm work on this issue in |
|
Thanks Pavel! |
|
You can see confirmation from Georg on thread in GHOP: I can update patch for 3.0 (it don't applies now) if you are ready to |
|
In this fix I removed the use of the file name in order to return the On Centos, the file name is the same as on Redhat, but its contents is 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. |
|
Christian was reviewing this for GHOP. |
|
Please see the top of platform.py: # This module is maintained by Marc-Andre Lemburg <mal@egenix.com>. # Note: Please keep this module compatible to Python 1.5.2. I wonder why the ticket wasn't assigned to me. Regarding the patch:
(*) It's probably time to drop 1.5.2 compatibility and only keep the Overall, I think it's better to define a fixed search order for the For that to work, it would help a lot if you could provide the file name |
|
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. |
|
Thanks, Berker, your patch looks fine. |
|
New changeset 9c606c573ec0 by Berker Peksag in branch 'default': |
|
On 13.05.2015 16:18, Petr Viktorin wrote:
Yes. I just did. Thanks for the reminder. |
|
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. |
|
Note that things have changed in this space, since the issue was opened in 2007. |
|
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. |
|
this is not "fixable". and now when parsing os-release you get different values then you got before, e.g. changing "Ubuntu" to "ubuntu". |
|
I didn't mean to say that it was. Still, it's important to have some implementation of identifying linux distributions and their properties.. |
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. |
|
Apologies. This can be simply installed by running Some notes:
|
|
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 bpo-25486. |
|
I would love some comments (and PRs, of course) on ld. Wanna make it as robust as possible. |
|
Nir, I'll review your code shortly. I like the idea to use /etc/os-release, as it has the most complete information. Stay tuned. Am 6. Dezember 2015 18:12:52 MEZ, schrieb Nir Cohen <report@bugs.python.org>:
|
|
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. |
|
The idea is to have similar functionality implemented as a PyPI Unlike Windows and Mac OS X, the approach to finding out If you're confident that you can write the one and only implementation, PS: I agree that the package name "ld" is not very intuitive. Perhaps Thanks,Marc-Andre Lemburg |
|
Nir currently proposes to change the package name from "ld" to "dist". See python-distro/distro#103 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. |
|
@leycec: By the way, the "ld" package *does* use shlex.shlex() to parse the os-release file. |
|
Just for completeness: The "ld" package is now called "distro" and its v0.6.0 is on PyPI: https://pypi.python.org/pypi/distro |
|
When are these functions going to be deprecated? In 3.5, 3.6, and master they still raise PendingDeprecationWarning, not DeprecationWarning: |
|
I talked to Ned, the release manager for 3.7. |
|
Marc-Andre, if you agree the function can be removed in 3.8. |
|
For the record, I opened an issue on |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: