Matthew Carlson <matthewfcarlson@...>
toggle quoted message
Show quoted text
I think leveraging the existing edksetup is a great idea. Using the
existing EDK_TOOL_PATH variable could work but it seems clunky. Since the
pip module wouldn't be a path, it seems strange to put a boolean value in a
variable meant to hold a path. I definitely think that the scripts could
print whether they're using the pip modules or the in-source tools. Since
Lazlo suggested that pip will be the default, we could have the in-source
modules notify of the fact that you're using the in-source modules. An
additional feature for the pip module could be printing the version that
they are (since you can use the pip infrastructure to query the version of
a given module within a python script). Another option would be simply
trying the pip module first and then falling back to the in-source module.
There would be a slight speed penalty (likely around 10ms) but since this
would only apply to trim and build, it should have relatively low impact.
Thank you for the excellent summary of the different pieces of the
discussion along with the links. To answer your first point, I think what a
developer does with their pip module is largely up to them. They could do a
virtual environment, they could just do what the requirements state, or pip
install from a checked out basetools.I do think there are some variables
that the virtual environment sets up that would be a good signal whether
you're in a virtual environment or not. I agree with your approach of
basetools development going into the out of edk2 repo and the importance of
making sure package maintainers test and validate their areas with the new
setup. I would personally try to get this early into the development cycle,
(just after this next stable tag this week) to give the community and
developers the most amount of time to get used to things. A trial period of
one release makes sense.
I also agree that the gateway is important in maintaining cohesion between
the new and the old. Hopefully that's nearing completion.
Hopefully other stewards will weigh in but otherwise we'll move ahead with
a proposed solution in patches next week.
On Wed, Sep 2, 2020 at 1:49 AM Laszlo Ersek <lersek@...> wrote:
On 09/02/20 02:49, Andrew Fish via groups.io wrote:
On Sep 1, 2020, at 4:35 PM, Matthew Carlson <matthewfcarlson@...>
Basetools/Sources/Python to a separate repo has started. See the RFC
A recent topic on the RFC mailing list went out and the work on moving
conversation here: https://edk2.groups.io/g/rfc/topic/74009714#270 <
The repo in question is here:
of patches will come into edk2 that redirects the build system into the new
The current plan is shortly after the stable tag is created, a series
python module as well as adds additional documentation. You can see a
sample of this work here: https://github.com/matthewfcarlson/edk2 <
https://github.com/matthewfcarlson/edk2> as this has a branch that has
the work required to use the basetools pip module. The patches won't delete
the Basetools/Sources/Python folder but will allow users to select between
them. After a certain grace period, the python folder will be deleted and
the pip module will be the de facto way of using basetools.
the grace period be?
Three questions need to be answered:
1. After the patches that enable the pip module land, how long should
places or just in the edk2-basetools directory?
2. During the grace period, should basetools commits land in both
one in EDK2 or the pip module)? Currently the approach being considered is
3. How should the user be able to select which basetools to use (the
a simple environmental variable? One of the key considerations is
transparency since it won't be apparent what is being used for a particular
build without some sort of mechanism to notify the developer. With two
seperate versions of Basetools, it becomes very easy for the version of
basetools you're using to not be the one you expect.
Matthew,behavior, and you add an argument you get the pip flavor? So maybe
I’ll throw out some current developer centric ideas.
1) If you `source edksetup.sh` (edksetup.bat) you get the current
2) We have similar issues to this with env variables and the buildcommand dumps them out when it runs. Can we use the current EDK_TOOL_PATH?
Or maybe add an extra print to show that the pip module is being used?
- the earlier discussion linked above (rooted at <
- the even earlier comments in the "Discussion: Basetools a separate repo"
thread on edk2-devel:
If I still understand / remember correctly, the way at least *I* would use
the new feature is the following:
- set up a new virtual python environment,
- either install the new pip module "permanently" in the virtual
environment, or else install it in "editable mode" from a git checkout (but
*still* in the virtual environment)
- build edk2 with the virtual environment active
That is, for me anyway, the key distinguishing factor would be that I'd be
in a python virtual environment where this particular python module existed
/ were installed.
Does this answer question (3)? Because, in my case anyway, I wouldn't have
to be *notified* about using the separate basetools repo vs. using the one
resident in edk2 -- instead, I'd have to *activate* the separate basetools
repo myself, as first step. So if that activation brings some queriable
feature into the environment (sets a new environment variable or makes a
new python package appear in the environment), then I think it's good
enough -- the usual tools that I run then can query these artifacts.
In short (I guess): commands should use the in-tree variant, unless I
activate the virtual environment that has the basetools PIP module
I think it would be fine to require that, *if* someone intends to activate
such a python virtual environment, *then* they do so *before* running
"edksetup.sh". So "edksetup.sh" could check for the python env having the
external basetools repo / module active. Hopefully that would be "early
Regarding the grace period -- questions (1) and (2):
- The patches introducing the new feature to edk2 should be posted to the
list. These patches should also add a warning to "edksetup.sh" that urges
the developer to use the out-of-tree basetools repo / PIP module, in case
"edksetup.sh" determines the current choice is the in-tree variant (that
is, the virtual env is inactive, or does not contain the new PIP module)
- While the patches are pending approval, BaseTools development is put on
hold (no fixes, no features).
- For every package (subsystem) listed in Maintainers.txt, in *both* edk2
*and* edk2-platfomrs, at least one "M" person is required to report back
with a Tested-by, meaning that they built said package successfully with
the new PIP module.
- When this feedback is complete, the patch is merged, and the new PIP
module becomes the default build system (see the edksetup.sh warning
- Optimally, the above (= comprehensive testing feedback, and merging)
would occur *early* in the development cycle (just after the last stable
- Going forward, bug reports and feature requests are only addressed in
the new (out-of-tree) module. If someone reports that they have to switch
back, *temporarily*, for whatever reason, to the in-tree variant, and the
in-tree variant no longer builds edk2 for them, then such issues can be
resolved on a case-by-case basis, *after* the issue is reported. Point
being, we make the out-of-tree system the new default because of the
comprehensive and strict initial testing requirements (see above); after
which the old system is preserved for a while only as a fallback. If the
fallback proves lacking later on (but still during the grace period), then
the community works to resolve the issue in one of two ways: either help
the issue reporter eliminate their need to use the fallback in the first
place, or backport the subject bugfix/feature to the fallback.
- After the *next* stable release (which still contains both the fallback
and the support for the out-of-tree PIP module), the fallback is removed.
Ultimately this would make the grace period almost one full development
cycle, in which cycle the new system should be tested comprehensively, and
become the default, near the beginning of the period.
This is just my proposal. Some of the other stewards are temporarily away;
I'd suggest waiting for their feedback too.
To finish up, I would like to highlight something from the earlier RFC:
Since this is a separate repo, it will follow a slightly different
contribution and code review process.
1. Github PR process will be used for contributions and code review
a. The yet to be released “Tianocore PR archiver” will be used to
send to a dedicated list for basetools patch review archive
2. PRs will only be committed if they keep linear history (no merge
3. The PR review must be approved by at least 2 members of the
basetools team (not including the author)
4. The PR must pass all automated checks
b. Unit tests
c. Code coverage (can’t commit change that would decrease overall %)
d. DCO enforcement - https://probot.github.io/apps/dco/
e. See other python requirements from the Python coding standard
5. Github Issues will be used for non-security sensitive
Point (1a) is a pre-requisite for merging the edk2 patches!
We cannot make the new system the default unless its development process
is integrated with the github-to-email gateway (webhook).