[tbot] [Discussion] Calling tbot from within the source directory

Harald Seiler hws at denx.de
Thu Nov 29 11:33:42 UTC 2018


On Thu, 2018-11-29 at 10:47 +0100, Stefano Babic wrote:
> On 29/11/18 10:41, Claudius Heine wrote:
> > Quoting Claudius Heine (2018-11-29 10:20:43)
> > > Hi Harald,
> > > 
> > > Quoting Harald Seiler (2018-11-29 10:01:34)
> > > > > > then you could use the current working directory in your testcases, so
> > > > > > you would not need an additional parameter or environment variable to
> > > > > > point the the source-tree if you want to avoid having the path to it
> > > > > > inside the testcases.
> > > > > > 
> > > > > > I hope I made myself understandable, but I basically I would like to
> > > > > > kill multiple birds with one stone:
> > > > > > 
> > > > > >  1. Make calling tbot from outside the tbot configuration directory
> > > > > >  easier.
> > > > > >  2. Make it possible to use cwd inside testcases to point to the
> > > > > >  source-tree -> make it easier to reuse/share testcases because they
> > > > > >  would not need to contain the path to the source tree anymore.
> > > > > 
> > > > > I can just imagine that you need, but if you could draft a simple real
> > > > > testcase here, it is easier to understand the reasons.
> > > > 
> > > > I think I can see what Claudius is on about here.  The thing is, you
> > > > shouldn't use `cwd` in your testcases, because it doesn't honor the specified
> > > > lab.  Instead you should use `lh.workdir`, which is a proper tbot path
> > > > and it's value should be defined in the lab-config.
> > > 
> > > Ok, I think I get you here. You cannot do that, since the source/build
> > > products might be somewhere else, not on the machine running tbot.
> > > 
> > > But I would also argue that the path to a specific project is not a lab
> > > or testcase configuration. It should be part of the user and project specific one.
> > > 
> > > So I think I currently don't know enough about tbot to know where to
> > > best put this kind of configuration. Maybe we have to implement some
> > > sort of configuration file support in tbot then.
> > 
> > Just a suggestion from me, calling tbot like this:
> > 
> >   tbot -c config.ini my-testcase
> > 
> > Where the ini file would contain something like this:
> > 
> >   [tbot]
> >   verbose=2
> >   cwd=/home/user/work/tbot/tbot-myproduct
> >   lab=lab/my-lab.py
> >   board=board/my-board.py
> >   flags=flag1 flag2
> >   testcase=my-default-testcase
> > 
> >   [project]
> >   sources=work/source/my-project-source
> >   outdir=work/source/my-project-source/out
> >   nfsdir=/srv/nfs/my-project/user/
> >   tftpdir=/srv/tftp/my-project/user/
> > 
> > What do you think?
> 
> See start of the thread, it was already proposed, but Harald prefers to
> avoid such as configuration file.

I think, I should elaborate on why:

As I mentioned in my talk, the version of tbot you know is actually the second
rewrite.  The first one had an extensive configuration system, supporting
overlaying different config files, having configs depend on each other, and
generating config values on the fly from python code.  The reason it got so
complex was because I stumbled upon a lot of edge-cases that needed special
handling.

It worked.  But it wasn't pretty.  And it was really hard to reason about.
I was just short of adding something like `bitbake -e` which would allow
you to trace where each value came from.

When I decided I need to restart the project again, I took some time to embrace
the core principles of python [1] and to think about how they apply to tbot.

I decided to throw out the configuration file idea completely.  I decided that
the most value is gained from tbot through bullet proof machine interaction and
that I leave everything else up to the user.  Configuration is one such thing.
For the lab and board there isn't really a way around it (although you could
also just define your board classes in your testcase source file without issues ...
it really is about convenience in this case).
  But for anything more I feel like it shouldn't be tbot's job to handle it.

As I showed in the dcu-repo (only visible to Claudius), a user that needs to
have config for each developer can add a config mechanism using pythons
builtin `configparser`.  This has two advantages:

	1. tbot can stay small and focus on its core job: Machine Interaction

	2. A user that is not content with just a `configparser` based config
	   can easily decide to switch to something different.  You could even
	   think about pulling the config via network if that is what you want ...

If tbot were to provide a config mechanism, I see two things happening:  For one,
people who don't know about this or need something more complex will still use their
own implementation (this violates "There should be one-- and preferably only one
--obvious way to do it." from the Zen).  On the other hand, people would need more
and more complex features added to this part of tbot which would take away time from
actually improving the parts of tbot that count.

To quote the unix philosophy:

	Do one thing and do it well

There are already many existing python modules that handle configuration very well,
so I think adding another implementation in tbot would be counterproductive.

Harald

[1]: https://www.python.org/dev/peps/pep-0020/

> 
> Stefano
> 
-- 
Harald

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-62  Fax: +49-8142-66989-80   Email: hws at denx.de


More information about the tbot mailing list