DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Robin Jarry <robin.jarry@6wind.com>,
	Louise Kilheeney <louise.kilheeney@intel.com>,
	dev@dpdk.org, david.marchand@redhat.com
Subject: Re: [dpdk-dev] [PATCH 0/9] python2 deprecation notice
Date: Fri, 17 Jul 2020 17:24:17 +0100	[thread overview]
Message-ID: <20200717162417.GC719@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <20200717080623.24ba9d1d@hermes.lan>

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

  reply	other threads:[~2020-07-17 16:24 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-10 10:10 Louise Kilheeney
2020-07-10 10:10 ` [dpdk-dev] [PATCH 1/9] usertools/cpu_layout: add " Louise Kilheeney
2020-07-10 10:10 ` [dpdk-dev] [PATCH 2/9] usertools/dpdk-telemetry-client: " Louise Kilheeney
2020-07-10 10:10 ` [dpdk-dev] [PATCH 3/9] usertools/dpdk-devbind: add " Louise Kilheeney
2020-07-10 10:10 ` [dpdk-dev] [PATCH 4/9] devtools/update_version_map: " Louise Kilheeney
2020-07-10 10:59   ` Neil Horman
2020-07-13  8:12   ` Kinsella, Ray
2020-07-10 10:10 ` [dpdk-dev] [PATCH 5/9] app/test-cmdline: " Louise Kilheeney
2020-07-10 10:10 ` [dpdk-dev] [PATCH 6/9] app/test: " Louise Kilheeney
2020-07-10 10:10 ` [dpdk-dev] [PATCH 7/9] usertools/dpdk-pmdinfo: " Louise Kilheeney
2020-07-10 11:00   ` Neil Horman
2020-07-10 10:10 ` [dpdk-dev] [PATCH 8/9] app/test-bbdev: python3 compatibility changes Louise Kilheeney
2020-07-10 10:10 ` [dpdk-dev] [PATCH 9/9] app/test-bbdev: add python2 deprecation notice Louise Kilheeney
2020-07-10 15:53   ` Chautru, Nicolas
2020-07-10 10:30 ` [dpdk-dev] [PATCH 0/9] " Bruce Richardson
2020-07-10 13:33 ` Robin Jarry
2020-07-10 14:47   ` Bruce Richardson
2020-07-13  9:21   ` Bruce Richardson
2020-07-14  1:19     ` Stephen Hemminger
2020-07-15  7:01     ` Robin Jarry
2020-07-16 14:44     ` Robin Jarry
2020-07-16 21:01       ` Stephen Hemminger
2020-07-17 12:42         ` Bruce Richardson
2020-07-17 15:06           ` Stephen Hemminger
2020-07-17 16:24             ` Bruce Richardson [this message]
2020-07-21 20:25               ` Thomas Monjalon
2020-07-21 20:56                 ` David Marchand
2020-07-21 21:05 ` David Marchand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200717162417.GC719@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=louise.kilheeney@intel.com \
    --cc=robin.jarry@6wind.com \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).