Greetings,
I am currently working on a long term project that uses Django 1.1.1, and we are planning to release it around march of 2010.
Now while surfing I came upon to this article which says the planned release date of Django 1.2.0 is March 9, 2010.
Now I am a bit confused. If I should continue developing under 1.1.1 or start developing using 1.2.0 beta.
I'd say only develop for the latest version if there is a specific feature you need/like. Read up on it so you know of course what is in store.
1.0 onwards. I've found swapping django versions to be relatively trouble free. At any stage all you need to do is swap symlinks on a source tree on your test server. and of course running that thorough unit test suite you've written will show up any version skew bugs.
The upgrade path is not difficult. I would familiarize yourself with the differences and avoid deprecations, but continue on the battle tested 1.1 branch. While you should never ever trust software release dates, you also probably don't want to bet your farm on a brand new branch with features you clearly don't need yet. You've got plenty to do to release in a month. Upgrade when you have time. If your release was scheduled for June you might consider it, but for now stick with stability. That's mho.
Part of our current application under development is being put into production now, but we hope to use Django 1.2 final. Our strategy is to write code, test and deploy using Django 1.1.1, but also test using virtualenv. There's really no reason not to test your code under 1.2 whatever your deployment decision because you'll want it eventually to be compatible with 1.2.
virtualenv makes the whole process painless and is the key to quickly switching between environments. It's incredibly easy to set up:
easy_install virtualenv
virtualenv django12
cd django12
source bin/activate
Then download and install Django 1.2 in the virtual environment and run your tests. I run the development server in virtualenv on port 8081, so I can have both servers -- using the same application code -- running at the same time, ports 8080, 8081.
In our case we had to remove one import and wrap a few others with try/except conditions. I had to write a dummy csrf_token template tag for CSRF to work -- the Django developers have informed me they'll include a dummy tag in 1.2 final. We also upgraded the South migrations tool to 0.7-pre, as the current release doesn't support Django 1.2.
Bottom line: Regardless of your deployment decision, a case can be made for testing both versions of Django if at all possible.
Related
I was using django 1.1 and python2.7 in my project.
Now I will setup a new Django project from scratch. So i want to know if the above configuration is correct for my new project or I should use python3 and latest django version. If so then which Django,Python version will be good for new project? And I should get good support from django community.
Thanks
Currently, the last stable version of Django is 2.1.7. This version works with Python 3.7. You'll find a lot of support for this version of Django... there are a lot of develops about this version, such as Django Rest Framework, JWT, among others.
I suggest you for a project from scratch, work with Django 2.1.7 and Python 3.7, probably, you'll get quickly your goals. If you need to update your knowledge, you can do a course on a web platform as Udemy.
Soon Django 2.2 will be released... but I suppose we have to wait some days to get all benefits of this new release.
I have a Django Server that uses a X package, these package i upgrade daily. I don’t want to Stop my Django instance every day when the package was updated.
I have a Cron daily to Upgrade the Package (Pip package -U),
but the Django doesn’t use the latest version upgrated. Thanks
Generally doing a software update to a running service implies some kind of a restart or reload of that service. In many cases, if you force this, it may work for some amount of time but may cause difficult to find bugs; java is infamous for working until the next occasional subroutine (ie, log collection) happens if you upgrade the jdk version in-place like this.
I'm not sure what kind of modules you're modifying here, but in some cases you might try out https://github.com/django-extensions/django-extensions to see if the manage.py shell_plus autoreload may serve your needs.
I'm following the guide to setup django-mongodb. But this line pip install git+https://github.com/django-nonrel/django#nonrel-1.5 always reverts my django to 1.5. Is there anyway that I can use lastest django?
That is because django-nonrelis a fork from the original Django project.
You can consider that as a different project.
django-nonrel was developed side by side with the original Django project until version 1.6, the last commit for nonrel is 2 years old.
To sum it up, if you want to use django-nonrel it is not recommended and you are limited to latest Django version it supports - 1.6.
The django-nonrel project is dead - If you want to use a NoSQL I will recommend not using Django.
There is't any official support for that, and I did not find any on-going projects (third-party) that exist anymore.
pip install git+https://github.com/django-nonrel/django#nonrel-1.6
The latest django-mongodb-engine is no longer operational. Using mongoengine alone will work only if your project does not use ANY contrib modules like, session, auth, user.
I recently came across another package called djongo. It is working fine on the latest version of Django.
Disclaimer: I have contributed to this package, but i am not trying to promote it anyway. I think it solves most of the Django MongoDB issues that have been around for ages and is extremely easy to use.
As a Django / Python newbie, should I try to debug on a server running 4 year old software versions, try to recreate the old software installations on my local, or just try to run the software in current version of Django/Python/Postgres/PostGIS on my local Mac OS X 10.9.5?
Background:
On a project where I was supposed to just load data into Postgres/PostGIS, I need to debug why a 2010 year old Django / Postgres / Postgis project is getting an error. I'm a LAMP developer who's never used Django or done much in Python, but I've been able to get a staging site working on the server, and make one or two changes. I thought it would make sense to debug locally on my Mac OS X 10.9.5. So I've used homebrew to install Django 1.7 and Postgres 9.3. Looking at the version differences, I'm worried it will be a more of a hassle now to try to migrate and upgrade the project than to attempt to debug it on the staging site instance running on the server.
FWIW, I know the lines of code that I'd like to investigate (seems like maybe an object is not getting loaded properly from db, since it is in the db), but I'm not positive what sort of echo statements to use. I like using IDE's to inspect things. The project is a bit of an orphan, as the first professional project of a developer who is no longer available to help. And of course, the deadline is last week. :(
Differences between your production and development environments can cause a myriad of headaches.
I recommend you use a tool such as Vagrant to set up a development environment running inside of a virtual machine that mirrors your production server.
Use VirtualEnv to emulate the necessary Django version. PostgreSQL is trickier, in theory you can have a second instance with the required version running simultaneously, but that can also cause very subtle conflicts. It would be better to have it running on another machine (virtual or physical) and access it through your local network.
The simplest way I think is to look at using unittest and mock object to set up some unit tests on the functions that you suspect are the cause of the problem. By using unittest and mock objects, you can control how the existing code interacts with Django and Postgres objects and allow for version differences by setting the expected return values.
With mock object, you can mock all or just part of an existing Python object, which reduces the dependencies you require for your development environment. Depending on how the code is structured, you might not need to install either Django or Postgres at all or a webserver for that matter. This blog explains Mock object in detail.
Even though you're pressed for time, you could do worse than setting up unittests for the whole project, future developers will thank you.
In terms of debugging, I personally can't reccomend pudb enough, it's an interactive command line debugger which you can use with unittest to zero in on what part of the code is causing the problem.
If you do need to install Django and Postgres, I would suggest looking at virtualenv which allows you to set up a virtual environment for Python. That way you can just install the specific dependencies you need without interfering with your global system wide installation. You can also install earlier versions of packages which would do the trick to emulate the existing system's state.
This doesn't work for me.
$ python django-admin.py startproject myproject
I am running a ubuntu virtual m/c on my windows system.
By default ubuntu 12.04 comes with python 2.7.3 so I am using that only
I downloaded or installed (whatever it does since I am new to django) by issuing the following command-
git clone https://github.com/django/django.git
django directory is successfully created.
I want to create a sample django application. So for this I am issuing the following command-
$ python django-admin.py startproject tango_with_django_project
Obviously, it will throw error since the default ubuntu python doesn't know that django has been installed.
My Question is how to integrate python with this Django and create a sample django application?
The comments above pointing you to the documentation are of course correct, but there are also other resources that can help you start your site the 'right' way. In particular, cookiecutter and its related Django template will get you set up with some really good defaults and valuable third-party apps straight away. If you have cash to spend I'd also heartily recommend the book Two Scoops of Django, by the people who wrote the two applications to which I've linked.
Jeff Knupp has also written a thoroughly useful blog post on starting a Django project the right way, which covers useful topics such as the importance of:
source control;
automated testing (see also this excellent book);
isolating your development environment to smooth deployment; and
managing your database with migrations (included in Django since version 1.7).