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

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

Laszlo:

> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, July 17, 2019 6:22 PM
> To: Gao, Liming <liming.gao@intel.com>; Leif Lindholm <leif.lindholm@linaro.org>
> Cc: devel@edk2.groups.io; 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: [PATCH 1/1] edksetup.sh: rework python executable scanning
> 
> On 07/17/19 05:23, Gao, Liming wrote:
> > Leif:
> >   I agree to discuss the behavior first, then review the code logic in detail. I add my comments below.
> >
> >> -----Original Message-----
> >> From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
> >> Sent: Wednesday, July 17, 2019 6:05 AM
> >> To: Laszlo Ersek <lersek@redhat.com>
> >> Cc: devel@edk2.groups.io; Rebecca Cran <rebecca@bsdio.com>; Feng, Bob C <bob.c.feng@intel.com>; Gao, Liming
> >> <liming.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; afish@apple.com
> >> Subject: Re: [PATCH 1/1] edksetup.sh: rework python executable scanning
> 
> >> - What does PYTHON3_ENABLE mean? Is it for probing only, or are we
> >>   setting it for later use by BaseTools?
> >
> > PYTHON3_EANBLE is to decide python3 enable or not. It has high priority.
> > Once it is set, PYTHON_COMMAND will be ignored.
> >   If it is set to TRUE, edksetup.sh will find Python3 in the system, set PYTHON_COMMAND env.
> >   If it is set to other value, edksetup.sh will find Python3 in the system, set PYTHON_COMMAND env.
Correct one typo here, sorry for the confuse.
If it is set to other value, edksetup.sh will find Python2 in the system, set PYTHON_COMMAND env.

> > If PYTHON3_EANBLE is not set, PYTHON_COMMAND will be used if PYTHON_COMMAND is set.
> > If PYTHON3_EANBLE is not set, and PYTHON_COMMAND is not set, the default behavior will set PYTHON3_EANBLE to TRUE.

> 
> I find this confusing. Basically, PYTHON3_EANBLE says, "ignore
> PYTHON_COMMAND, just go for the highest python3 version".
> 
> But that is the exact same behavior as if the user didn't set *either*
> PYTHON3_EANBLE *or* PYTHON_COMMAND. So why do we have two configurations
> for the exact same behavior?
> 
> Namely (to repeat):
> 
> (1) PYTHON3_EANBLE is set to a non-null string: PYTHON_COMMAND is
> ignored, and we pick the highest minor version of python3.
> 
> (2) PYTHON3_EANBLE is unset, and PYTHON_COMMAND is unset: we pick the
> highest minor version of python3.
> 
> Those configurations -- evoking identical behavior -- could be collapsed
> into one configuration, namely, if we simply eliminated PYTHON3_EANBLE,
> and relied on PYTHON_COMMAND only. Here's how:
> 
> * PYTHON_COMMAND is unset: pick the highest minor version of python3.

Before Python3 enable, there is no requirement to set PYTHON_COMMAND path.
To keep this support, introduce PYTHON3_ENABLE for auto find python2 or python3. 

Thanks
Liming
> 
> Thanks
> Laszlo