When the recent_mock() utility was introduced, I may have missed the
fact that it would be possible to mock builtins.open().  Or, it may
be that was only possible in Python 3.

Anyway, now that we only support Python 3, let's just mock
builtins.open() and drop this custom decorator.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

And the compatiblity helper six.  With Python 2 gone, a number of
package changes are also introduced, so that the packages are always
named python3-<suffix>.

Also, because it would be confusing not having an "avocado" script,
and to conform with the system wide change introduced by distros that
now offer Python 3 by default, the scripts are no longer called
avocado-3 (or avocado-3.x), but simply "avocado".
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Instead of executing `lsmod`, the same information is available
in /proc/modules.  Also, add test to that function.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The same checks are performed repeated times.  Let's remove those.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

It's more common in our code (and pretty much around all Python
tests) to use the TestCase utility methods such as `assertEqual`
instead of doing `assert foo == bar`. Let's remove the few
occurrences of the `assert` idiom for cohesiveness.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

One of the unittests, namely `test_parse_lsmod_is_empty`, is implemented
as a static method, which should be fine because it doesn't use any class
attribute. But, there are a couple of problems.

First, it looks like the Python unittest library, while able to "discover"
such tests (implemented as static methods):

   $ python test_utils_linux_modules.py -v
   test_parse_lsmod (__main__.TestLsmod) ... ok
   test_parse_lsmod_is_empty (__main__.TestLsmod) ... ok
   test_parse_lsmod_no_submodules (__main__.TestLsmod) ... ok
   test_parse_lsmod_single_submodules (__main__.TestLsmod) ... ok

   ----------------------------------------------------------------------
   Ran 4 tests in 0.001s

   OK

It can not deal with it if its name is given explicitly. Example:

   $ python -m unittest test_utils_linux_modules.TestLsmod.test_parse_lsmod_is_empty
   Traceback (most recent call last):
     File "/usr/lib64/python2.7/runpy.py", line 162, in _run_module_as_main
       "__main__", fname, loader, pkg_name)
     File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code
       exec code in run_globals
     File "/usr/lib64/python2.7/unittest/__main__.py", line 12, in <module>
       main(module=None)
     File "/usr/lib64/python2.7/unittest/main.py", line 94, in __init__
       self.parseArgs(argv)
     File "/usr/lib64/python2.7/unittest/main.py", line 149, in parseArgs
       self.createTests()
     File "/usr/lib64/python2.7/unittest/main.py", line 158, in createTests
       self.module)
     File "/usr/lib64/python2.7/unittest/loader.py", line 130, in loadTestsFromNames
       suites = [self.loadTestsFromName(name, module) for name in names]
     File "/usr/lib64/python2.7/unittest/loader.py", line 122, in loadTestsFromName
       (obj, test))
   TypeError: calling <function test_parse_lsmod_is_empty at 0x7fb3f58129b0> returned None, not a test

While a bug should probably be filed on upstream CPython, we can't neither
should wait on a possible fix.

Second, it's much more common, and arguably more Python, to have non-static
methods as tests, so that unittest.TestCase methods can be called, such as
"assertEquals" instead of "assert foo == bar".

So, let's change this method to be a non-static one.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This is an automated mass import cleanup across all
avocado source files:

1) Imports follow the order:
 * Standard library imports
 * Non standard library external imports
 * Internal imports
 All separated by a single line
2) One line between imports and the rest of the code
3) Remove unused imports in the process
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Even though I may be the one to blame about coming up with this
"simple import magic", I believe it was a mistake and we should get
rid of them.

There are a couple of other ways to actually do development out of
of a source tree, including running unittests that do not require
this amount of boiler plate code. Examples include just setting
the PYTHONPATH environment variable to actually run (setuptools based)
`python setup.py develop`.

The little bits of what looks like the import magic that was left, is
not really import magic. It's just that functional tests need to locate
the Avocado source tree base directory to run the test runner from it.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

To be honest, our test code could still be kept in the same directories and
have the same names. But I think we can improve two things here:

1) Flatten a little bit the directory structure of selftests. Two path
components are being dropped here: "all" and "avocado". So that
"selftests/all/functional/avocado" becomes simply
"selftests/functional".

2) File names match what is, by default, recognized by unittest (the
Standard Library module) based discovery of tests. That means that
doc_build_test.py becomes test_doc_build.py. Not a big deal IMHO.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

On multiple places we modify the sys.path to make avocado work from
sources. Instead of `append` we should `insert` the path as when running
from avocado sources directory, we want to use the modules from here,
rather than from installed version.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

This library adds utility functions for linux kernel modules.
The functionality covers listing, loading and removing
loadable modules.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>