Re: [edk2-devel] RFC for Edk2-Library

["Laszlo Ersek" <lersek@redhat.com>]

On 05/07/19 23:35, Sean via Groups.Io wrote:
> RFC  Edk2-Library creation
>
> Create a new tianocore owned repository to host a python library
> package in support of UEFI development.  This package will allow easy
> sharing of python library code to facilitate reuse.  Inclusion of this
> package and dependency management should be managed using Pip/Pypi. To
> start this is a supplemental package and is not required to be used
> for edk2 builds.

[1]

> Examples of content here
>
> * Edk2 file type parsing
> * UEFI structure encode/decode in python
> * Packaging tools (Capsules generation, signing, INF gen, Cat gen)
> * TPM support code
> * Potentially move content from basetools/source/python/common/*

[2]

> * No command line tools/interface
>
> Maintainers
>
> * Sean Brogan
> * Bret Barkelew
> * Placeholder for existing maintainer from the basetools
>
> License
>
> * BSD + Patent (edk2 aligned)
>
> Contribution process and issue tracking
>
> * Follow Github PR process for contributions and issue tracking
> * Contributor forks repo in github
> * Contributor creates branch for work
> * Contributor updates release notes to indicate change (if necessary)
> * Contributor submits PR to master branch of tianocore/Edk2-Library
>   repo
> * Review feedback is given in PR
> * Python Tests are run on the repo (new contributions need unit tests)
> * Python Style (flake8) must pass
> * All review feedback must be completed, maintainers approved, and
>   tests run successfully before PR is *squash merged* into master

The sentences

[1] "To start this is a supplemental package and is not required to be
     used for edk2 builds."

[2] "Potentially move content from basetools/source/python/common/*"

foreshadow that such a code movement might happen down the road, and the
external package could become a requirement for building edk2.

That step would mean the following:

(a) Edk2 would not remain buildable from a single command

    git clone --recurse-submodules

    Building edk2 would require GNU/Linux users to start tracking
    packages with "pip", which is independent of any given distro's own
    package management, and may cause conflicts if not used carefully:

      https://developer.fedoraproject.org/tech/languages/python/pypi-installation.html

    This requirement on "pip" would only go away once the external
    python dependencies were packaged for at least the larger GNU/Linux
    distros.

(b) Edk2 users running into build problems related to the external
    python dependencies would have to contribute through a github-only
    workflow. That's not a deal-breaker per se -- if we want to
    contribute to other edk2 dependencies, such as OpenSSL or nasm, we
    also have to conform to their specific development models, clearly.

    However, "squash merge" is a catastrophically bad development model,
    and I'd object to introducing a new edk2 build dependency that
    followed that model.

    (There are other issues with the GitHub.com development workflow, as
    discussed elsewhere, but "squash merge" takes the cake.)

Problem (a) would be solvable in the long term (through collaboration
with distro maintainers, i.e. downstream packaging), but problem (b)
would not be. Thus I'm fine with the proposal, in its current form, only
if the new package is 100% an addition on top of edk2, even in the long
term, and not in any part intended as a future replacement for current
edk2 functionality.

Thanks,
Laszlo