From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web12.2464.1587720479101400164 for ; Fri, 24 Apr 2020 02:27:59 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UCbBtgOf; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587720478; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JgNyoVeBDvchgsD2BZVCdU7l9B52ogHVKDqOHtceIEA=; b=UCbBtgOf1VUcfhkHHZLtcRXkciJbwor+Gm0SdHLrO5ogyk1Im5rArL1i/TpO7B6YaoTwJ0 QdVqR/phZDnnnB/rFReMvTwwSRbiYexXCKYNKwl18xbspSplj659CW1XbOF5nir8Ko/Yid xLxsKjS0WFanFdUL9LrBr6OUFYueAzk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-288-OKCwVV1oOiih-J-VlVRmcw-1; Fri, 24 Apr 2020 05:27:51 -0400 X-MC-Unique: OKCwVV1oOiih-J-VlVRmcw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 55103460; Fri, 24 Apr 2020 09:27:50 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-159.ams2.redhat.com [10.36.113.159]) by smtp.corp.redhat.com (Postfix) with ESMTP id AD62D79B6; Fri, 24 Apr 2020 09:27:49 +0000 (UTC) Subject: Re: [edk2-devel] FW: Discussion: Basetools a separate repo To: Matthew Carlson , devel@edk2.groups.io References: <383cfe10-81b8-63be-3ed6-a1d3cb304fb5@redhat.com> <328.1587583818041440437@groups.io> From: "Laszlo Ersek" Message-ID: Date: Fri, 24 Apr 2020 11:27:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <328.1587583818041440437@groups.io> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 04/22/20 21:30, macarl via [] wrote: > I think you've got it. The version of basetools will be carried via a pip-requirements file. > > Where would "pip install -r pip-requirements.txt" *fetch* the required basetools version from? > I believe that it has a cache internal to pip. But if you want to fetch a basetools that hasn't been fetched before, yes, it would require a network download. Alternatively, if you're without internet access, you can check it out locally and use the pip install -e. > > Can you please explain the effects of the "pip install -e in more detail? > So I'm a little murky on how it works but I believe that it creates symlinks or some other mechanism to repoint the global python module (global meaning your pip install or virtualenv). This is something that works automatically. The setup.py in the root of the repo takes care of this since it's used also to package the pip module. You can do pip install -e., and it just works (tm). Any basetools commit you check out (once it is in it's own repo, going back a given basetools commit two years ago is unfortunately not as easy) will work with pip install -e with not setup or configuration on your part as a developer. I use this whenever I work on the pytools and it works quite well. It will also show up in the BuildToolsReport and pip freeze as being locally installed and it will tell you the git commit it is currently at. > > I agree- I think we're trending towards very very frequent releases for basetools to provide high granularity. But that is pending community feedback and the decision of the tools maintainer. It is certainly trivial to automate the release pipeline in such a way that a release with every commit that passes CI is easy and mostly automatic for the maintainers. Thank you. All of the above sounds nice. I'm carefully optimistic about these changes, and am not opposing them at this point. I hope I can find the time to test these features once they are being proposed in code form. Regarding the frequent (automatic) release tagging for the separate basetools repo -- that too sounds great; I just think it will need manual work on the edk2 side, i.e. to keep "pip-requirements.txt" bumped. While that work sounds quite "menial", I much hope that it can be integrated into the basetools development requirements -- "whenever you get something into basetools, and the system tags a new release automatically, be sure to post a patch to edk2 for advancing it to the new basetools release". Thanks! Laszlo