Message ID | 20200710101055.33671-1-louise.kilheeney@intel.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0319FA052A; Fri, 10 Jul 2020 12:11:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3F6AE1D6FF; Fri, 10 Jul 2020 12:11:02 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 57C7E1C1BB for <dev@dpdk.org>; Fri, 10 Jul 2020 12:11:01 +0200 (CEST) IronPort-SDR: f5bdNsuqpTIrB3W822h39fHKdO7xiDTlU8ld6llvsiWfUbmJnqvmU7C02+DD6G8nhlN2xb81LL bDDAcxYhUvHw== X-IronPort-AV: E=McAfee;i="6000,8403,9677"; a="136380934" X-IronPort-AV: E=Sophos;i="5.75,335,1589266800"; d="scan'208";a="136380934" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2020 03:11:00 -0700 IronPort-SDR: 4+YnNLSdMA7v751ATkTo8GN7azfyM16INEPnw9SGV7KBGOu4ZzGly7/f1RbgrNq/xsct9v5ltn HqgF/Zd1ElLw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,335,1589266800"; d="scan'208";a="298384564" Received: from silpixa00389033.ir.intel.com (HELO silpixa00389033.ger.corp.intel.com) ([10.237.223.171]) by orsmga002.jf.intel.com with ESMTP; 10 Jul 2020 03:10:59 -0700 From: Louise Kilheeney <louise.kilheeney@intel.com> To: dev@dpdk.org Cc: david.marchand@redhat.com, bruce.richardson@intel.com, Louise Kilheeney <louise.kilheeney@intel.com> Date: Fri, 10 Jul 2020 11:10:46 +0100 Message-Id: <20200710101055.33671-1-louise.kilheeney@intel.com> X-Mailer: git-send-email 2.17.1 Subject: [dpdk-dev] [PATCH 0/9] python2 deprecation notice X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
python2 deprecation notice
|
|
Message
Louise Kilheeney
July 10, 2020, 10:10 a.m. UTC
This patchset adds deprecation notices to python scripts, warning of the removal of python2 support from the DPDK 20.11 release. Louise Kilheeney (9): usertools/cpu_layout: add python2 deprecation notice usertools/dpdk-telemetry-client: python2 deprecation notice usertools/dpdk-devbind: add python2 deprecation notice devtools/update_version_map: add python2 deprecation notice app/test-cmdline: add python2 deprecation notice app/test: add python2 deprecation notice usertools/dpdk-pmdinfo: add python2 deprecation notice app/test-bbdev: python3 compatibility changes app/test-bbdev: add python2 deprecation notice app/test-bbdev/test-bbdev.py | 9 +++++++-- app/test-cmdline/cmdline_test.py | 3 +++ app/test/autotest.py | 4 ++++ devtools/update_version_map_abi.py | 4 ++++ usertools/cpu_layout.py | 4 ++++ usertools/dpdk-devbind.py | 4 ++++ usertools/dpdk-pmdinfo.py | 4 +++- usertools/dpdk-telemetry-client.py | 4 ++++ 8 files changed, 33 insertions(+), 3 deletions(-)
Comments
On Fri, Jul 10, 2020 at 11:10:46AM +0100, Louise Kilheeney wrote: > This patchset adds deprecation notices to python scripts, > warning of the removal of python2 support from the DPDK 20.11 release. > > Louise Kilheeney (9): > usertools/cpu_layout: add python2 deprecation notice > usertools/dpdk-telemetry-client: python2 deprecation notice > usertools/dpdk-devbind: add python2 deprecation notice > devtools/update_version_map: add python2 deprecation notice > app/test-cmdline: add python2 deprecation notice > app/test: add python2 deprecation notice > usertools/dpdk-pmdinfo: add python2 deprecation notice > app/test-bbdev: python3 compatibility changes > app/test-bbdev: add python2 deprecation notice > > app/test-bbdev/test-bbdev.py | 9 +++++++-- > app/test-cmdline/cmdline_test.py | 3 +++ > app/test/autotest.py | 4 ++++ > devtools/update_version_map_abi.py | 4 ++++ > usertools/cpu_layout.py | 4 ++++ > usertools/dpdk-devbind.py | 4 ++++ > usertools/dpdk-pmdinfo.py | 4 +++- > usertools/dpdk-telemetry-client.py | 4 ++++ > 8 files changed, 33 insertions(+), 3 deletions(-) > > -- Thanks for setting us up for Python 2 support removal. Series-acked-by: Bruce Richardson <bruce.richardson@intel.com>
Hi Louise, 2020-07-10, Louise Kilheeney: > This patchset adds deprecation notices to python scripts, > warning of the removal of python2 support from the DPDK 20.11 release. While showing warnings to users about Python 2 support drop in 20.11 is good, it seems like the shebangs in a lot of these scripts still refer to "python". dpdk$ git describe v20.05-623-geff30b59cc2e dpdk$ git grep '#.*!.*python\>' app/test-bbdev/test-bbdev.py:1:#!/usr/bin/env python app/test-cmdline/cmdline_test.py:1:#!/usr/bin/env python app/test/autotest.py:1:#!/usr/bin/env python buildtools/map_to_win.py:1:#!/usr/bin/env python config/arm/armv8_machine.py:1:#!/usr/bin/python devtools/update_version_map_abi.py:1:#!/usr/bin/env python usertools/cpu_layout.py:1:#!/usr/bin/env python usertools/dpdk-devbind.py:1:#! /usr/bin/env python usertools/dpdk-pmdinfo.py:1:#!/usr/bin/env python usertools/dpdk-telemetry-client.py:1:#! /usr/bin/env python On many distros, "python" still points (as of today) to python2. You series will cause warnings that cannot be avoided. Also, on some distros, "python" does not exist at all (RHEL 8 and CentOS 8 for example). And only "python2" or "python3" are available. I wonder if it would not be better to find a way to make these shebangs "dynamic" somehow. It is not trivial and I don't see any other solution than plain modification of the shebangs at build time. However, there is no way (to my knowledge) to specify which version of python is "selected" during the build. Does anyone have a proper solution?
On Fri, Jul 10, 2020 at 03:33:58PM +0200, Robin Jarry wrote: > Hi Louise, > > 2020-07-10, Louise Kilheeney: > > This patchset adds deprecation notices to python scripts, > > warning of the removal of python2 support from the DPDK 20.11 release. > > While showing warnings to users about Python 2 support drop in 20.11 is > good, it seems like the shebangs in a lot of these scripts still refer > to "python". > > dpdk$ git describe > v20.05-623-geff30b59cc2e > dpdk$ git grep '#.*!.*python\>' > app/test-bbdev/test-bbdev.py:1:#!/usr/bin/env python > app/test-cmdline/cmdline_test.py:1:#!/usr/bin/env python > app/test/autotest.py:1:#!/usr/bin/env python > buildtools/map_to_win.py:1:#!/usr/bin/env python > config/arm/armv8_machine.py:1:#!/usr/bin/python > devtools/update_version_map_abi.py:1:#!/usr/bin/env python > usertools/cpu_layout.py:1:#!/usr/bin/env python > usertools/dpdk-devbind.py:1:#! /usr/bin/env python > usertools/dpdk-pmdinfo.py:1:#!/usr/bin/env python > usertools/dpdk-telemetry-client.py:1:#! /usr/bin/env python > > On many distros, "python" still points (as of today) to python2. You > series will cause warnings that cannot be avoided. > > Also, on some distros, "python" does not exist at all (RHEL 8 and CentOS > 8 for example). And only "python2" or "python3" are available. > > I wonder if it would not be better to find a way to make these shebangs > "dynamic" somehow. It is not trivial and I don't see any other solution > than plain modification of the shebangs at build time. > > However, there is no way (to my knowledge) to specify which version of > python is "selected" during the build. > > Does anyone have a proper solution? > That's a good point and I'm not sure there is a clean solution to it - especially if there is no "python" without a 2 or 3 at the end? Theoretically we could put something like this at the start of each script to ensure it runs with python3 if available and "python" otherwise: from __future__ import print_function import sys import os import distutils.spawn if sys.version_info.major < 3: py3 = distutils.spawn.find_executable("python3") if py3: print("Running", ' '.join([py3] + sys.argv)) sys.exit(os.system(' '.join([py3] + sys.argv))) print("Running", str(sys.argv), "with python version",\ str(sys.version_info.major) + "." + str(sys.version_info.minor)) It doesn't solve the problem of those systems where /usr/bin/env python returns nothing, but in those cases the script won't run at all, so the user needs to explicitly call via python2/3 directly and the deprecation notice is correct if they pick the wrong one. For most distros where "python" alone does exist, the above code will work to prevent the deprecation notice appearing except where the user does not have python3 available. If we want to go with a build-time selection approach, we should just change the defaults in all scripts to python3 and only change them back in the Makefile build if python3 is not found. [Meson requires python3, so we can ignore any checks there.] Regards, /Bruce
On Fri, Jul 10, 2020 at 03:33:58PM +0200, Robin Jarry wrote: > Hi Louise, > > 2020-07-10, Louise Kilheeney: > > This patchset adds deprecation notices to python scripts, > > warning of the removal of python2 support from the DPDK 20.11 release. > > While showing warnings to users about Python 2 support drop in 20.11 is > good, it seems like the shebangs in a lot of these scripts still refer > to "python". > > dpdk$ git describe > v20.05-623-geff30b59cc2e > dpdk$ git grep '#.*!.*python\>' > app/test-bbdev/test-bbdev.py:1:#!/usr/bin/env python > app/test-cmdline/cmdline_test.py:1:#!/usr/bin/env python > app/test/autotest.py:1:#!/usr/bin/env python > buildtools/map_to_win.py:1:#!/usr/bin/env python > config/arm/armv8_machine.py:1:#!/usr/bin/python > devtools/update_version_map_abi.py:1:#!/usr/bin/env python > usertools/cpu_layout.py:1:#!/usr/bin/env python > usertools/dpdk-devbind.py:1:#! /usr/bin/env python > usertools/dpdk-pmdinfo.py:1:#!/usr/bin/env python > usertools/dpdk-telemetry-client.py:1:#! /usr/bin/env python > > On many distros, "python" still points (as of today) to python2. You > series will cause warnings that cannot be avoided. > > Also, on some distros, "python" does not exist at all (RHEL 8 and CentOS > 8 for example). And only "python2" or "python3" are available. > > I wonder if it would not be better to find a way to make these shebangs > "dynamic" somehow. It is not trivial and I don't see any other solution > than plain modification of the shebangs at build time. > > However, there is no way (to my knowledge) to specify which version of > python is "selected" during the build. > > Does anyone have a proper solution? > In the absense of a "proper" solution, is the simplest option to change the shebangs to all be python3, but leave the python2 compatibility in place, and add the warnings for anyone running it explicitly using python2?
On Mon, 13 Jul 2020 10:21:49 +0100 Bruce Richardson <bruce.richardson@intel.com> wrote: > On Fri, Jul 10, 2020 at 03:33:58PM +0200, Robin Jarry wrote: > > Hi Louise, > > > > 2020-07-10, Louise Kilheeney: > > > This patchset adds deprecation notices to python scripts, > > > warning of the removal of python2 support from the DPDK 20.11 release. > > > > While showing warnings to users about Python 2 support drop in 20.11 is > > good, it seems like the shebangs in a lot of these scripts still refer > > to "python". > > > > dpdk$ git describe > > v20.05-623-geff30b59cc2e > > dpdk$ git grep '#.*!.*python\>' > > app/test-bbdev/test-bbdev.py:1:#!/usr/bin/env python > > app/test-cmdline/cmdline_test.py:1:#!/usr/bin/env python > > app/test/autotest.py:1:#!/usr/bin/env python > > buildtools/map_to_win.py:1:#!/usr/bin/env python > > config/arm/armv8_machine.py:1:#!/usr/bin/python > > devtools/update_version_map_abi.py:1:#!/usr/bin/env python > > usertools/cpu_layout.py:1:#!/usr/bin/env python > > usertools/dpdk-devbind.py:1:#! /usr/bin/env python > > usertools/dpdk-pmdinfo.py:1:#!/usr/bin/env python > > usertools/dpdk-telemetry-client.py:1:#! /usr/bin/env python > > > > On many distros, "python" still points (as of today) to python2. You > > series will cause warnings that cannot be avoided. > > > > Also, on some distros, "python" does not exist at all (RHEL 8 and CentOS > > 8 for example). And only "python2" or "python3" are available. > > > > I wonder if it would not be better to find a way to make these shebangs > > "dynamic" somehow. It is not trivial and I don't see any other solution > > than plain modification of the shebangs at build time. > > > > However, there is no way (to my knowledge) to specify which version of > > python is "selected" during the build. > > > > Does anyone have a proper solution? > > > > In the absense of a "proper" solution, is the simplest option to change the > shebangs to all be python3, but leave the python2 compatibility in place, > and add the warnings for anyone running it explicitly using python2? The standard way to use python3 that I have seen is: #! /usr/bin/env python3
2020-07-13, Bruce Richardson: > In the absense of a "proper" solution, is the simplest option to > change the shebangs to all be python3, but leave the python2 > compatibility in place, and add the warnings for anyone running it > explicitly using python2? Personally, I am OK with this solution. However, this is quite radical. I guess we would need to make it obvious to everyone using 20.08 that all Python scripts will now use python3 unless they explicitly replace the shebangs when installing them. I wonder if that would not be better to add a build option to force these shebangs.
2020-07-13, Bruce Richardson: > In the absense of a "proper" solution, is the simplest option to > change the shebangs to all be python3, but leave the python2 > compatibility in place, and add the warnings for anyone running it > explicitly using python2? I have found a hacky[1] but somewhat not too ugly way to dynamically use any available python interpreter. Basically, the scripts shebangs become: #!/bin/sh # shell script hack to dynamically use any available python interpreter ''':' if command -pv python3 >/dev/null 2>&1; then exec python3 "$0" "$@" else exec python2 "$0" "$@" fi ''' # real python code starts here This hack obviously would remain only for the time where we still have python 2 support and can be removed after 20.08 is released. What do you think? [1] https://unix.stackexchange.com/a/66242
On Thu, 16 Jul 2020 16:44:29 +0200 Robin Jarry <robin.jarry@6wind.com> wrote: > 2020-07-13, Bruce Richardson: > > In the absense of a "proper" solution, is the simplest option to > > change the shebangs to all be python3, but leave the python2 > > compatibility in place, and add the warnings for anyone running it > > explicitly using python2? > > I have found a hacky[1] but somewhat not too ugly way to dynamically use > any available python interpreter. > > Basically, the scripts shebangs become: > > #!/bin/sh > # shell script hack to dynamically use any available python interpreter > ''':' > if command -pv python3 >/dev/null 2>&1; then > exec python3 "$0" "$@" > else > exec python2 "$0" "$@" > fi > ''' > # real python code starts here > > This hack obviously would remain only for the time where we still have > python 2 support and can be removed after 20.08 is released. > > What do you think? > > [1] https://unix.stackexchange.com/a/66242 > No.
On Thu, Jul 16, 2020 at 02:01:21PM -0700, Stephen Hemminger wrote: > On Thu, 16 Jul 2020 16:44:29 +0200 > Robin Jarry <robin.jarry@6wind.com> wrote: > > > 2020-07-13, Bruce Richardson: > > > In the absense of a "proper" solution, is the simplest option to > > > change the shebangs to all be python3, but leave the python2 > > > compatibility in place, and add the warnings for anyone running it > > > explicitly using python2? > > > > I have found a hacky[1] but somewhat not too ugly way to dynamically use > > any available python interpreter. > > > > Basically, the scripts shebangs become: > > > > #!/bin/sh > > # shell script hack to dynamically use any available python interpreter > > ''':' > > if command -pv python3 >/dev/null 2>&1; then > > exec python3 "$0" "$@" > > else > > exec python2 "$0" "$@" > > fi > > ''' > > # real python code starts here > > > > This hack obviously would remain only for the time where we still have > > python 2 support and can be removed after 20.08 is released. > > > > What do you think? > > > > [1] https://unix.stackexchange.com/a/66242 > > > > No. I could live with this, but I think that python3 is widespread enough now to just go with the simpler solution of python3 by default while still allowing others to run with python2 explicitly if they so desire. I think we have covered a number of options, but I'm not sure we have converged on an agreed solution. Here are the options I would consider: 0. Do nothing to the code, and just print deprecation notice in docs. This will violate the previously documented plan, but won't break anything for anyone. 1. Just add deprecation notice but leave shebang lines unchanged, meaning lots of people see the notice but don't need to care since they just call the script. 2. As #1, but check if python3 is available and only print deprecation notice if not 3. Add deprecation notice, and change shebang lines to use python3. This means that anyone who does not have python3 installed will see a breaking change 4. Change shebangs to use python3 and detect at "make" build time if python3 is available. If py3 is unavailable, adjust shebang and add deprecation warning on "make install". 5. Use shell-hack above. Any other options I'm missing? For me, I think I can live with all options bar #1. Probably my top preference would be #4 or #2, with #0 and #4 next best thereafter. Regards, /Bruce
On Fri, 17 Jul 2020 13:42:09 +0100 Bruce Richardson <bruce.richardson@intel.com> wrote: > On Thu, Jul 16, 2020 at 02:01:21PM -0700, Stephen Hemminger wrote: > > On Thu, 16 Jul 2020 16:44:29 +0200 > > Robin Jarry <robin.jarry@6wind.com> wrote: > > > > > 2020-07-13, Bruce Richardson: > > > > In the absense of a "proper" solution, is the simplest option to > > > > change the shebangs to all be python3, but leave the python2 > > > > compatibility in place, and add the warnings for anyone running it > > > > explicitly using python2? > > > > > > I have found a hacky[1] but somewhat not too ugly way to dynamically use > > > any available python interpreter. > > > > > > Basically, the scripts shebangs become: > > > > > > #!/bin/sh > > > # shell script hack to dynamically use any available python interpreter > > > ''':' > > > if command -pv python3 >/dev/null 2>&1; then > > > exec python3 "$0" "$@" > > > else > > > exec python2 "$0" "$@" > > > fi > > > ''' > > > # real python code starts here > > > > > > This hack obviously would remain only for the time where we still have > > > python 2 support and can be removed after 20.08 is released. > > > > > > What do you think? > > > > > > [1] https://unix.stackexchange.com/a/66242 > > > > > > > No. > > I could live with this, but I think that python3 is widespread enough now > to just go with the simpler solution of python3 by default while still > allowing others to run with python2 explicitly if they so desire. > > I think we have covered a number of options, but I'm not sure we have > converged on an agreed solution. Here are the options I would consider: > > 0. Do nothing to the code, and just print deprecation notice in docs. This > will violate the previously documented plan, but won't break anything for > anyone. > 1. Just add deprecation notice but leave shebang lines unchanged, meaning > lots of people see the notice but don't need to care since they just call > the script. > 2. As #1, but check if python3 is available and only print deprecation > notice if not > 3. Add deprecation notice, and change shebang lines to use python3. This > means that anyone who does not have python3 installed will see a breaking > change > 4. Change shebangs to use python3 and detect at "make" build time if > python3 is available. If py3 is unavailable, adjust shebang and add > deprecation warning on "make install". > 5. Use shell-hack above. > > Any other options I'm missing? > > For me, I think I can live with all options bar #1. Probably my top > preference would be #4 or #2, with #0 and #4 next best thereafter. > 6. Change shebangs to use python3 and don't bother detecting. Since distributions will have python3. 7. Change shebangs and keep the python2 compat imports 8. Other alternative I have seen in code is to use try block in the import section: try: # for Python2 from Tkinter import * except ImportError: # for Python3 from tkinter import * But supporting python2 for a longer time makes no sense. I would go for #0 for 20.08 and full python3 in 20.11 (#3)
On Fri, Jul 17, 2020 at 08:06:23AM -0700, Stephen Hemminger wrote: > On Fri, 17 Jul 2020 13:42:09 +0100 > Bruce Richardson <bruce.richardson@intel.com> wrote: > > > On Thu, Jul 16, 2020 at 02:01:21PM -0700, Stephen Hemminger wrote: > > > On Thu, 16 Jul 2020 16:44:29 +0200 > > > Robin Jarry <robin.jarry@6wind.com> wrote: > > > > > > > 2020-07-13, Bruce Richardson: > > > > > In the absense of a "proper" solution, is the simplest option to > > > > > change the shebangs to all be python3, but leave the python2 > > > > > compatibility in place, and add the warnings for anyone running it > > > > > explicitly using python2? > > > > > > > > I have found a hacky[1] but somewhat not too ugly way to dynamically use > > > > any available python interpreter. > > > > > > > > Basically, the scripts shebangs become: > > > > > > > > #!/bin/sh > > > > # shell script hack to dynamically use any available python interpreter > > > > ''':' > > > > if command -pv python3 >/dev/null 2>&1; then > > > > exec python3 "$0" "$@" > > > > else > > > > exec python2 "$0" "$@" > > > > fi > > > > ''' > > > > # real python code starts here > > > > > > > > This hack obviously would remain only for the time where we still have > > > > python 2 support and can be removed after 20.08 is released. > > > > > > > > What do you think? > > > > > > > > [1] https://unix.stackexchange.com/a/66242 > > > > > > > > > > No. > > > > I could live with this, but I think that python3 is widespread enough now > > to just go with the simpler solution of python3 by default while still > > allowing others to run with python2 explicitly if they so desire. > > > > I think we have covered a number of options, but I'm not sure we have > > converged on an agreed solution. Here are the options I would consider: > > > > 0. Do nothing to the code, and just print deprecation notice in docs. This > > will violate the previously documented plan, but won't break anything for > > anyone. > > 1. Just add deprecation notice but leave shebang lines unchanged, meaning > > lots of people see the notice but don't need to care since they just call > > the script. > > 2. As #1, but check if python3 is available and only print deprecation > > notice if not > > 3. Add deprecation notice, and change shebang lines to use python3. This > > means that anyone who does not have python3 installed will see a breaking > > change > > 4. Change shebangs to use python3 and detect at "make" build time if > > python3 is available. If py3 is unavailable, adjust shebang and add > > deprecation warning on "make install". > > 5. Use shell-hack above. > > > > Any other options I'm missing? > > > > For me, I think I can live with all options bar #1. Probably my top > > preference would be #4 or #2, with #0 and #4 next best thereafter. > > > > 6. Change shebangs to use python3 and don't bother detecting. > Since distributions will have python3. > This was what our originally patch submission was to do, but it was pointed out that we said we would have deprecation notices in the scripts in 20.08 and only remove fully in 20.11 > 7. Change shebangs and keep the python2 compat imports This is pretty much the same as #3. The python2 compat imports etc. will be removed in 20.11 anyway, so we can ignore those I think. > > 8. Other alternative I have seen in code is to use > try block in the import section: > > try: > # for Python2 > from Tkinter import * > except ImportError: > # for Python3 > from tkinter import * > > But supporting python2 for a longer time makes no sense.a This is already done in DPDK. All scripts already support both python2 and python3 AFAIK. If any don't, it's a bug. > > I would go for #0 for 20.08 and full python3 in 20.11 (#3) > Full python3 in 20.11 is indeed the already agreed plan. All python2 compatibility will be removed then. /Bruce
I vote for applying this patch series, because it does not change what we have, except printing a warning in case python3 is neither explicitly called, nor the default. I consider it is a good step, and I don't see the extra warning as a severe annoyance. 17/07/2020 18:24, Bruce Richardson: > On Fri, Jul 17, 2020 at 08:06:23AM -0700, Stephen Hemminger wrote: > > On Fri, 17 Jul 2020 13:42:09 +0100 > > Bruce Richardson <bruce.richardson@intel.com> wrote: > > > I think we have covered a number of options, but I'm not sure we have > > > converged on an agreed solution. Here are the options I would consider: > > > > > > 0. Do nothing to the code, and just print deprecation notice in docs. This > > > will violate the previously documented plan, but won't break anything for > > > anyone. > > > 1. Just add deprecation notice but leave shebang lines unchanged, meaning > > > lots of people see the notice but don't need to care since they just call > > > the script. > > > 2. As #1, but check if python3 is available and only print deprecation > > > notice if not > > > 3. Add deprecation notice, and change shebang lines to use python3. This > > > means that anyone who does not have python3 installed will see a breaking > > > change > > > 4. Change shebangs to use python3 and detect at "make" build time if > > > python3 is available. If py3 is unavailable, adjust shebang and add > > > deprecation warning on "make install". > > > 5. Use shell-hack above. > > > > > > Any other options I'm missing? > > > > > > For me, I think I can live with all options bar #1. Probably my top > > > preference would be #4 or #2, with #0 and #4 next best thereafter. > > > > > > > 6. Change shebangs to use python3 and don't bother detecting. > > Since distributions will have python3. > > > > This was what our originally patch submission was to do, but it was pointed > out that we said we would have deprecation notices in the scripts in 20.08 > and only remove fully in 20.11 > > > 7. Change shebangs and keep the python2 compat imports > > This is pretty much the same as #3. The python2 compat imports etc. will be > removed in 20.11 anyway, so we can ignore those I think. > > > > > 8. Other alternative I have seen in code is to use > > try block in the import section: > > > > try: > > # for Python2 > > from Tkinter import * > > except ImportError: > > # for Python3 > > from tkinter import * > > > > But supporting python2 for a longer time makes no sense.a > > This is already done in DPDK. All scripts already support both python2 and > python3 AFAIK. If any don't, it's a bug. > > > > > I would go for #0 for 20.08 and full python3 in 20.11 (#3) > > > > Full python3 in 20.11 is indeed the already agreed plan. All python2 > compatibility will be removed then.
On Tue, Jul 21, 2020 at 10:25 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > I vote for applying this patch series, > because it does not change what we have, > except printing a warning in case python3 > is neither explicitly called, nor the default. > > I consider it is a good step, > and I don't see the extra warning as a severe annoyance. Users can call the scripts with the right interpreter if the warning is too much for them and they don't want to switch their whole system to python3. +1 for this series.
On Fri, Jul 10, 2020 at 12:11 PM Louise Kilheeney <louise.kilheeney@intel.com> wrote: > > This patchset adds deprecation notices to python scripts, > warning of the removal of python2 support from the DPDK 20.11 release. > > Louise Kilheeney (9): > usertools/cpu_layout: add python2 deprecation notice > usertools/dpdk-telemetry-client: python2 deprecation notice > usertools/dpdk-devbind: add python2 deprecation notice > devtools/update_version_map: add python2 deprecation notice > app/test-cmdline: add python2 deprecation notice > app/test: add python2 deprecation notice > usertools/dpdk-pmdinfo: add python2 deprecation notice > app/test-bbdev: python3 compatibility changes > app/test-bbdev: add python2 deprecation notice Moved patch 8 as first patch then squashed the rest as a single patch. Applied, thanks Louise.