I've been using a pre 1.0 version of django (a dev version somewhere around .97),
And now I'm considering upgrading to 1.x (I grabbed the latest thing from the svn).
There have been some changes to the way the admin interface works, so now I have to edit all my models.py files and create new admin.py files.
I remember seeing a tool that supposedly automated (most of) this process, but that was a long time ago and I don't remember where it was (or maybe my memory is wrong)
Is there such a tool? Where is it?
This might also be helpful:
http://www.djangosnippets.org/snippets/603/
I think what you're looking for is this page: http://docs.djangoproject.com/en/dev/releases/1.0-porting-guide/.
It contains info on the changes, and a link to the script that will auto-generate a 1.0-compatible admin.py file based on your models.
Related
I'm making a Django project consisting of several apps and I want to use a version number for the whole project, which would be useful for tracking the status of the project between each time it comes to production.
I've read and googled and I've found how to put a version number for each django app of mine, but not for a whole project.
I assume that the settings.py (in my case it would be base.py, because the settings are inherited for each environment: developmente, pre-production, production) would be the ideal file for storing it, but I would like to know good practices from other Django programmers, because I haven't found any.
Thank you in advance
I don't think I've ever needed to do this, but the two obvious choices would be either the settings file, as you state, or alternatively the __init__.py in the main project app.
You don't need it to relate to django, you can tag a commit in your source control to provide a marker of a particular version (as well as a separate branch for releases).
From the docs for git tagging
Git has the ability to tag specific points in history as being important. Typically people use this functionality to mark release points (v1.0, and so on).
You could use the same versioning number system as google if you so wish which relates to
year.month.day.optional_revision # i.e 2016.05.03 for today
Doing this would make it easier to track back to previous versions since it won't be overwritten in source code by newer version numbers.
This question already exists, but it is over one year old now and a lot has probably happened if the documentation is a good judge. There is no documented path to migrate from current redmine (2.1) to chiliproject for example.
Chiliproject is a fork of redmine, but I am unable to decide wherever I should migrate or not. There is no clear path as to how I should do the migrations and how much functionality I might loose.
Is there a way to compare the differences between the two projects? Is it worth to spend the time investigating the migration path?
If you have migrated what is your experience?
I searched StackOverflow for the "redmine vs. chiliproject" question because I am having a lot of trouble with installing plugins of any kind on the newest chiliproject version.
Usually, it looks like everything is working fine until you try to update the settings for the plugin (for example, install the Contact Form plugin and try to change something on http://SERVER:3000/settings?tab=contact_form), the debug log shows that the changes were made in the database, but they changes are never loaded back to the plugin page.
I have not been ale to find any documentation on potential changes to the plugin architecture in ChiliProject that would cause this. The plugin page does not list many plugins that are known to work with ChiliProject 3 either.
TL;DR: If you think that you will have any desire to use any existing plugins to extend the functionality of the program you choose, go with Redmine.
I am developing an Django application using the Django 1.3.1 release :
https://code.djangoproject.com/browser/django/tags/releases/1.3.1
I encountered a bug, which has been identified and fixed by the Django team :
https://code.djangoproject.com/ticket/16128
The changeset associated to the bug resolution is located in Django trunk
https://code.djangoproject.com/changeset/17755
My question is : how can I take advantage of the bug resolution, without upgrading to the Django trunk version ?
There a bunch of files attached to the ticket, the latest is :
https://code.djangoproject.com/attachment/ticket/16128/16128.diff
I can see that this file is a standard 'diff' file, which can be processed by the 'patch' utility. I tried to apply it on my django 1.3.1 installation (on a dev machine), but it does not work...The source lines (to be replaced) are not exactly the one expected by the diff file.
To which 'start state' does refer this diff file ? In other words, to which django version can it be applied ?
Is there another way than applying it 'manually' ? Even if I apply it manually, I can see that the patched code call new versions of methods not included in the patch...which means that I have to find out, by reading the code, which other files have to be patched, and patch them...
At this point, I think something like : "waow, it's to complicated, let's wait the next release of Django - 1.5, for this ticket - and find a workaround !". But, in other hand, if the patch system exists, it must be possible to apply this patch to my Django 1.3.1 installation...
Did anyone encountered the same kind of problem ? If so, how did you manage it ?
Thanks in advance for your help
Did you actually try with the Django 1.4 release, which has been issued a few days ago? I am quite sure it is part of it.
Anyways...you can get the official diff at the changeset page that you referenced - at the bottom there is a link to an unified diff. You can download the patch from there and use it to patch(1) your release (beware that should the Django team release a new security release of Django 1.3, you may have to apply it again). However, those diffs are always against the most recent codebase at the time the patch has been committed. For that reason, sometimes you might have a bad luck (like in the case you have described above) and it may not apply cleanly to the previous release. In such case you would have to track down all the changes required to make it work, which may be pretty much work and might be unacceptable. So there are only three options: find your own way to work the bug around, track all the changes required to apply the patch cleanly, or upgrade to the given revision.
The senior developer (and the only person experienced with Django in our company) has moved away and left us. Shortly after this (following his instructions) we pushed a site live onto a shared server (we have full control over the server) and updated the version of Django to the latest release for the new site to work.
Since then we have had issues with the other Django project on there which was built using an older version.
The main issue that I have is that we have a crontab that sends an email to the client outlining their orders. I have taken a screen grab of the error that I am getting but if I am honest I am struggling to make any sense of it. The names have been changed to protect the innocent (client).
http://i-am-a-fish.co.uk/help.png
I have uploaded a screen grab again i-am-a-fish.co.uk/help2.png
All suggestions are very welcomed!
Deprecation warning is not the reason, you can ignore it (unless you want to fix and use hashlib). The reason is multipart_subtype which your custom EmailAlternativesMessage class is not defining. Try to find declaration of EmailAlternativesMessage and add
class EmailAlternativesMessage(EmailMessage):
multipart_subtype = 'alternative'
...
Now that your immediate problem is fixed, the real solution here is to use virtualenv to isolate each project's dependencies (including Django itself) from the others, so deploying a project based on recent Django doesn't require an immediate upgrade of every other site on the server.
I'm updating a 0.5.1 complete_project to 0.7beta3 + virtualenv + pip + fabric.
I have converted my project into multiple stand-alone applications and I have everything being pulled down by pip from a requirements.txt file.
I am now moving the code over and so far can get the Welcome page and perform a log-in, but then it breaks, due, it appears, to the introduction of Group support and the refactoring of Tribes into Tribes and Topics.
Has anyone successfully made this move? If you did, how did you handle migrating your data? What should I be looking out for? Anyone have a checklist or list of steps? What other exciting challenges do I have to look forward to?
The short answer as far as I'm aware (and I've been following Pinax development for some time now) is that there is no straightforward path to upgrade the project from 0.5.1 to 0.7beta3. I'm not sure how familiar you are with the code, but this is the process I would use based on my limited experience:
Start by using the social_project/ that ships with the latest version of Pinax. Copy into it any changes you made to the settings.py file as well as any custom apps you have.
The templates and media have moved to folders outside of the projects, but if you customized any of them (I'm sure you did) take the custom ones and drop them into the template folders in your project to override those in the default theme folders. You should compare them to those in the theme folders to see what changes may need to be made to keep up with changes in the apps.
The next step would be to do the same thing with urls.py copying any customizations over the one provided by the project.
Try getting it running at this point with a fresh DB. Hopefully any errors will point you in the right direction to stuff that you might have missed or not known about.
Once you gotten it running most of the DB tables should be the same (I believe) except as you mentioned the Tribes stuff. Migrating the data, though, is still beyond what I've had to deal with.
Disclaimer: I've been following development but never had to perform an upgrade quite this big. Good luck and (obviously) back up your work and data before trying to port it all over.
See the documentation and code ( http://github.com/pinax/pinax/tree/master ) for more details. The code is a convenient (though tedious) way to watch the evolution between 0.5.1 and 0.7beta3, for what that's worth.