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

["Leif Lindholm" <leif.lindholm@linaro.org>]

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.

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

/
    Leif