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.
Related
The point of this is to keep notes/urls pointing to particular parts of the documentation that people want to refer to in the future. For example, when something is a complex feature that requires a little bit of review most of the times you work with it.
Let's take an example. I search for Django STATICFILES_DIR:
https://www.google.com/search?q=django+STATICFILES_DIRS
Pretty quickly I get exactly what I want:
https://docs.djangoproject.com/en/4.1/ref/contrib/staticfiles/
which has a STATICFILES_DIR configuration entry.
But, notice from the url, this is for Django 4.1. And it says so on the page too.
But maybe there are a current version? Let's look.
There isn't.
Contrast with Python, which points to a very generic, 3 version. Not to Python 3.10 or 3.11.
https://docs.python.org/3/tutorial/datastructures.html#dictionaries
Or postgres (looking for create table):
https://www.postgresql.org/docs/14/sql-createtable.html
OK, yes, I have a version 14, but...
I can click on that current and that will NOT pin me to a particular version.
https://www.postgresql.org/docs/current/sql-createtable.html
In the case of Django, Python and Postgresql, I am pretty confident a generic, version-less documentation page will serve my purposes just fine 90% of the time - those are pretty stable APIs by now.
Often searching gets you to ancient postgresql versions like 9.2, but you can always find a current link.
Am I looking in the wrong places for a permanent link for Django docs?
Yes, there is dev link on the Django versions, but that's living a bit dangerously, I assume people are potentially working updating the docs on the current version on that URL. Or should I use that after all?
Going to use the dev tag for now. Django is stable enough that I expect minimal problems there and I can always go back to my version of interest from there. But at least I don't have bookmarks pointing to a bunch of different historical versions.
We experienced strange behaviour. Especially under chrome, some items are missing. Anyone ?
Which version are you using? You should always pin the version you use, which means that once it's published, it will never change.
The code is open source, you can check yourself from the github repository and there are other more appropriate channels than Stack Overflow, IMO:
The Django weblog, where a post is published each time there is a new release.
The Django users mailing list/google group is another place where you can keep up to date.
PyPI gives you the release history.
Finally, with any open source software, don't be afraid of digging into the source code and see what has changed. Github has a great way of comparing between 2 tags, for instance for the latest 2 1.11.x relases: https://github.com/django/django/compare/1.11.16...1.11.17
There was 2 new bugfix relases published on each 2.1.x and 1.11.x branches yesterday, so if your dependencies aren't pinned, you might have auto-updated, but without further details it's hard to tell you more.
There are two main schools of thought for doing A/B (Split) Testing:
Javascript-based solutions such as Optimizely, Google Analytics Content Experiments.
Server-side solutions such as Django-AB, Splango, and django-lean. (Also, writing your own.)
My understanding is that Javascript-based solutions are spectacular for "which color button converts better," but not so great for switching out entire page layouts, and completely unworkable for trying out large functional changes such as the sequence of pages in a funnel.
That leads me towards a server-side solution. I'm not crazy about coding my own, and will do so only if there is no other option. I'm trying to add value by improving the core functionality of my site, not by creating a better split-testing framework.
The Django apps I've found for split testing are various mixtures of unmaintained, undocumented, documented incorrectly, and incompatible with Django 1.5. This surprises me, because the Django and Python communities seem to have a strong focus on good documentation. I'm also very surprised that none of the testing frameworks I've tried has been compatible with Django 1.5 -- is testing not as core a part of the philosophy in the Django/Python world as it is in Rails?
Here's what I've found:
Splango https://github.com/shimon/Splango -- Not compatible with Django 1.5 (although most compatibility bugs I found were trivial to fix). Largely un-touched since October 2010, except for a fix August 2012 which claims to make sure templates get included in the install. Since templates don't get included in the install when Splango is installed via PyPI, either the fix didn't work or didn't get submitted to PyPI. Documentation is largely accurate, but doesn't completely cover how to set up tests and get reports. It tells you how to configure the template to gather the data, but there appears to be additional steps required in the admin interface which are completely undocumented, and I'm not sure I've done them properly.
Django-lean. Original at https://bitbucket.org/akoha/django-lean has not been updated since July 2010. There is an apparently "blessed" fork at https://github.com/anandhenry2002/django-lean which has not been changed since May 2012, when it was copied over from the original. The original's documentation is incorrect in ways that make following the examples impossible. (Though you can probably muddle your way through, as I did.) The new version's documentation has formatting problems that make it difficult to read on github. (This appears to be because it's the unchanged documentation from the old project, and BitBucket syntax doesn't work on Github.) The django-lean Google Group has not had a message since July 2012.
django-mini-lean https://github.com/DanAncona/django-mini-lean -- Updated as recently as February 2013, but undocumented.
Leaner - https://bitbucket.org/brianjinwright/leaner -- Last updated July 2012, and no docs.
Django-AB -- Last updated May 2009. Is not a package, and can't be installed via PIP or PyPI. After placing the checkout in my django app folder (and renaming the folder to ab) and following the installation instructions, I get an error loading the template loader that I have not tracked down further.
So far Splango appears to be the winner, as I've actually been able to get it more-or-less working (by manually installing the templates, and then editing them to fix Django 1.5 incompatibilities).
Can anyone point me to anything I've missed?
You have missed this app : https://github.com/mixcloud/django-experiments + https://github.com/disqus/gargoyle/
And then there's waffle: http://waffle.readthedocs.org/
It's simple, updated, maintained, but not very feature rich, it doesn't have any analytics/reporting stuff integrated. But then again, google analytics or mixpanel type of service is better for this.
I first looked at Django-AB and that is almost what I wanted, but I couldn't get it to work either. After looking at django-experiments and deciding I didn't want to mess around with redis yet, I decided to roll my own. I've tried to package it up nicely and make it easy to use for the beginner. It's super basic.
https://github.com/crobertsbmw/RobertsAB
You can swap out entirely different page layouts with Google Analytics Experiments (their default experiment setup will redirect users to a different URL for each variation you have), although in general its much easier to interpret why something is more successful if you test smaller things against each other.
You are right that testing different funnels and user flows against each other using Google Analytics would require a lot of manual setup; although theoretically you could do it by swapping out different links and tracking your users with UTM campaigns.
For smaller A/B tests within the same page, I ended up using Google Analytics Experiments and writing a custom Django CMS plugin for adding a few variant options to a template, which queries the Google Analytics API and displays the correct variant using Javascript.
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.
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.