These files weren't being installed by the setup.py code, and thus
ended up missing from RPM packages.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

In a pure Python world[1] the "avocado" module requires the existence
of these configuration files.  Let's make those configuration files
"data files" of that module.

Since the configuration location can now be a different, the settings
module needs adjustments to also attempt to load them from package
resources (which is tied to the data files).

Finally, when using RPM packages, we need to put the configuration
back into the system location (/etc).

[1] - that is, ignoring operating system or distribution specific
      conventions and packaging technologies
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

* https://github.com/avocado-framework/avocado:
  avocado/core/job.py: don't attempt to run git if .git doesn't exist
  Revert "avocado/core/job.py: don't attempt to run git if .git doesn't exist"

When looking for the GIT commit info to log in the Avocado job log,
we can optmize things a little by not running git if the ".git" directory
doesn't exist at the top level.

py2to3 is not being used anymore, so we don't need to check if we're
running from modules from the build directory.

Also, as another optmization, let's not look for the git binary until
we're sure we'll be running it.

Update: Use abspath to get "base_dir" location to avoid using "" when
avocado is executed from main git directory.
Signed-off-by: NCleber Rosa <crosa@redhat.com>
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The 6323773d commit breaks avocado
execution from head of the git source as the base_dir is "" and then
"os.chdir" fails.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Signed-off-by: NAmador Pahim <apahim@redhat.com>

Signed-off-by: NAmador Pahim <apahim@redhat.com>

Signed-off-by: NAmador Pahim <apahim@redhat.com>

When looking for the GIT commit info to log in the Avocado job log,
we can optmize things a little by not running git if the ".git" directory
doesn't exist at the top level.

py2to3 is not being used anymore, so we don't need to check if we're
running from modules from the build directory.

Also, as another optmization, let's not look for the git binary until
we're sure we'll be running it.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Let's break down the types and description of the CmdResult init
method.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

We're (hopefully) about to change the specifics about the Python
versions we support.  But, until then, let's be clear about the
Python version (2.7) that we support.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

pyliblzma is not required in python >= 3.3, and backports.lzma
works for all versions prior to that one. Let's update
the requirements.txt file to only install that backport
when necessary.
Signed-off-by: NLucas Meneghel Rodrigues <lookkas@gmail.com>

Python wheel packages are really convenient.  Let's create and
distrubute them in addition to the source packages.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

* https://github.com/avocado-framework/avocado:
  avocado/core/loader.py: implement ordered test discovery

Because only package based installs (such as RPM) will probably build
and install them.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

And move that information to the documentation directory, where people
will probably look for instructions if they feel like building the
docs.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Which is also supposed to be the most universal installation
method: pip based installs in the user's own directories.

Then, give information on virtual environment based installations.

The README file was missing the section on pip based installs, so
let's add it there.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

* https://github.com/avocado-framework/avocado:
  spell: comply with new checks

Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

* https://github.com/avocado-framework/avocado:
  vmimage: add JeOS Image Provider

Signed-off-by: NAmador Pahim <apahim@redhat.com>

make spell is now covering more cases. This patch fixes the actual spell
errors and adds the required exceptions.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

The docstring given on `_greedy_path()` has examples that don't match
the implementation.  To prevent the implementation from deviating
(again?) let's turn those into tests.

Also, to make the purpose of that function more clear, this
changes its name to `_greedy_path_to_re()`.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The order in which test classes and methods are found is relevant
to the loader result.  Currently, this ordering is not dependable
as the loader findings are stored on a regular dictionary.

This change makes the ordering dependable, and so happens to also
make the test pass on a Python 3 environment.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

WIth the new repository, now it is possible to add our own JeOS Image
Provider to the vmimage module.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

Signed-off-by: NAmador Pahim <apahim@redhat.com>

Signed-off-by: NAmador Pahim <apahim@redhat.com>

"file" is not available on python3, let's use "open" to get file
instance.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The subprocess.DEVNULL is not available on Python2.

This reverts commit e51acbfa.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

examples/tests/gdbtest.py already imports the portable range() from
the six library, but was not using it.  Let's fix this.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

That is already used when the detected version is Python 3, but
pylint doesn't know about it, so let's make it ignore that.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

avocado.utils.external.gdbmi_parser uses `cmp` which is Python 2 only.
Let's use the simple recipe for Python 3 compatibility as per
https://docs.python.org/3.0/whatsnew/3.0.html#ordering-comparisons .
Signed-off-by: NCleber Rosa <crosa@redhat.com>

On Python 2, input() has a different behavior, including an evaluation
of the obtained string.  On Python 3, it just returns the stripped
string.

Let's hand off the difference handling to six.

PS: we won't use use six.moves.input() on the failtest_ugly.py file,
given that it's intended to be a bad example.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The current syntax is incompatible with Python 3.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NAmador Pahim <apahim@redhat.com>

Signed-off-by: NAmador Pahim <apahim@redhat.com>

Signed-off-by: NAmador Pahim <apahim@redhat.com>

A few extra configurations needed for the Python 3 builds running on Travis-CI.
Signed-off-by: NLucas Meneghel Rodrigues <lookkas@gmail.com>

Merge branch 'travis_configuration_python3' of https://github.com/clebergnu/avocado into clebergnu-travis_configuration_python3

The environment that Travis-CI sets up is somehow broken with regards
to the requirements for six.  The exact message we get and running
selftests/run is:

   pkg_resources.ContextualVersionConflict: (six 1.9.0
   (/home/travis/virtualenv/python3.4_with_system_site_packages/lib/python3.4/site-packages),
   Requirement.parse('six>=1.10.0'), {'Fabric3'})

Let's bump the requirements to 1.10.0, to try to help Travis-CI.
Signed-off-by: NCleber Rosa <crosa@redhat.com>