4 ms·
Why would you want to update requirements.txt before testing against the new package version first? My dependency upgrade workflow for a Python web app is usua
by tedmiston 11y ago
Why would you want to update requirements.txt before testing against the new package version first?
My dependency upgrade workflow for a Python web app is usually:
run pip list --outdated
upgrade one package
run tests
if success
pip freeze to update this package (and its dependencies)
commit
else
investigate or revert and make a note for later (if many breaking changes, etc.)
Perhaps this could be useful if you're using tox to test against many versions of Python, e.g. for a library.
(Or if you only freeze top-level dependencies, even though that goes against best practices.)
- welder 11y agoSome of my projects have double digits dependencies in their requirements.txt file so upgrading one at a time, even with pip list --outdated, would take too long. I prefer to upgrade everything and fix things that break. I've always been able to easily figure out which dependency was causing the exception after upgrading all packages, so no point in upgrading them individually for me. Also, I don't manually update my packages. My build scripts do that for me from my requirements.txt file, so it makes sense to update requirements.txt first.
- tedmiston 11y agoMy main project has ~30. But still I prefer to go one at a time, especially with a major version bump, for the sake of understanding exactly what breaks. Perhaps it's just a personal preference.
- welder 11y agoYes perhaps :) I still look at the changelogs of all updated packages before running the upgrades.
- ubernostrum 11y agoSome of my projects have double digits dependencies in their requirements.txt file so upgrading one at a time, even with pip list --outdated, would take too long. The only solution I know of to this is to "unroll" all those dependencies into your own requirements.txt, and manage them the same way. For some projects I work with this is actually the only option, since I have to use requirements files with hashes and those are all-or-nothing -- even a single dependency-of-a-dependency that doesn't specify a hash will break the install, so I have to track down all of them and get a hashed entry into my requirements file.
- orf 11y agoTesting packages 1 by 1 finds any bugs and the exact package that caused it immediately, but you could just upgrade all of them and see if it fails. If it does a git-bisect could find the exact package that causes it. Seems optimizing for the happy path (nothing breaks) could save some time.
- emidln 11y agoThe tooling in Clojure land actually automated this (upgrade one dep, run tests, stop and back out if broken, continue otherwise). It would be neat seeing an equivalent of the lein-ancient plugin for Python, because this really is a PITA.
- michaelmior 11y agoThis makes updating all versions easy. You run a tool like Pur then run your tests. If they pass, you commit and push the requirements.txt changes.
- tedmiston 11y agoIf that's the desired behavior, it's already pretty easy by piping the outdated package list into upgrade. pip list --outdated | sed 's/(.*//g' | xargs pip install -U pip freeze > requirements.txt From http://stackoverflow.com/a/22260015/149428 http://stackoverflow.com/a/22260015/149428 Another similar easy option is pip-review. https://github.com/jgonggrijp/pip-review https://github.com/jgonggrijp/pip-review
- welder 11y agoI explained in more detail in another comment here, but I don't directly install requirements so install first solutions like pip-review and pip list --outdated don't work for me.