Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix tests that require isolation via virtualenv #239

Closed
wants to merge 39 commits into from

Conversation

abravalheri
Copy link
Collaborator

This PR attempts to solve #238.
In order to do so, it replaces pytest-virtualenv dependency by custom code based on stdlib's venv.
To workaround the apparent inability of venv to install pip when running from inside another venv, we use the global python3 available.

@abravalheri abravalheri force-pushed the fix-venv-tests branch 4 times, most recently from 32949c8 to 1254e7a Compare July 15, 2019 23:16
@@ -7,13 +7,17 @@ matrix:
fast_finish: true
include:
- os: linux
dist: xenial
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason, travis insists in using an old version of ubuntu, and this version have problems using apt (gpg keys issue)

@abravalheri
Copy link
Collaborator Author

I think I am happy with the code now. Sorry if I took me a while, every time we have a Travis issue, the process in painfully iterative.

To be fair, there are a few more things that this PR do:

  • Switch to Travis built-in way of installing packages instead of manually using apt or brew
  • Remove duplication for the system tests (e.g., before: a lot of run functions around, now: everything goes to the same run) and centralize helper functions/fixtures in a single place.
  • Remove test dependencies on pytest-shutils and pytest-virtualenv
  • Use stdlib's venv module to isolate tests
  • Better run helper (with better support to env and verbose
  • Remove workaround needed to make Pipenv (and other dotenv programs) work with pytest-virtualenv
  • Remove tests to ensure requirements.txt is installed.
  • Remove some unnecessary things since now we are using Python > 3.4

Unfortunately this PR also removes the ability of using coverage inside the venvs used during tests.

(P.S.: The falling test in Travis happens because we are trying to use Python 3.5 but we require 3.6 minimum)

@coveralls
Copy link

coveralls commented Jul 26, 2019

Pull Request Test Coverage Report for Build 1718

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 95.643%

Totals Coverage Status
Change from base Build 1701: 0.0%
Covered Lines: 1135
Relevant Lines: 1177

💛 - Coveralls

@abravalheri abravalheri force-pushed the fix-venv-tests branch 6 times, most recently from 4265747 to 1b05f12 Compare July 27, 2019 01:10
Python3 has the `venv` module built-in.
By creating a custom fixture using it, we have more control
and can address the limitations of the external package
This is a workaround instead of usinv `venv` python API,
since pip is never installed when the running python is already inside a
virtual env

Unfortunatelly running with coverage is not implemented
Since we are transitioning versions, any outdated extension will cause
the tests to break by introducing incompatible version ranges for
PyScaffold
… since it is more or less a system test anyway (end-to-end test)
… not installed by default in ubuntu
… so we avoid SSL errors
@abravalheri abravalheri force-pushed the fix-venv-tests branch 2 times, most recently from f09f785 to ea40b07 Compare July 27, 2019 12:47
… to check if the SSL error goes away...
… in an attempt to solve the SSL errors
… in yet other attempt to solve pip SSL errors.
… explicitly, since the other attempts to use env vars and a pip.conf/pip.ini
file do not seem to solve the SSL error in Windows [CI]
… so we can understand what else is going wrong
… because it seems that the SSL error in windows is not going anywhere...

(using the trusted-host flag, the associated env var or pip.ini in windows,
is enough to make pip work, however, `setup.py` seems to ignore all of that
and raise SSL errors)
Since get-pip does not solve the problem with the SSL certificates, this commit
returns to use `python -m pip install --upgrade pip`, because it should be
faster.

Additionally, it adds certifi, since a comment in pypa/pip#4156 points that
setuptools uses it to solve certificates...
… in system tests, as an attempt to solve of the errors described in pyscaffold#244
… the env var in `.cirrus.yml` should be enough, it is not necessary to repeat
it everywhere.
… in system tests, with a very naive conversion function
… for system tests.

This commit improves the previous one by removing the windows specific path
workarounds.
Instead of comparing the path that was found by `shell which` with the venv,
call `python which` restricting the search to the venv.
… in system tests. This way Python 3.5 can also be included.
@FlorianWilhelm
Copy link
Member

@abravalheri, thanks for this PR. I ported most of it to version 3.2.3 and the current v4.0.x branch. I stayed with pytest-virtualenv and it seems to works. Let me know if you want to have something else merged.

Going to Cirrus was a great idea btw. My suggestion would be to have a version 3.3 first with --cirrus and also update pyscaffoldext-custom-extension to use that instead of --travis. Also, all current extension should be updated first. After that, we could go on working on 4.0.

You can just close this PR if you think everything is ported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants