Re: [edk2-devel] [PATCH 1/1] edksetup.sh: rework python executable scanning

["Liming Gao" <liming.gao@intel.com>]

Leif:

> -----Original Message-----
> From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
> Sent: Tuesday, July 23, 2019 5:45 PM
> To: Gao, Liming <liming.gao@intel.com>
> Cc: devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; Rebecca Cran <rebecca@bsdio.com>; Feng, Bob C <bob.c.feng@intel.com>;
> Kinney, Michael D <michael.d.kinney@intel.com>; afish@apple.com
> Subject: Re: [edk2-devel] [PATCH 1/1] edksetup.sh: rework python executable scanning
> 
> On Fri, Jul 19, 2019 at 01:07:54PM +0000, Gao, Liming wrote:
> > > Yes.
> > > But perhaps the user isn't the admin, and the admin installs a new
> > > version of python without updating the default links, in order to let
> > > a different user test the new version. Thinking this will not affect
> > > users, because python, python2 and python3 all behave exactly like
> > > before.
> > >
> > > > Current edksetup.sh can easily apply the new version python.
> > > > Now, the difference is the default policy to choose python version.
> > > > Your suggestion is to use default version python interpreter or base
> > > > on PATH to find the python interpreter.
> > > > Current logic is to find the high version in the available python interpreter.
> > > > It is added @d8238aaf862a55eec77040844c71a02c71294e86 commit.
> > >
> > > Yes, and ideally I would have noticed that and had this conversation
> > > back then. But I didn't. Sorry.
> > >
> > > > Do you meet with the real problem with the high version python interpreter?
> > >
> > > Not yet.
> > > But I can easily see this causing issues with the various docker
> > > images we have set up for various (not just TianoCore) CI jobs.
> >
> > What issue here? You mean the variable docker may have the different version
> > python interpreter. The same source may have the different build result on those dockers.
> 
> Sorry, I'm going to stop giving specifics here. I was trying to use it
> as an example, but it has clearly turned into just a distraction,
> bringing us further from the actual problem.
> 
> The fundamental issue is this:
> * As a distribution mainteiner (or docker image owner), I will pick
>   whatever default version of system tools are. I may also decide to
>   install multiple versions, but keeping the default at a lower than
>   latest version.
> * As a user, or CI implementer, I may choose to override that (by for
>   example installing my own version of python and updating my PATH to
>   look there first).
> 
> Scanning through the path looking for "highest version" breaks both of
> these. Just like scanning through the path looking for the highest
> C compiler version would.
> 

I agree C compiler version is a good case. Edk2 tool chain GCC5 uses the default gcc compiler, 
doesn't find the highest version GCC compiler. They can align to the same rule. If we 
change the policy to find the default python3, how we let user know python37 have the 
better performance improvement? 


> > > *But* the latest version of my script does not behave in this way, so
> > > that still needs to change.
> > >
> > > > > If PYTHON_COMMAND is set, it should always be respected. If it's not
> > > > > set, python3 is picked in preference anyway.
> > > >
> > > > So, PYTHON_COMMAND is higher priority than PYTHON3_ENABLE.
> > > > That means PYTHON3_ENABLE value will be ignored. Right?
> > >
> > > Exactly. So I think it it not needed.
> >
> > OK. If you think that PYTHON3_ENABLE is not used, can you send RFC to remove it?
> 
> Yes, will do.

Thanks 

Liming

> 
> /
>     Leif