Liming, I think that the user should not need to set PYTHON3_ENABLE at all if they manually set PYTHON_COMMAND.
-Jaben > -----Original Message----- > From: Gao, Liming > Sent: Tuesday, January 08, 2019 4:43 PM > To: Carsey, Jaben <jaben.car...@intel.com>; Laszlo Ersek > <ler...@redhat.com>; Ni, Ray <ray...@intel.com>; edk2-devel@lists.01.org; > leif.lindh...@linaro.org; af...@apple.com; Kinney, Michael D > <michael.d.kin...@intel.com> > Subject: RE: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update > Importance: High > > Jaben: > I also think this way. Now, we have two envs PYTHON3_ENABLE and > PYTHON_COMMAND. The behavior can be combined as the below to > support this usage. If user wants the specific python interpreter, he only > needs to set PYTHON_COMMAND env. > > If PYTHON3_ENABLE is set, PYTHON_COMMAND will be set to the found one > by edk2 scripts based on PYTHON3_ENABLE value. > If PYTHON3_ENABLE is not set, but PYTHON_COMMAND is set, then > PYTHON_COMMAND will be used to run python script. No version check > here. > If PYTHON3_ENABLE is not set, but PYTHON_COMMAND is not set, > PYTHON_COMMAND will be set to the high version python installed in OS. > > Thanks > Liming > >-----Original Message----- > >From: Carsey, Jaben > >Sent: Wednesday, January 09, 2019 2:06 AM > >To: Laszlo Ersek <ler...@redhat.com>; Gao, Liming > <liming....@intel.com>; > >Ni, Ray <ray...@intel.com>; edk2-devel@lists.01.org; > leif.lindh...@linaro.org; > >af...@apple.com; Kinney, Michael D <michael.d.kin...@intel.com> > >Subject: RE: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update > > > > > > > >> -----Original Message----- > >> From: Laszlo Ersek [mailto:ler...@redhat.com] > >> Sent: Tuesday, January 08, 2019 9:26 AM > >> To: Carsey, Jaben <jaben.car...@intel.com>; Gao, Liming > >> <liming....@intel.com>; Ni, Ray <ray...@intel.com>; edk2- > >> de...@lists.01.org; leif.lindh...@linaro.org; af...@apple.com; Kinney, > >> Michael D <michael.d.kin...@intel.com> > >> Subject: Re: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update > >> Importance: High > >> > >> On 01/08/19 17:22, Carsey, Jaben wrote: > >> > Liming and Laszlo, > >> > What if we add a 4th option to the environment variable - the path to > >> a specific python interpreter for use. > >> > >> I thought of that, but how do the build tools derive the python version > >> just from the pathname of the interpreter? > >> > >> Will they run "$INTERPRETER --version" and parse the output? > >> > >> I think that could be brittle; distributions sometimes customize the > >> version strings of their executables. The "--version" output is usually > >> human-readable, not machine-readable (per intent). > > > >Laszlo, you lost me. How is that related to an exact path? If the user > specifies > >the path, then always use that specific interpreter. > > > >> > >> Thanks, > >> Laszlo > >> > >> > > >> > -Jaben > >> > > >> > > >> >> -----Original Message----- > >> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > >Of > >> >> Gao, Liming > >> >> Sent: Tuesday, January 08, 2019 6:23 AM > >> >> To: Laszlo Ersek <ler...@redhat.com>; Ni, Ray <ray...@intel.com>; > >edk2- > >> >> de...@lists.01.org; leif.lindh...@linaro.org; af...@apple.com; Kinney, > >> >> Michael D <michael.d.kin...@intel.com> > >> >> Subject: Re: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update > >> >> > >> >> Laszlo: > >> >> Yes. This can be supported. But, I don't know what purpose to specify > >> >> python minor version of Python3. Current implementation in Python3 > >> branch > >> >> always tries to find the high version installed in OS. For example, > >> Python3.4, > >> >> Python3.7 are both installed, Python3.7 will be chosen. Does this policy > >> meet > >> >> with your usage? > >> >> > >> >> Thanks > >> >> Liming > >> >>> -----Original Message----- > >> >>> From: Laszlo Ersek [mailto:ler...@redhat.com] > >> >>> Sent: Tuesday, January 8, 2019 3:04 AM > >> >>> To: Gao, Liming <liming....@intel.com>; Ni, Ray <ray...@intel.com>; > >> edk2- > >> >> de...@lists.01.org; leif.lindh...@linaro.org; > >> >>> af...@apple.com; Kinney, Michael D <michael.d.kin...@intel.com> > >> >>> Subject: Re: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update > >> >>> > >> >>> On 01/07/19 14:41, Gao, Liming wrote: > >> >>>> Ray: > >> >>>> I think this proposal is good to recommend Python3 as the default > >> >> interpreter. I summary the updated proposal. > >> >>>> > >> >>>> 1. PYTHON3_ENABLE env is not set. edksetup.bat/edksetup.sh will > >find > >> >> higher version python installed in OS. If Python3 is found, > >> >>> Python3 will be used. Then, if python2 is found, and python2 is used. > If > >> not > >> >> found, report error and stop build. This will change the > >> >>> default python interpreter from Python2 to Python3 when they both > >are > >> >> installed. > >> >>>> 2. PYTHON3_EANBLE env is set to TRUE. edksetup.bat/edksetup.sh > >will > >> >> find Python3. If Python3 is found, Python3 will be used. If not > >> >>> found, report error and stop build. > >> >>>> 3. PYTHON3_ENABLE env is set to not TRUE. > >edksetup.bat/edksetup.sh > >> >> will find Python2. If Python2 is found, Python2 will be used. If > >> >>> not found, report error and stop build. > >> >>>> Once Python is found, edksetup.bat/edksetup.sh and build tool will > >> both > >> >> print message to let user aware which version python tool is > >> >>> used in this build. > >> >>> > >> >>> If we're going for this level of flexibility, I'd like to suggest / > >> >>> request another improvement. Some Linux distros intend to > >> accommodate > >> >>> multiple Python3 versions at the same time (this is not a typo; I don't > >> >>> mean Python2+Python3, but multiple Python3 versions). So basically > I'd > >> >>> suggest that we offer a method for specifying a python version > >> >>> (2/3/auto-detect), plus, in case a specific major version is specified, > >> >>> that we allow the user to specify the precise interpreter pathname > too. > >> >>> > >> >>> Thanks, > >> >>> Laszlo > >> >> _______________________________________________ > >> >> edk2-devel mailing list > >> >> edk2-devel@lists.01.org > >> >> https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel