Analyzing Django requirement files on GitHub
pyup.io
pyup.io
Probably because 95% of projects on GitHub are homework assignments for job interviews that never get updated after they're submitted.
Something related that would be nice though is having pip list -o only output dependencies in the requirements.in file if it exists, or else that are primary dependencies.
My development environment is not pinned. When I set up CI, I do it with bot pinned (as it goes to production) and unpinned (from dev) requirements, both generated using pip-chill.
Jay (at PyUp) - any idea?
I'll write a follow up post on this :)
Sometimes you can build a small but profitable business and not do everything right from a technical perspective.
Still, you'd never see the code on a public Github repo.
These are more likely Django apps... it'd be interesting to consider how many of them shouldn't even be mentioning Django at all in their requirements.txt files to avoid clashing with the Django version of the project you're importing their app into.
setup.py is for specifying dependencies of a piece of code you're distributing, while requirements.txt is for specifying a known-good environment to run a piece of code in.
For example, my own personal site has a requirements.txt specifying Django 1.11.2 because that's the version I'm deploying on and test it on. But it uses several applications I've written and distribute, and those use setup.py to specify a dependency on Django 1.8, 1.10 or 1.11 (and those all use tox/Travis to test on the full matrix of Python and Django versions they support).
Not sure how this short article could have rocketed to the very top of the front page so quickly, though...
For those not familiar with django's release history the 1.6 -> 1.7 major release was a very large change in terms of how database migrations are handled. In 1.6 (and earlier) there was no built in too for it, but a very popular django extension library called South was the standard. In version 1.7 the creator of South (Andrew Godwin) wrote a migration tool for django core that was based on his previous work with South. There is a migration path from South to django core migrations and it's not that scary to do but it's a little work. That was several years ago at this point though. I wonder if some projects just abandoned upgrading at 1.6 because of this.
Though you're right that people tend to "stick" on a version where the next step up is a trickier upgrade. That's happened a couple times in Django's history -- a lot of early deployments (pre-1.0) pinned for a long time on 0.91 since the Django ORM got completely rewritten for 0.95.
And post-1.0, the switch to class-based generic views also left some people behind. 1.11 is likely to be "sticky" too since it's the last version that will support Python 2 (the next release -- Django 2.0 -- will be Python-3-only, and 1.11's LTS support cycle is timed to expire when upstream support for Python 2.7 does).