From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.136, mailfrom: liming.gao@intel.com) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by groups.io with SMTP; Thu, 18 Jul 2019 09:48:21 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2019 09:48:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,278,1559545200"; d="scan'208";a="367411352" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga006.fm.intel.com with ESMTP; 18 Jul 2019 09:48:20 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 18 Jul 2019 09:48:20 -0700 Received: from shsmsx154.ccr.corp.intel.com (10.239.6.54) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 18 Jul 2019 09:48:20 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.110]) by SHSMSX154.ccr.corp.intel.com ([169.254.7.240]) with mapi id 14.03.0439.000; Fri, 19 Jul 2019 00:48:18 +0800 From: "Liming Gao" To: "devel@edk2.groups.io" , "leif.lindholm@linaro.org" CC: 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 Date: Thu, 18 Jul 2019 16:48:18 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E4AC021@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> In-Reply-To: <20190717223711.GE2712@bivouac.eciton.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjkyMDRjMGItNzkzNC00OTU0LTgwMzAtMjdhZDViZWM5OWNkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiXC81WHpLU3dQOE8wQ1hoQzVYTWZYMzVvQklkTHlIaHBROW12NWxZUERwM1JKYnJxb3hKUGtJM0VBUkh2b2oxUjUifQ== 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: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Le= if Lindholm > Sent: Thursday, July 18, 2019 6:37 AM > To: Gao, Liming > Cc: Laszlo Ersek ; devel@edk2.groups.io; Rebecca Cran= ; Feng, Bob C ; > Kinney, Michael D ; afish@apple.com > Subject: Re: [edk2-devel] [PATCH 1/1] edksetup.sh: rework python executa= ble scanning >=20 > On Wed, Jul 17, 2019 at 03:23:26AM +0000, 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] > > > So, first of all - I am entirely happy with dropping the function. > > > But I wanted to have it written anyway in case someone came up with = a > > > really good explanation for why we needed to completely cover the sa= me > > > pattern as the code currently in tree: and the situation does not > > > relate to python4 or python5 - it relates to picking the latest of > > > 2.7, 2.7.6, 3.5, 3.5.2, 3.5,4, 3.7 (which is my interpretation of th= e > > > behaviour of current HEAD). > > > > > > So basically - I think we need to reach an agreement (with BaseTools > > > maintainers, and existing users) about what the behaviour should be. > > > > > > - 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 priorit= y. > > Once it is set, PYTHON_COMMAND will be ignored. > > If it is set to TRUE, edksetup.sh will find Python3 in the system, s= et PYTHON_COMMAND env. > > If it is set to other value, edksetup.sh will find Python2 in the sy= stem, set PYTHON_COMMAND env. > > If PYTHON3_EANBLE is not set, PYTHON_COMMAND will be used if PYTHON_CO= MMAND is set. > > If PYTHON3_EANBLE is not set, and PYTHON_COMMAND is not set, the > > default behavior will set PYTHON3_EANBLE to TRUE. >=20 > (typo as discussed in other email corrected above (python3->python2)) >=20 > > So, the default behavior is to use highest version Python3. User can > > set PYTHON_COMMAND for their python version. > > > > > - What should the priority order be when looking for python > > > executables? > > > > 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. >=20 > 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. >=20 > 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 user= =20 environment is changed. But, I think user installs new version python, he= =20 may want to use it. Current edksetup.sh can easily apply the new version p= ython.=20 Now, the difference is the default policy to choose python version.=20 Your suggestion is to use default version python interpreter or base on PA= TH to find the python interpreter.=20 Current logic is to find the high version in the available python interpre= ter.=20 It is added @d8238aaf862a55eec77040844c71a02c71294e86 commit.=20 Do you meet with the real problem with the high version python interpreter= ?=20 >=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 for > suggesting people install, and use, python 3.7. I do not see it as a > good argument for always preferring the highest version available. >=20 User can set PYTHON_COMMAND to keep the same python interpreter. > > > - Can we use simply 'python' as the default? > > > > Based on previous discussion, we recommend to use Python3 as default. >=20 > If python3 is to be the default, then I see no use for PYTHON3_=A3NABLE. Now, BaseTools has not drop Python2 support. If user wants to use Python2,= = =20 he can simply set PYTHON3_ENABLE=3DFALSE, then he doesn't need to find pyt= hon path=20 to set PYTHON_COMMAND env.=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? Thanks Liming >=20 > > > - Do we need functionality for more than selecting between > > > python2/python3? > > > > Yes. Find the high version python installed in the system. >=20 > Best Regards, >=20 > Leif >=20 >=20