4:09 a.m.
----- "James Laska" <jlaska(a)redhat.com> wrote:
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.
You're right, that works. I can do something like:
# PYTHONPATH=/usr/share/autotest/ python
>> import client.bin.common
>> import autotest_lib
>>
So if we have the right PYTHONPATH (which we can solve by installing
a .pth file into /usr/lib/python/site-packages) and if we keep the right
order of imports (common.py first), we can use autotest libraries also
outside the autotest process itself.
> 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?
I don't think there was a strong need for it and I don't think it would
be wise. We just found it by coincidence.
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?
Yes, I have the same opinion. If it is doable and reasonable we really
should have a standalone test script that doesn't rely on autotest.
In some cases, however, we have put the logic directly into the test
object (e.g. upgradepath test), because it seems like a best approach
in those scenarios (although it has some disadvantages).
> 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?
I am not sure. I think the current state (non-standard location)
is sufficient for us, at least for now.
8:15 a.m.
New subject: autotest_lib can't be used outside autotest process
On Wed, 2010-11-10 at 05:09 -0500, Kamil Paral wrote:
----- "James Laska" <jlaska(a)redhat.com> wrote:
> 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.
You're right, that works. I can do something like:
# PYTHONPATH=/usr/share/autotest/ python
>>> import client.bin.common
>>> import autotest_lib
>>>
So if we have the right PYTHONPATH (which we can solve by installing
a .pth file into /usr/lib/python/site-packages) and if we keep the right
order of imports (common.py first), we can use autotest libraries also
outside the autotest process itself.
Very cool! That may have just made packaging autotest a bit simpler.
So rather than fiddle with breaking how autotest is currently packaged,
I can stuff a .pth file into /usr/lib/python/site-packages/autotest.pth.
Thanks, I'll look into this when we need to cut a new version of
autotest.
http://docs.python.org/install/index.html#inst-search-path
Thanks,
James
4956
days inactive
4956
days old
autoqa-devel@lists.fedorahosted.org
1 comments
2 participants
participants (2)
-
James Laska -
Kamil Paral