i was working on a project on django using one of my system(win8) now i have changed my system.how do i continue working from where i left off on my new system(win7).i have a copy of the old django project file directory and nothing else,i have installed python and django on my new system and just copying that file directory and running python manage.py runserver on new system doesnt work(i wasnt hoping that it would work anyway) so what should i do?i am new in django and python so if anyone can explain me in detail.if my question arise any confusion please leave a comment.
django.db.models.loading was removed in Django 1.9. You need install the same version of Django on the old and new systems.
Django is pretty good about backwards compatibility, but you can't upgrade from one version to the next and assume that everything is going to work. You need to read through the release notes first (e.g 1.9), and make any required code changes.
Related
I am relatively new to Django, and I must admin I'm getting confused (not to mention frustrated) with its frankly, bizarre folder structure - and the differentiation between website, projects, apps and modules.
I am trying to install and use django-realestate into my virtenv (using virtualenvwrapper)
After I created the new virtenv, I installed the Django app in the new environment. The problem is that the entire codebase is actually created under ~./virtualenvs/myenv
The problem is that I want to be able to modify and (quite extensively) extend the code to suit my own purposes. However, I can't do that - if the code is under the "control" of virtualenv. My gut instinct is to do either of the following:
Move the code from the src folder under ~./vitualenvs/myenv to /path/to/proj
Create a brand new Django install and add(/merge?) the folders realestate, testproject and test to my project folder?
It is a hideously complicated setup for what is a straightforward requirement: I want to have the latest Django version, and also have the code for the latest real-estate app (which I will modify extensively).
How do I solve this problem?
Deploying to a live server for an existing Django application. It's a very old site that has not been updated in 3+ years.
I was hired on contract to bring it up to date, which included upgrading the Django version to be current. This broke many things on the site that had to be repaired.
I did a test deployment and it went fine. Now it is time for deployment to live and I am having some issues....
First thing I was going to do is keep a log of the current Django version on server, incase of any issues we can roll back. I tried logging in Python command prompt and importing Django to find version number, and it said Django not found.
I was looking further and found the version in a pip requirements.txt file.
Then I decided to update the actual django version on the server. Update went through smoothly. Then I checked the live site, and everything was unchanged (with the old files still in place). Most of the site should have been broken. It was not recognizing any changes in Django.
I am assuming the reason for this might be that the last contractor used virtualenv? And that's why it is not recognizing Django, or the Django update are not doing anything to the live site?
That is the only reason I could come up with to explain this issue, as since there is a pip requirements.txt file, he likely installed Django with pip, which means Python should recognize the path to Django.
So then I was going to try to find the source path for the virtualenv with command "lsvirtualenv". But when I do that, even that gives me a "command not found" error.
My only guess is that this was an older version of virtualenv that does not have this command? If that is not the case, I'm not sure what is going on.
Any advice for how I find the information I need to update the package versions on this server with the tools I have access to?
Create your own virtualenv
If all fails, just recreate the virtualenv from the requirements.txt and go from there
Find out how the old app was being launched
If you insist on finding the old one, IMO the most direct way is to find how is the production Django app being ran. Look for bash scripts that start it, some supervisor entries etc
If you find how it starts, then you can pinpoint the environment it is launched in (e.g. which virtualenv)
Find the virtualenv by searching for common files
Other than that you can use find or locate command to search for files we know to exist in a virtualenv like lib/pythonX.Y/site-packages, bin/activate or bin/python etc
Why not start checking what processes are actually running, and with what commandline, using ps auxf or something of the sort. Then you know if its nginx+uwsgi or django-devserver or what, and maybe even see the virtualenv path, if it's being launched very manually. Then, look at the config file of the server you find.
Alternatively, look around, using netstat -taupen, for example, which processes are listening to which ports. Makes even more sense, if there's a reverse proxy like nginx or whatever running, and you know that it's proxying to.
The requirements.txt I'd ignore completely. You'll get the same, but correct information from the virtualenv once you activate it and run pip freeze. The file's superfluous at best, and misleading at worst.
Btw, if this old contractor compiled and installed a custom Python, (s)he might not even have used a virtualenv, while still avoiding the system libraries and PYTHONPATH. Unlikely, but possible.
When i point my django project to my python interpreter 3.2 in the new interpreter window and load files accordingly using the apply button, I hit next it says django is not in the python interpreter , do I need to install django inside the python interpreter??
when i create new project the option of django project is there and i can develop python projects fine, but eclipse won't let me go any further in django sayin django not found....pre requisite is that django is installed into the [ppython/jython/ironpython interpreter.
Any ideas to overcome this?
Django isn't Python 3 compatible yet. Experimental support is planned in 1.5. See https://docs.djangoproject.com/en/1.4/faq/install/ for more info.
I am very new to django, python and ubuntu command line. I've been installing an application on PC's and this is my third one. Ive come across this error and am not sure where else to look. When I run
python manage.py syncdb
i receive the following error
django.core.exceptions.ImproperlyConfigured: Cannot determine PostGIS version for database "winepad". GeoDjango requires at least PostGIS version 1.3. Was the database created from a spatial database template?
Any help would be greatly appreciated
Thanks
Check Your PostGIS Version. it must be atleast 1.3.
Have you gone through this character-building documentation:
http://docs.djangoproject.com/en/dev/ref/contrib/gis/install/
?
We need to know more about versions of things and what steps you took to come to this error. Otherwise, the error is pretty informative. The database that your settings refer to must not have been created with postgis 1.3+ from a spatial database template.
I wonder since you say that you are new,, Do you realize that you are attempting to install a Django package that has geo requirements and therefore assumes that you have a correct version of postgres-sql up and running (which is a somewhat difficult install itself)
You might want to start with something simpler that just uses the sql-lite database look in the Djano settings file to see what the database setting is....
After looking at the reusable apps chapter of Practical Django Projects and listening to the DjangoCon (Pycon?) lecture, there seems to be an emphasis on making your apps pluggable by installing them into the Python path, namely site-packages.
What I don't understand is what happens when the version of one of those installed apps changes. If I update one of the apps that's installed to site-packages, then won't that break all my current projects that use it? I never noticed anything in settings.py that let's you specify the version of the app you're importing.
I think in Ruby/Rails, they're able to freeze gems for this sort of situation. But what are we supposed to do in Python/Django?
Having multiple versions of the same package gets messy (setuptools can do it, though).
I've found it cleaner to put each project in its own virtualenv. We use virtualevwrapper to manage the virtualenvs easily, and the --no-site-packages option to make every project really self-contained and portable across machines.
This is the recommended setup for mod_wsgi servers.
You definitely don't want to put your Django apps into site-packages if you have more than one Django site.
The best way, as Ken Arnold answered, is to use Ian Bicking's virtualenv (Virtual Python Environment Builder). This is especially true if you have to run multiple versions of Django.
However, if you can run a single version of Python and Django then it might be a little easier to just install the apps into your project directory. This way if an external app gets updated you can upgrade each of your projects one at a time as you see fit. This is the structure Pinax used for external Django apps at one time, but I think it's using virtualenv + pip (instead of setuptools/distutils) now.
What we do.
We put only "3rd-party" stuff in site-packages. Django, XLRD, PIL, etc.
We keep our overall project structured as a collection of packages and Django projects. Each project is a portion of the overall site. We have two separate behaviors for port 80 and port 443 (SSL).
OverallProject/
aPackage/
anotherPackage/
djangoProject80/
settings.py
logging.ini
app_a_1/
models.py # app a, version 1 schema
app_a_2/
models.py # app a, version 2 schema
app_b_2/
models.py
app_c_1/
models.py
djangoProject443/
test/
tool/
We use a version number as part of the app name. This is the major version number, and is tied to the schema, since "uses-the-same-schema" is one definition of major release compatibility.
You have to migrated the data and prove that things work in the new version. Then you can delete the old version and remove the schema from the database. Migrating the data is challenging because you can't run both apps side-by-side.
Most applications have just one current version installed.