On Tue, 2010-11-09 at 12:59 -0500, Kamil Paral wrote:
Martin played a little today with AutoQA and discovered that he
can't
run our watchers if he uses autotest_lib module inside them.
The reason wasn't clear for me immediately, so I look at it a little
closer.
The reason is that autotest libraries are not in a standard Python PATH.
The only way to gain access to autotest_lib module is to import
/usr/share/autotest/client/bin/common.py. And that happens only when
you run autotest tool, like this:
# autoqa post-koji-build -k dist-f14 foo -t helloworld --local
-- or (subsequently) like this --
# ~autotest/client/bin/autotest /tmp/autoqa-control.9xlSGi
Definitely something specific to the peculiar way that autotest is
packaged. I can see why, it makes sense for their project to be
portable to any directory. Just import the common module, and it will
do the dirty work of finding the remaining libraries and setting up
sys.path. Since most of our work is specific to a single distro, we
obviously like things to be in their standard locations.
For those scripts that we want to run outside autotest environment
(like watchers, autoqa script itself, stand-alone parts of our tests)
we can't use autotest_lib module, we have to rely just on our autoqa
library (and more specifically on those parts of our autoqa library
that don't rely on autotest_lib themselves).
So I just want to point out that if you see this kind of problem,
this is the reason.
The question remains - is this desirable or not desirable? Would we
like to see autotest modules be accessible as a standard Python module?
Do we need it?
I may not fully understand the problem, but I don't think we should need
to integrate watchers with autotest. Was there a specific need to
integrate the watcher with autotest?
Additionally, I get nervous when we integrate out test scripts with
autotest. Obviously, we need to integrate with the current test harness
to some degree. However, I want to make sure we understand the links
and they are documented well in the event we need to swap out for a
different back-end harness/scheduler.
This does help clarify though which files can link to autotest and which
cannot. Obviously, the control file and the test object file can link
against autotest. But any test script should be stand-alone. For
example, tests/conflicts/potential_conflict.py and
tests/rpmguard/rpmguard. They were designed to be run stand-alone on a
system and shouldn't link with autotest at all. Am I correct?
I don't think we need it right now, just some food for thought.
Definitely, thanks for pointing this out!
While researching packaging autotest, the packager will have to answer
this question of why aren't some files in standard system locations.
I've been assuming that answering that question is a distinct effort
from anything going on with our autoqa work. Did I get that wrong?
Thanks,
James