Hi, I'd second that. PIP and virtual env have worked well for me too. You could also combine it with fabric in order to automate the building of different environments, so once you get a stable working environment you can use pip's 'freeze' command to create a requirements file with the exact versions of all currently installed packages and use fabric, pip and virtualenv to deploy your code into a new virtualenv anytime you like
You could then, for example, create a new environment to test the latest versions of some or all packages Use package >= version_number instead of package == version_number in your requirements file. That way you won't break your production environment while you are testing that the latest versions of packages play well together. As noted above, there are loads of blog posts on doing this kind of thing, it's pretty well documented. John On Aug 13, 1:54 pm, Daniel Abel <daniel.abel....@gmail.com> wrote: > On Aug 13, 2:43 pm, Oivvio Polite <oiv...@polite.se> wrote: > > > So I guess these errors are relating to some testing Django and/or > > South does per default and that the errors might be due to some version > > incompatibility between the Django/South versions I had installed last > > year and the ones that are installed now. > > > My question isn't really about how to resolve this particular issue but > > rather about best practices for maintaining a consistent "Django stack", > > so that similar errors will not happen in the future. > > You have basically two choices: > > 1) have someone do the 'which versions work together' testing for you. > This is what linux distributions implicitly promise: "use only > packages from the stable repository because those have been tested > that they work in combination". When something breaks, complain to > your linux distributor's maintainers. > > 2) 'Freeze' the package versions when you have something that works, > and run tests when you upgrade some packages to ensure that nothing > breaks. In this case, using virtualenv and pip can help a lot: you > write a requirements file that lists all the components you use, with > explicit version numbers and when deploying install (on a per-site, > not per-server basis) exactly those versions. (google 'virtualenv pip > django') The advantage is that nothing will break by suprise, the > disadvantage is that you don't get bugfixes (including security > bugfixes) silently. > > (Personally I use option 2, virtualenv and pip) > > Hope this helps, > Daniel Abel -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
