4 ms·
I sometimes fall into the trap of using pip to install dependencies and then things break after an os update. That is, my python version has changed from 3.8 t
by fullstop 5y ago
I sometimes fall into the trap of using pip to install dependencies and then things break after an os update. That is, my python version has changed from 3.8 to 3.9 and my dependencies are sitting in the wrong directory. I never know if I should use pip and requirements.txt or rely on Ubuntu's packaged versions.
- geofft 5y agoI used to have a rule of, never use pip and only use Ubuntu's/Debian's packaged versions. That works pretty well if you're happy with the packaged versions and you don't need unpackaged libraries. I now have the rule of, only ever use pip inside a venv. If your venv is more than a little bit complex, write a requirements.txt file so you can generate it. So it's something like $ cat > requirements.txt << EOF tensorflow Django==3.2.5 cryptography EOF $ echo venv > .gitignore $ python3 -m venv venv $ venv/bin/pip install -r requirements.txt $ venv/bin/python or, if you prefer, $ . venv/bin/activate (venv)$ pip install -r requirements.txt (venv)$ python Then when your Python version changes, or you get confused about what's installed, or whatever, you can just blow away the entire venv and recreate it: $ rm -r venv $ python3 -m venv venv $ venv/bin/pip install -r requirements.txt and you're in a known-good place. Either of these rules works fine. The thing that works poorly is using pip install outside of a venv (with or without root).
- trulyme 5y agoFor me the rule is to always use pipenv locally and pip + requirements.txt (generated by pipenv) for production (in docker container usually). No complaints.
- mixmastamyk 5y agoJust pip install again under new interpreter. Use distro versions if a script will primarily run there, and ok if an older version.