On Mon, Feb 6, 2012 at 8:23 AM, bruno desthuilliers <[email protected]> wrote: > Depends on how much you need to modify the third part app. Forking the > app is sometimes the best solution, but it means you'll have a hard > time keeping in sync with the original code when bugfixes and new > features will be released.
It's really not that hard assuming that you are using some decent source control. In subversion, a new release is handled by the tool 'svn_load_dirs', which is trivial to use, and then merging the changes that required the branch. If the changes are minimal, then there is really not much work involved in merging them to a newer release. Once you have the forked project tracked in source control, installing your patched version in production is simply a case of referencing it correctly via pip. Ideally you should keep all dependencies tracked in a requirements.pip file, so this simply requires changing a line like so: -django==1.3.1 +svn+http://my.repo.host/python/vendor/django/1.3.1-barorg#egg=django At $JOB, we go a step further and roll these up into packages which we serve up from our own pypi (well, a directory with a collection of tar.gz files in it), so we can use the simpler format. Plus, our production machines have no direct access to the internet, so it is kind of necessary anyway :) Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
