Title: How can I test Python virtual code environments programatically?
Tags: python,virtualenv,cicd,python-venv

Question: We manage a significant number of Python virtual code environments in our estate. We are moving to a more aggresive OS level patching schedule which means there is higher risk to break some Python virtual code environments due to some OS level dependencies changing or issues during installation. We are therefore looking at different options to try to mitigate this risk. Aside from recreating the virtual code environment after OS patching what else can we do to confirm the code environment it's working fine? Of course running the code/app/model that the code environment is meant to support would be ideal but this is not practical/possible for various reasons that are not relevant to the question.
I was thinking that perhaps I could look at the requirements.txt of each virtual code environment and attempt to import all packages that required to be installed in each virtual code environment. From previous experience the majority of virtual code environment issues happen either during the creation of the code environment (ie when packages are installed/code env created) or when the required packages are imported in code. So this approach will cover most of the risk leaving only potential run time issues which should be a very small proportion.
What's you view on this approach? Do you see any issues with it? One thing I know will be a challenge is that package names don't always match the "import" name used in code but I suspect we will be able to work around this problem building a dictionary of package names and import names.

Answer: If you update Python, of course you might end up with versioning issues. if these are dev machines, I'd strongly suggest you enforce a policy to update, but not push it on the dev without their knowledge.
If you don't upgrade Python, the only things that may break are the packages that are not pure python and depend on those OS level packages. Even then, most of those will have been compiled at installation and unless they dynamically load OS libraries that changed APIs after patching, they would not be affected.
So you are left with identifying python packages that have dynamic OS-level library dependencies, and focus on those. There is likely only a few projects that would belong in that category, and they are usually the ones causing developers installation problems, so they should be easy to identify ;-)
You can use pip inspect to get a full description of the packages and the location of their metadata
You can go list files in the site_packages folders and find out which project were built from non-python source that may require OS level libraries, and focus on trying to install those after patching.
If you don't want to sweat it and automate this, a full pip freeze > requirements.txt will give you all of the packages in the environment, and a simple test would be to re-create the environment and pip install -r requirements.txt
Beyond that, I'd assume developers will be in charge of making the code and dev environment work, and hopefully they use some reproducible environment for deployment (like containers) and local OS patching of their dev machine will be annoying but won't affect prod immediately.
If you're now talking about patching live servers that are not containerized, then definitely follow a pattern of patching in dev, then staging before pushing those changes to prod. Let the code base go through all the testing they normally do through on those patched OSs, and let the devs iron out the bugs for the environments. When and if it becomes more important that you push an OS patch immediately rather than to go through a full test cycle, then you can take that decision.