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