Develop Reference

Upgrading Django Version: Best Practice

I've pretty big code base written on Django 1.5, it's about time to upgrade to the newest version (1.11.2) as many stuff don't work well.
I'm wondering if it's best to upgrade step by step: 1.5->1.6->1.7...
or just jump to 1.11.2
what method should be better and make the (hard) process easier? as my project has many dependencies?
Also what are good practices to do? I'm using virtualenv and aware of this Django article about upgrading

The document you found (“Upgrading Django to a newer version”) has a good guide.
An important part, before upgrading, is to have full branch coverage by the automated test suite for your application, before upgrading.
You want to be able to run a full automated test suite, see everything pass and know that all branches are exercised by the test suite.
This means that when you break something by porting to the new Django version, you'll be able to see which parts of your app are not behaving correctly any more.
Read about what changes you need to make by reading the release notes and deprecation timeline, for all of the relevant releases between your current and target Django versions.
See what dependencies you'll need to upgrade for Django; you might need to correct your code if it relies on incompatible features in an outdated third-party library.
All of those should be done before upgrading a single thing, in my opinion.

It depends on two things. How many people are using the Django app, and the extend of your test coverage.
If you are the only user, no worries, upgrade all the way. But if you have a lot of users you will quickly find out by upgrading all the way to 1.11.2 that some edge cases may not be covered by your tests.
Expect a lot of error 500 along the way.
If your coverage is close to 100% on all your apps, you may not have that problem.
Note that a lot has changed since 1.5.

I my case about: Data
I am using SQLite and i am sure that, the lastest version can kill you if you have only 1 conflict.
python manage.py makemigrations and so on had so many chance in it's method.
And if you change Python from 2x to 3x, it is a new case too =))

Is there way to check feature deprecation against django version?

As some features get deprecated with new versions of Django, is there a way to check for that on an existing project code say on github.
Could a tool do that. Is there a way to detect that through testcases.
Would it be possible to do the same against a python version.
I guess one way could be to run through a specific version of django / python using tox and then check for errors.
I am just looking for something more elegant or direct, something like which says - "Note this feature has been deprecated", something which can be done in strongly typed language like Java.
If one wanted to build such a tool, what could be starting point for that, if possible.

This is how I got tox to run one project of mine against Django 1.6, 1.7 and 1.8 with deprecation warnings on:
[tox]
envlist = {py27,py34}-{django16,django17,django18}
[testenv]
basepython =
py27: python2.7
py34: python3.4
deps =
django16: Django>=1.6,<1.7
django17: Django>=1.7,<1.8
django18: Django>=1.8,<1.9
commands =
python -Wmodule ./manage.py test
The -Wmodule argument causes Python to output each deprecation warning the first time it occurs in a module, which was good enough for me. I was able to deal with instances where I used from django.core.cache import get_cache, which will be gone in Django 1.9.
In cases where -Wmodule outputs too much, you might want to be more selective. Python's documentation gives the lowdown on how to use this argument. I've purposely not used -Werror because this would not just make the individual tests fail but would make my test suite fail to execute any test because the suite uses deprecated features.

I think this would have to be in the unit tests for your project.
If your tests exercise code that will be deprecated in a future version of Django you will get warnings. If you've jumped to a version of Django where the feature is already deprecated you'll get exceptions and failed tests of course.
You can tell the Python interpreter to promote warnings to exceptions, which would cause tests to fail.
Instructions here to apply the same trick to the popular nosetests test framework.
If you know already (from Django docs) that some code you're writing will need to change depending on Django version it is run under (eg you're distributing a reusable Django app) I would suggest a form of feature detection using try ... except
For example, here I wanted to conditionally use the new transaction.atomic feature from Django >= 1.6: .
As you anticipated, I then run the tests against different versions of Django with the help of Tox.

Non-django analogue to manage.py

I'm looking for some python package providing basic functionality for writing and executing project-specific commands using some common interface. There is no problem to write it myself, but I already saw a project like this somewhere, so would you help me to remember it?

Maybe you are thinking of paster?

fabric can do this but it's more geared towards deployment and other such tasks. Scons is a build tool similar to make which can have custom commands. Paver is also like make/rake for doing things like this. You can also add custom commands to the distutils setup.py script. The standard libary cmd module is a lighter version.

You could use the new argparse package which is a standard Python package to parse command line options http://docs.python.org/library/argparse.html#module-argparse
Django's manage.py probably uses that as well but I have not looked at the code so I can't confirm.

How does django-nose differ from the default Django test-runner

I've been seeing and reading about a lot of people using nose to run their Django tests. I haven't been able to figure out the added benefits of using Nose to run my Django tests. If someone could fill me in on what nose is and how it adds more to a Django project, it would be helpful.
I haven't been able to find a good document/article outlining these points.
Thank you

I was curious about this too and it seems that the main advantage of django-nose using the python nose library is "Test Discovery".
In addition, from http://readthedocs.org/docs/nose/en/latest/testing.html
you can also write simple test functions, as well as test classes that are not
subclasses of unittest.TestCase. nose also supplies a number of
helpful functions for writing timed tests, testing for exceptions, and
other common use cases. See Writing tests and Testing tools for more.
From what I understand from other python developers on freenode irc, Trial test runner on Twisted Framework have these similar features like nose.
I am still not entirely convinced about using django-nose for django development but am giving a shot and report back if I find out more!

There are a lot more features overall, but I think one major reason people use nose/djano_nose is that it allows you to very easily do code coverage.
python manage.py test myapp --with-coverage --cover-package=myapp

Finding unused Django code to remove

I've started working on a project with loads of unused legacy code in it. I was wondering if it might be possible to use a tool like coverage in combination with a crawler (like the django-test-utils one) to help me locate code which isn't getting hit which we can mark with deprecation warnings. I realise that something like this won't be foolproof but thought it might help.
I've tried running coverage.py with the django debug server but it doesn't work correctly (it seems to just profile the runserver machinery rather than my views, etc).
We're improving our test coverage all the time but there's a way to go and I thought there might be a quicker way.
Any thoughts?
Thanks.

You can run the development server under coverage if you use the --noreload switch:
coverage run ./manage.py runserver --noreload

pylint is great tool for static code analysis (among others things it will detect unused imports, variables or arguments).
http://nedbatchelder.com/blog/200806/pylint.html
http://www.doughellmann.com/articles/pythonmagazine/completely-different/2008-03-linters/index.html