Setup python paths in test runner configuration

[jsoriano]

Add conftest.py files to projects with python tests. This file is imported by the test runner. Use it to setup python paths so tests don't need to care about them depending on where they are located, and we control paths from central points.

[elasticmachine]

Pinging @elastic/integrations (Team:Integrations)

[elasticmachine]

💚 Build Succeeded

Expand to view the summary

Build stats

• Build Cause: [Pull request #20832 updated]

• Start Time: 2020-08-27T21:36:32.851+0000

• Duration: 65 min 59 sec

Test stats 🧪

Test	Results
Failed	0
Passed	15289
Skipped	1761
Total	17050

[andrewkroh]

I would prefer to have the import statements match the project structure so that when you see an import statement you can know exactly where the file is coming from (like import libbeat.tests.system.beat.compose). Then the only addition to sys.path is the repository root. Would it be possible to implement that? Would you still need one conftest.py for every beat project?

[jsoriano]

I would prefer to have the import statements match the project structure so that when you see an import statement you can know exactly where the file is coming from (like import libbeat.tests.system.beat.compose). Then the only addition to sys.path is the repository root. Would it be possible to implement that? Would you still need one conftest.py for every beat project?

It is not very common to have so long import paths in python. Usually the modules are in some path, and one adds this path to their python path.
An extra problem is that all the intermediary paths need to be modules too, so for libbeat.test.system.beat.compose to work, we would need to add some empty __init__.py files:

libbeat/__init__.py
libbeat/tests/__init__.py
libbeat/tests/system/__init__.py

Something we could do if we want to have a single conftest.py file instead of one per project, is to move all python modules we have to some common path (dev-tools/python?), and include this path from a single conftest.py in the root of the project. We would need to slightly refactor packages used in x-pack. I will give a try to this option. @andrewkroh wdyt about this option?

[jsoriano]

I would prefer to have the import statements match the project structure so that when you see an import statement you can know exactly where the file is coming from.

Another problem with this is that we have python code under directories with hyphens (x-pack), that are not allowed in python module names.

In [9]: import x-pack
  File "<ipython-input-9-1b6cd5801f44>", line 1
    import x-pack
            ^
SyntaxError: invalid syntax

[andrewkroh]

Thanks for explaining the reasons why my suggestion would not work. I'm not much of a python developer (nor do I want to be 😆 ). I think this approach of moving the sys.path manipulation out of the code is clean.

[jsoriano]

I am merging this as it removes python path configuration from tests, what I think is an improvement.
As a future improvement, we could still look for ways of not needing a conftest.py file per project.