If you are using a virtual environment and have a decent enough test suite that you can repeatedly and automatically run (it's best if you can run it on your local workspace via a script or a simple command), then the brute-force type of approach is to:
- Setup a fresh copy of your project (ex.
git clone onto a separate folder)
- Setup an empty/blank virtual environment
- Run your tests
- Install missing packages every time you encounter a "ModuleNotFoundError" type of error
- Repeat until all tests passes
- Export the packages you now have to a separate requirements.txt file (
pip freeze > requirements.new.txt or any of the other ways from Automatically create requirements.txt)
For example, we have this (very) minimal example code:
# --- APP CODE
from numpy import array
from openpyxl import Workbook
from pydantic import BaseModel, ValidationError
class MyModel(BaseModel):
x: int
# --- TEST CODE
import pytest
def test_my_model():
with pytest.raises(ValidationError):
MyModel(x="not an int")
After cloning this and setting up a brand new fresh virtual environment (but without yet installing any of the packages), the 1st attempt to run the tests yields:
(my_venv) $ pytest --maxfail=1 main.py
bash: /Users/me/.venvs/my-proj-7_w3b8eb/bin/pytest: No such file or directory
So then, you install pytest.
Then, you get:
(my_venv) $ pytest --maxfail=1 main.py
...
main.py:1: in <module>
from numpy import array
E ModuleNotFoundError: No module named 'numpy'
So then you install numpy.
Then, you get:
(my_venv) $ pytest --maxfail=1 main.py
...
main.py:2: in <module>
from openpyxl import Workbook
E ModuleNotFoundError: No module named 'openpyxl'
So then you install openpyxl.
...and so on. Until all the tests passes. Of course, even when your automated tests pass, it's good to also do some manual basic tests to make sure everything is indeed working as before. Finally, generate a new copy of your requirements.txt file, and compare that with the old one, to check for any differences.
Of course, as I mentioned at the start, this assumes you have a decent enough test suite that tests a large % of your code and use cases. (It's also one of the good reasons why you should be writing tests in the first place.).