Re: [edk2-devel] FW: Discussion: Basetools a separate repo

["Purma, Kondal R" <kondal.r.purma@intel.com>]

> Can you please explain the effects of the "pip install -e in more detail?

"Pip install -e" basically editable mode feature, means it installs setuptools in development mode. We can install any prjects in editable mode and also supports local or  from git or svn supported mode.

Pip also supports pinned version numbers (which can protect bugs or incompatibilities) and Hash-checking mode. 

I think for long term we are moving right direction .

Thanks,
Kondal.
-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: Friday, April 24, 2020 2:28 AM
To: Matthew Carlson <macarl@microsoft.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] FW: Discussion: Basetools a separate repo

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