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

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

Hi Sean ,

Sorry I replied to wrong subject and it's about ToolEnv.

It's great that all python files must pass flake8 Python Style. I remember flake8 does not show errors for undefined member variables or instances . 

I feel this is one of most common use cases of code failures, due to typing errors and won't be visible unless  test that use case.

Are we planning to use any flake8 plug-ins to cover this or is it good idea to use Pylint (only to cover features not covered by falke8)on top of flake8.

Thanks,
Kondal.

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Michael D Kinney
Sent: Thursday, May 23, 2019 10:14 AM
To: devel@edk2.groups.io; sean.brogan@microsoft.com; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv

Hi Sean,

Thanks for the clarification that this PIP module has more than just build and CI.  And over time, it may add more features to help developers maintain their code and platforms.  How about

  edk2-tool-extensions

And we perhaps remove plural from the library repo

  edk2-tool-library

Do you think that python needs to be in the repo name so it is obvious these are python components.  Or is the top level Readme.md sufficient to make this obvious.  Perhaps:

  edk2-pytool-extensions
  edk2-pytool-library

Mike


> -----Original Message-----
> From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io] On Behalf Of Sean via Groups.Io
> Sent: Wednesday, May 22, 2019 11:46 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; 
> devel@edk2.groups.io
> Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv
> 
> Yes the plan would be to support both CI and local builds.  There is 
> actually more features related to support platform builds so I think 
> it would be better to keep ci out of the name.  The reason why 
> Tool-Env was suggested is the modules can be used to run anything 
> within the python environment not just builds.
> We have a git submodule update tool, external dependency management 
> tool (package mgmt/binary files), platform build tool, and CI build 
> tool.
> 
> Look at https://github.com/microsoft/mu_pip_environment
> and https://github.com/microsoft/mu_pip_build to get an idea of the 
> content proposed.
> 
> Thanks
> Sean
> 
> 
> 
> -----Original Message-----
> From: Kinney, Michael D <michael.d.kinney@intel.com>
> Sent: Wednesday, May 22, 2019 7:39 PM
> To: devel@edk2.groups.io; rebecca@bluestop.org; Sean Brogan 
> <sean.brogan@microsoft.com>
> Subject: RE: [edk2-devel] RFC for Edk2-ToolEnv
> 
> Hi Sean,
> 
> Does the PIP module here support both local platform builds and CI 
> builds?
> 
> I am looking at the name of the repo and trying to align with the 
> edk2-tools-library repo name so it is obvious the two repos are 
> related.  Maybe focus on the CI part for the name and we reuse the CI 
> features to simplify local builds.
> 
> 	edk2-tools-ci
> 
> Finalizing the name is the only open I am aware of.
> 
> Thanks,
> 
> Mike
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io] On Behalf Of
> > rebecca@bluestop.org
> > Sent: Tuesday, May 14, 2019 4:34 PM
> > To: Sean <sean.brogan@microsoft.com>; devel@edk2.groups.io
> > Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv
> >
> > On 2019-05-14 17:23, sean.brogan via groups.io wrote:
> > > Take a look at the proposed content and how it is
> > used.  We even have
> > > examples of calling from DevOps and i don't think
> > Jenkins would be any
> > > different.  I don't think we are trying to
> duplicate CI
> > > functionality.  We are providing the "last mile" so
> > that those CI
> > > engines can run EDK specific tests and
> tools.  Standard
> > CI engines
> > > have no concept of packages, DSC, FDF, INFs,
> firmware,
> > etc.
> >
> >
> > Okay, that's great. Of course we do also have lots of
> code running on
> > the CI server at work, not the client, that does
> things like packaging
> > etc., and this proposal will include server-side code
> too.
> >
> > Also, I don't think there is anything that'll be as
> nicely integrated
> > as this, so I'm happy with it.
> >
> >
> > --
> > Rebecca Cran
> >
> >
> >
> 
> 
>