Wondering which restructured package most of you use in django 1.5+?
from django.contrib.markup.templatetags.markup import restructuredtext
Returns:
ImportError ...
No module named markup.templatetags.markup
https://docs.djangoproject.com/en/1.6/releases/1.5-alpha-1/#django-utils-markup
Yes the django.utils.markup was deprecated in 1.5 and removed in 1.6. The Python implementation of the reStructuredText markup lives in the docutils package. That is the implementation that Django <= 1.5 used.
The easiest way to install docutils is using pip:
pip install docutils
You can find the old django.utils.markup implementation in the 1.5.x branch on Djangos github repo:
https://github.com/django/django/blob/stable/1.5.x/django/contrib/markup/templatetags/markup.py#L76
This is an addon to the answer by #jbub:
When you have an old Django application and you want to continue using markup, follow these steps:
Delete django.contrib.markup from INSTALLED_APPS (in the file settings.py
Add a directory templatetags to your application
Copy the file markup.py from https://github.com/django/django/blob/stable/1.5.x/django/contrib/markup/templatetags/markup.py#L76 to templatetags
touch a file __init__.py in the templatetags directoy
Start over your webserver and see it working again.
Note that this procedure keeps your old application working. However, the deprecation of django.contrib.markup came for a reason: There were security concerns over possible cross-site scripting attacks using markdown. You are on your own to deal with this problem.
Related
It seems the best way to send emails from the django-allauth app asynchronously is to simply install django-celery-email. But the packages warns that
This version requires the following versions:Python 2.7 and Python3.5, Django 1.11, 2.1, and 2.2 Celery 4.0
I've only been using python for several months and never encountered a situation where two python version are needed on a project. And I'm using the official recommendation of pipenv for local development. A quick google shows that it isn't possible to have two python interpreters installed in the virtual environment. Since the plugin seems so popular I wondered how others were setting it up? Apologies if I've missed something major that explains this.
A bonus answer would also take into account that I am using docker and the docker image will install the python packages like this.
RUN pipenv install --system --deploy --ignore-pipfile
Many thanks in advance.
I am pretty sure it is just inaccurate description in the project docs, so you need either python 2.7 or python >=3.5 to be installed
In the end I didn't use django-celery-email. It's easy to send the emails generated by the django-allauth app without this package.
I used these resources -
https://github.com/anymail/django-anymail/issues/79
https://docs.djangoproject.com/en/2.2/topics/email/#defining-a-custom-email-backend
Basically you do this to get it working.
In settings.py define a CustomEmailBackend -
EMAIL_BACKEND = "users.backends.CustomEmailBackend"
In a backend.py file define the backend -
from django.core.mail.backends.base import BaseEmailBackend
from .tasks import async_send_messages
class CustomEmailBackend(BaseEmailBackend):
def send_messages(self, email_messages):
async_send_messages.delay(email_messages)
return len(email_messages)
And this is the task -
from django.core.mail import get_connection
from abstract_base_user.celery import app
#app.task(rety_backoff=True, serializer="pickle")
def async_send_messages(email_messages):
conn = get_connection(backend='anymail.backends.mailgun.EmailBackend')
conn.send_messages(email_messages)
The celery django app should be set up in the standard way as defined at https://docs.celeryproject.org/en/latest/django/first-steps-with-django.html
And the celery settings in the settings.py need include the pickle content type -
CELERY_ACCEPT_CONTENT = ['json', 'pickle']
Obviously you need to include your anytime settings and broker settings too. But this should be enough to get anybody started.
I'm using os x , I tried to run the project that I installed from Github
https://github.com/cfpb/idea-box
but there is error says : ImportError: No module named comments
maybe I miss something but since I'm newbie in Django I can't figure it out
Django comments are deprecated in latest version. You can either install older django version (such as 1.5).
Or the better solution is to install comments from external repository like so:
pip install django-contrib-comments
and then change all imports like this:
from django.contrib.comments.models import Comment # old
from django_comments.models import Comment # new
Sources:
Django's docs
Another question
I have a project that I've built over the last several years, and it was started in Django 1.4. The server that runs this project is due for replacement, so I'm in the process of migrating to the new server.
I'm considering taking this opportunity to upgrade the project to Django 1.7. I've been looking over the notes, and I know I will have some work to do regarding url tags, and some other things. But, it looks like the main structure of projects has changed. In my project, the settings.py, static folder, and the project wide urls.py files/folder were all within the project's root directory. However, in 1.7 (and probably a few version earlier) it seems these files/folders are moved to an app folder within the main project.
For example, my 1.4 project has a project structure of:
project folder:
- urls.py # all other app urls.py files are included in this main urls file
- static # all static files for the whole project reside here
- settings.py # project settings
./app:
- urls.py #app specific urls
But now, it seems the default project structure has changed to this:
project folder:
- # there's nothing here other than the "manage" script
./project:
- # an 'app' with the same name as the project now holds project wide files
- urls.py # project wide urls file?
- settings.py # project wide settings? within this app folder?
- static # project wide static files to be held here?
So, will I even be able to run my project in 1.7 given the new project structure?
You can have whatever project structure you desire in Django. So you will be able to run your project barring any other upgrading issues. One of the best current examples of project structure is the Django Cookiecutter by PyDanny.
Besides abstract user classes, authentication, and migrations ( and the commands like syncdb / schemamigration that go with it) nothing should really stand in your way to upgrade. Some things have been depreciated but they're well documented and easy to fix. In each release, they've ensured the upgrade path and backwards compatibility is clear and as good as possible.
I'd recommend following the best practices with 1.5, 1.6, and 1.7 that have changed the way the community writes Django applications. My favorite resource for to learn about them is Two Scoops of Django. PyDanny is one of the authors. There are two versions, for 1.5 and 1.6, and each goes over the major differences between the previous version and how the new features have changed the way you should write Django apps. By reading both you could get a clear view of how to upgrade your app from 1.4 to 1.5 to 1.6. Beyond that, the release notes of each version, and the django-cookiecutter are great places to see whats changed and what the new best practices are.
I want to be clear that this is a distilled version of the answers found at the link provided by harshil above. I am adding it here in case the URL breaks in the future as it helped me.
ADD A SECRET_KEY TO YOUR SETTINGS.PY
Changed in Django 1.5, Django now requires every project to have a SECRET_KEY.
THE CONCEPT OF APPLICATIONS AND APPLICATIONS REGISTRY IN 1.7:
This is a new concept introduced in 1.7 where Django maintains a registry of your installed applications, hence making it really easy to manage and introspect all your apps. The best part I liked about this feature is that it makes it super easy to manage subapps and also run initialization code when each app is ready.
You can learn more about this here: https://docs.djangoproject.com/en/1.7/ref/applications/
UPGRADING DJANGO TEMPLATE URL TAGS TO USE NEW SYNTAX INTRODUCED IN DJANGO 1.5:
If you were already using Django’s {% load url from future %}, you can skip this step, but in case you weren’t you must now change your url tags from {% url view_name args %} to {% url 'view_name' args %}.
There is this awesome sed command that you can use to convert all your url tags to the new format. You can either run this command from your template directory
sed -i -r -e "s#\{% url ([a-zA-Z0-9_.:-]+)#\{% url '\1'#g" *
or in order to run it recursively you can run the following:
find . -type f -print0 | xargs -0 sed -i -r -e "s#\{% url ([a-zA-Z0-9_.:-]+)#\{% url '\1'#g"
Credit goes to Enrico for posting this shortcut on stack here.
APP LABELS
While migrating from Django 1.4 I had issues where the new django migrations (which is the next topic) had issues recognizing which ‘app’ a given model belonged to. As a rule of thumb, I would just add app_label to all the models Meta class and set it to the package (folder) name.
MIGRATIONS
With Django 1.7 you no longer need south, since migrations are now built-in. The best way to migrate from south to django migrations is to delete all the migration files from your migrations folder (leave the __init__.py in there).
Run the following to generate all the new migrations:
python manage.py makemigrations
followed by migrate (if django sees that the table already exists then it won’t run those migrations)
python manage.py migrate
URLS.PY
You might have the following in all your urls.py
from django.conf.urls.defaults import patterns, include, url
You will want to replace that with:
from django.conf.urls import patterns, include, url
HTTPRESPONSE
If there is any code that sets the mimetype of the HttpResponse manually you will need to change it to content_type.
HttpResponse({"message": "hello world!"}, mimetype="application/json") becomes HttpResponse({"message": "hello world!"}, content_type="application/json")
GET_QUERY_SET
The get_query_set method has been deprecated in preference for get_queryset. So you will need to change that as well if you were overriding the get_query_set method previously.
CACHING
If you were using ORM caching like johnny-cache, you will need to either kill that, roll your own or upgrade to something like django-cachalot.
PLUGINS:
Remember to upgrade all your requirements and plugins. A lot of the older plugins might not be compatible with Django 1.7.
Upgrade to Celery >= 3.1.16
Here is a good list of things to keep in mind when upgrading from 1.4 http://labs.seedinvest.com/backend/upgrading-from-django-1-4-to-django-1-7/
this article suggest the best way to do it, is one version step at a time:
This section will make it clear that you should only ever upgrade one release at a time. You should not upgrade from 1.4 to 1.7 directly. Instead, make the jump from 1.4 to 1.5 first, then proceed to 1.6, and so on. This is in keeping with the idea of taking small steps.
see:
http://andrewsforge.com/article/upgrading-django-to-17/part-4-upgrade-strategies/
However, it probably depend on the time a project can be 'on hold' during refactoring it to a newer version probably mean the progress of new features and so on has to be 'on hold'.
I guess doing it all at once, is a big step, so a lot of work at once, but dividing it in small steps (version by version) means shorter tracks, but the overall track will probably be longer.
I'm trying to set up Pinax and I'm new to everything involved (Django, Pinax, webservers, etc). I'm following http://pinax.readthedocs.org/en/latest/gettingstarted.html
When I generate a project using:
(mysite-env)$ pinax-admin setup_project -b basic mysite
The directory structure I get is:
apps __init__.py manage.py settings.pyc urls.py
dev.db __init__.pyc requirements static urls.pyc
fixtures locale settings.py templates wsgi.py
Which as far as I can tell is missing the deployment folder (when you compare to the directory structure shown here : http://pinax.readthedocs.org/en/latest/starterprojects.html). It doesn't seem to be effecting anything yet, but it makes me nervous. What is going on and is the fact I'm missing the deployment folder going to cause problems in the future?
I'm running Ubuntu and using python 2.7. I had the same behaviour with Windows 7, python 2.6
Thanks!
The new Django versions have made the old pinax pretty much useless. Now Django supports project templates and Pinax is separated into several smaller projects regarding starter projects (such as pinax-project-account) and apps (such as django-user-account).
The current way to use pinax is to choose a starter project, and then running something like:
$ django-admin.py startproject --template=https://github.com/pinax/pinax-project-account/zipball/master <project_name>
and then install requirements:
$ pip install -r requirements.txt
This will create a new Django project using the starter-project as a template, which already includes a few apps (like django-user-account) and templates (with bootstrap!). The project is ready to run, and already includes a bunch of functionality (like user registration, login and management).
Also, Django has changed the project directory structure a bit, so now it doesn't really look like that anymore.
I'm trying to figure out if its possible to get django 1.3 running on heroku. I have been going off of their tutorial which assumes the user is using the latest version (1.4) of django. If I follow the tutorial, with the exception of explicitly using Django==1.3 instead of the most recent django version, I get an error when I run django-admin.py startproject hellodjango . (note the dot)
Error:
File "/home/my_dir/.virtualenvs/hellodjango/local/lib/python2.7/site-packages/django/utils/importlib.py", line 28, in import_module
raise TypeError("relative imports require the 'package' argument")
TypeError: relative imports require the 'package' argument
It still creates the project and the welcome page comes up on http://127.0.0.1:8000/. If I keep going with the tutorial and push it to heroku I get
ImportError at /
No module named hellodjango.urls
Seems like there is some mismatch between file structure between the tutorial and django 1.3.
Instructions on how to install Django 1.3 would be very helpful.
This '.' option don't work for me even with Django 1.4 i get same error as you did. So i ignored the dot:
django-admin.py startproject hellodjango
Then i moved all files from hellodjango folder to it's parent folder (that's what Heroku need) and deleted the hellodjango folder.
Followed all steps so i could get the app running on heroku but i got same error as you again, "No module named hellodjango.urls". I solved this removing this hellodjango part from settings.py as i changed the files to a new path so settings.py reflect that change now and everything is fine.
The '.' at the end of the ./manage.py startproject myproject . means start a project "in the current directory"(This feature was added in djago 1.4). In django 1.4 instead of importing from myproject import myapp, you just import yourapp directly. Your apps are not longer tied to your projects.
I found this article online that may help you solve your problem:
http://bitkickers.blogspot.com/2012/04/djangoheroku-quickstart-for-existing.html