SecureDrop right now runs on Ubuntu Xenial. We are working on moving to Ubuntu Focal. Here is the EPIC on the issue tracker.
While I was creating the Docker development environment on Focal, I noticed our tests were failing with the following message:
Traceback (most recent call last):
File "/opt/venvs/securedrop-app-code/bin/pytest", line 5, in <module>
from pytest import console_main
File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/pytest/__init__.py", line 5, in <module>
from _pytest.assertion import register_assert_rewrite
File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/_pytest/assertion/__init__.py", line 8, in <module>
from _pytest.assertion import rewrite
File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/_pytest/assertion/rewrite.py", line 31, in <module>
from _pytest.assertion import util
File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/_pytest/assertion/util.py", line 14, in <module>
import _pytest._code
File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/_pytest/_code/__init__.py", line 2, in <module>
from .code import Code
File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/_pytest/_code/code.py", line 29, in <module>
import pluggy
File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/pluggy/__init__.py", line 16, in <module>
from .manager import PluginManager, PluginValidationError
File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/pluggy/manager.py", line 6, in <module>
import importlib_metadata
File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/importlib_metadata/__init__.py", line 471, in <module>
__version__ = version(__name__)
File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/importlib_metadata/__init__.py", line 438, in version
return distribution(package).version
File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/importlib_metadata/__init__.py", line 411, in distribution
return Distribution.from_name(package)
File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/importlib_metadata/__init__.py", line 179, in from_name
dists = resolver(name)
File "<frozen importlib._bootstrap_external>", line 1382, in find_distributions
File "/usr/lib/python3.8/importlib/metadata.py", line 466, in find_distributions
found = cls._search_paths(context.name, context.path)
AttributeError: 'str' object has no attribute 'name'
make: *** [Makefile:238: test-focal] Error 1
Found out that pluggy
dependency is too old. We update all application dependencies whenever there is a security update, but that is not the case with the development or testing requirements. These requirements only get installed on the developers' systems or in the CI. Then I figured that we are using a version of pytest
3 years old. That is why the code refuses to run on Python3.8
on Focal.
The update hell
Now, to update pluggy
, I also had to update pytest
and pytest-xdist
, and that initial issue solved. But, this broke testinfra
. Which we use in various molecule
scenarios, say to test a staging
or production
server configurations or to test the Debian package builds. As I updated testinfra
, molecule
also required an update, which broke due to the old version of molecule
in our pinned dependency. Now, to update I had to update molecule.yml
and create.yml
file for the different scenarios and get molecule-vagrant
0.3. Now, after I can run the molecule
scenarios, I noticed that our old way of injecting variables to the pytest
namespace via pytest_namespace
function does not work. That function was dropped in between. So, had to fix that as the next step. This whole work is going on a draft PR, and meanwhile, some new changes merged with a new scenario. This means I will be spending more time to rebase properly without breaking these scenarios. The time takes to test each one of them, which frustrates me while fixing them one by one.
Lesson learned for me
We should look into all of our dependencies regularly and keep them updated. Otherwise, if we get into a similar situation again, someone else has to cry in a similar fashion :) Also, this is difficult to keep doing in a small team.
from Planet Python
via read more
No comments:
Post a Comment