Re: [Fuego] [PATCH 2/4] linaro: update to python3

<[email protected]> Fri, 27 Aug 2021 21:48:56 +0000
Newsgroups dev.linux.lists.fuego
Message-ID <BYAPR13MB25031E385C3D20DA783F67FEFDC89@BYAPR13MB2503.namprd13.prod.outlook.com>
Tho,

I just did a long-winded answer to Daniel on this topic.  Please see that e-mail.
(But in summary, I'd like to split this change up - some in install and some in the test.)
 -- Tim


> -----Original Message-----
> From: [email protected] <[email protected]>
> 
> Dear Tim,
> 
> > If a better python3-pip is needed for building, I think this should go into the installation scripts, unless this is intended to be doing
> something on the device under test, and not the host.
> I will move linaro's dependencies to https://bitbucket.org/fuegotest/fuego/src/master/install-scripts/install-debian-common.sh.
> What do you think?
> 
> Thanks,
> Tho
> 
> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: Friday, August 27, 2021 12:54 AM
> To: sangorrin daniel(サンゴリン ダニエル □SWC◯ACT) <[email protected]>
> Cc: [email protected]; nguyen dat tho(TSDV Eng 1) <[email protected]>
> Subject: RE: [PATCH 2/4] linaro: update to python3
> 
> Ok - I went to apply this today, and I realized I still have some questions...
> 
> See inline below.
> 
> 
> > -----Original Message-----
> > From: Daniel Sangorrin <[email protected]>
> >
> > From: Nguyen Dat Tho <[email protected]>
> >
> > The upstream linaro repository[1] now uses python3 so use pip3 to
> > install the requirements
> >
> > [1] https://github.com/Linaro/test-definitions
> >
> > Signed-off-by: Nguyen Dat Tho <[email protected]>
> > Signed-off-by: Daniel Sangorrin <[email protected]>
> > ---
> >  tests/Functional.linaro/fuego_test.sh | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/Functional.linaro/fuego_test.sh
> > b/tests/Functional.linaro/fuego_test.sh
> > index 677ab49..c775baa 100755
> > --- a/tests/Functional.linaro/fuego_test.sh
> > +++ b/tests/Functional.linaro/fuego_test.sh
> > @@ -26,8 +26,10 @@ function test_pre_check {  }
> >
> >  function test_build {
> > +    apt-get install python3-pip
> >      source ./automated/bin/setenv.sh
> > -    pip install -r $REPO_PATH/automated/utils/requirements.txt --user
> > +    pip3 install setuptools --user
> > +    pip3 install -r $REPO_PATH/automated/utils/requirements.txt
> > + --user
> >  }
> 
> What is the effective user account when this is run in Fuego non-container mode?
> 
> For non-container execution, do you execute build steps as user 'fuego'
> or 'jenkins'?  For a container environment, the build steps are performed as user 'jenkins'.  Will these steps even work, in that environment?
> 
> Does this need to be 'sudo apt-get install', to handle the container case?
> 
> Do the pip3 operations work at the system level, or at the level of an individual account.
> 
> If a better python3-pip is needed for building, I think this should go into the installation scripts, unless this is intended to be doing something
> on the device under test, and not the host.
> 
> This will have a permanent effect on the build environment, for either the container, or the host machine where Fuego is running.
> 
> In your test environment, is the host machine the same as the device under test, so that these changes are thrown away when the image is
> thrown away?  Or is this persistent?
> 
> It seems like there should be a check to avoid re-installing these, if they are already present.  But maybe "apt-get install " or "pip3 install"
> will just issue a warning, and there is not harm to executing these if the packages are already there.
> 
> Anyway, as  you can tell, I am confused by this patch.
> 
> Overall, I don't object to it.  I just want to understand what's happening with pip3 installation and setuptools installation at the user level
> and system level, for the case where:
>  - the test is executing in a Fuego container, with a remote DUT
>  - the test is executing in a Fuego container, with a local DUT (DUT=self)
>  - the text is executing natively, with a remote DUT
>  - the test is executing natively, with a local DUT (DUT=self)
> 
> Thanks,
>  -- Tim