From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.126, mailfrom: liming.gao@intel.com) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by groups.io with SMTP; Fri, 19 Jul 2019 06:07:58 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2019 06:07:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,282,1559545200"; d="scan'208";a="159096448" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga007.jf.intel.com with ESMTP; 19 Jul 2019 06:07:57 -0700 Received: from fmsmsx125.amr.corp.intel.com (10.18.125.40) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 19 Jul 2019 06:07:57 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX125.amr.corp.intel.com (10.18.125.40) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 19 Jul 2019 06:07:57 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.110]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.55]) with mapi id 14.03.0439.000; Fri, 19 Jul 2019 21:07:55 +0800 From: "Liming Gao" To: Leif Lindholm CC: "devel@edk2.groups.io" , Laszlo Ersek , Rebecca Cran , "Feng, Bob C" , "Kinney, Michael D" , "afish@apple.com" Subject: Re: [edk2-devel] [PATCH 1/1] edksetup.sh: rework python executable scanning Thread-Topic: [edk2-devel] [PATCH 1/1] edksetup.sh: rework python executable scanning Thread-Index: AQHVPBfvoF4E+Ey0NE+TBGgFSaKUcqbNRqyAgADYoWCAAMK/gIABrs0Q//+U3gCAAcBxIA== Date: Fri, 19 Jul 2019 13:07:54 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E4AC9E5@SHSMSX104.ccr.corp.intel.com> References: <20190716190754.25412-1-leif.lindholm@linaro.org> <20579d07-778d-ef9f-9226-25e9629fa2d5@redhat.com> <20190716220449.r7kfozr7yaasi64k@bivouac.eciton.net> <4A89E2EF3DFEDB4C8BFDE51014F606A14E4A974D@SHSMSX104.ccr.corp.intel.com> <20190717223711.GE2712@bivouac.eciton.net> <4A89E2EF3DFEDB4C8BFDE51014F606A14E4AC021@SHSMSX104.ccr.corp.intel.com> <20190718175538.GK2712@bivouac.eciton.net> In-Reply-To: <20190718175538.GK2712@bivouac.eciton.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDQ0MDZkMGYtNzdlMC00YmFkLWFhMmEtYzM5MTZlMTVhMjI5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiU1pmdFZqNW5uVmR3VW45bFo2UGtEd1Izc3dadFE0UmdHYjNWTGRSdkdlbkxaU0JXaDhEbmtkSm1Sc08zMjdqYiJ9 dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: liming.gao@intel.com Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Leif: > -----Original Message----- > From: Leif Lindholm [mailto:leif.lindholm@linaro.org] > Sent: Friday, July 19, 2019 1:56 AM > To: Gao, Liming > Cc: devel@edk2.groups.io; Laszlo Ersek ; Rebecca Cran = ; Feng, Bob C ; > Kinney, Michael D ; afish@apple.com > Subject: Re: [edk2-devel] [PATCH 1/1] edksetup.sh: rework python executab= le scanning >=20 > On Thu, Jul 18, 2019 at 04:48:18PM +0000, Gao, Liming wrote: > > > > Find the high version python. When we enable Python3, we find > > > > Python37 does great performance optimization. > > > > So, we think high version python can bring more benefit. > > > > > > This is where I disagree. > > > As a user/admin, I am no more interested in my build tools deciding I > > > would prefer another python than the default one than I am in they > > > deciding I would prefer another toolchain. > > > > > > If I build a specific commit of edk2 (including BaseTools) from a > > > specific command line, then I expect any subsequent builds to behave > > > identically unless I have reconfigured the system. Installing another > > > version of python without changing the system default shoulds not > > > change that. > > > > I agree this is a good point to keep the same build behavior even if us= er > > environment is changed. But, I think user installs new version python, = he > > may want to use it. >=20 > 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. >=20 > > 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 inter= preter. > > It is added @d8238aaf862a55eec77040844c71a02c71294e86 commit. >=20 > Yes, and ideally I would have noticed that and had this conversation > back then. But I didn't. Sorry. >=20 > > Do you meet with the real problem with the high version python interpre= ter? >=20 > 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 versio= n=20 python interpreter. The same source may have the different build result on = those dockers. >=20 > > > If I _want_ to use the newly installed python, I can change the > > > python/python2/python3 links. And if I don't want to do that, I can > > > set PYTHON_COMMAND. > > > "We have seen better performance with 3.7" is an excellent argment fo= r > > > suggesting people install, and use, python 3.7. I do not see it as a > > > good argument for always preferring the highest version available. > > > > User can set PYTHON_COMMAND to keep the same python interpreter. >=20 > Yes, but for me, that logic fails the "least amount of surprise" > litmus test. If the command invoked when I call 'python' (or 'python2' > or 'python3') is the same, then I would expect the same version to be > used by the build system. If I *wanted* applications to use the newer > version, I would change the 'python' (or 'python2' or 'python3') > symlink. >=20 > > > > > - Can we use simply 'python' as the default? > > > > > > > > Based on previous discussion, we recommend to use Python3 as defaul= t. > > > > > > If python3 is to be the default, then I see no use for PYTHON3_=A3NAB= LE. > > > > Now, BaseTools has not drop Python2 support. If user wants to use Pytho= n2, > > he can simply set PYTHON3_ENABLE=3DFALSE, then he doesn't need to find = python path > > to set PYTHON_COMMAND env. >=20 > On Linux, the path is not required for PYTHON_COMMAND. And this is the > .sh, so I would hope the same holds true under cygwin. So > PYTHON_COMMAND=3Dpython2 provides the same functionality as > PYTHON3_ENABLE=3DFALSE. >=20 > *But* the latest version of my script does not behave in this way, so > that still needs to change. >=20 > > > 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? >=20 > Exactly. So I think it it not needed. OK. If you think that PYTHON3_ENABLE is not used, can you send RFC to remov= e it? Thanks Liming >=20 > / > Leif