Testsuite fails if run independently outside of a virtualenv

[knobix]

If the testsuite is executed in a native build environment (= not in a virtualenv via tox) by issuing pytest it fails with:

ImportError while loading conftest '/wrkdirs/usr/ports/devel/py-oci/work-py36/oci-python-sdk-2.3.1/tests/conftest.py'.
tests/conftest.py:8: in <module>
    from tests.integ import util
tests/integ/util.py:12: in <module>
    from .. import test_config_container
tests/test_config_container.py:8: in <module>
    from . import vcr_mods  # noqa: F401
E   ImportError: cannot import name 'vcr_mods'

The testsuite will pass when the vcr_mods subdirectory from https://github.com/oracle/oci-cli/tree/master/tests/vcr_mods is copied to tests/:

=========== short test summary info ==========
SKIPPED [14] /wrkdirs/usr/ports/devel/py-oci/work-py36/oci-python-sdk-2.3.1/tests/conftest.py:41: Config file, /wrkdirs/usr/ports/devel/py-oci/work-py36/oci-python-sdk-2.3.1/tests/resources/config, does not exist
===== 20 passed, 14 skipped in 4.23 seconds =====

As far I can see only the following additional requirements are needed to get a successful run of the testsuite, so they could be added e.g. as tests_requires to setup.py:

• pytest
• requests
• vcrpy

It would be also nice to package the tests/ directory for the sdist so it would be available also via PyPI.

Environment:

• OS: FreeBSD 11.2-, 11.3-, 12.0-RELEASE
• Python Version: 2.7.16, 3.6.9

[jasonyin]

Hi @knobix , thanks for reporting the issue. Running SDK in virtual env is recommended as all of our tests/builds/verifications are done in that way, hence you will get more coverage if follow the installation guide here: https://github.com/oracle/oci-python-sdk#installation

I am trying to understand is there any reason not use virtual environment for it?

[knobix]

Hi @jasonyin ,

thank you for your info. Indeed, I'm aware of the fact that virtualenv is the recommended way as described in https://github.com/oracle/oci-python-sdk#installation .

Testing/Using the SDK outside a virtualenv gives downstream packagers the possibility to do proper QA to test the SDK against Python packages that are shipped locally.

In my case the Python SDK was added to the FreeBSD ports collection recently and as with many Python ports there it depends/uses local packages.

[jasonyin]

Got it. we will triage/prioritize this issue and will update you here, thanks!

[moraleslazaro]

The test suite fails even inside a virtual environment. There aren't any references to the module vcr_mods inside test_config_container.py, so even if the folder is copied over it won't be used. Flake8 warnings about that module not being used but the warning was suppressed with # noqa: F401 when the change was introduced. Maybe there was some intention in using the module later but I guess that intention didn't materialize since the module was never added to the tests/ folder.

[pabs3]

I encountered this while trying to package oci-python-sdk for Debian, would appreciate a fix for this. In the meantime I will apply the patch in #253 to remove it.

[major]

Same for packaging in Fedora. Thanks for the temporary patch. 🫂