Unless any counter arguments are presented, I suggest let's require psycopg 2.5 for now. Is there a scenario where you could pip install Django but not pip install psycopg2?
On Saturday, February 14, 2015 at 5:43:32 PM UTC-5, Shai Berger wrote: > > Hi all, > > On Saturday 14 February 2015 22:53:13 Marc Tamlyn wrote: > > > > Django 1.8 will necessarily be the first version with a true minimum > > requirement on psycopg2 version. Historically we have never documented a > > required version. > > > > FWIW, we have long had minimum requirements for other backends -- all > other > backends, if I'm not mistaken. > > > > > Release history for psycopg2: > > - 2.0.9 is extremely old (date unknown) > > - 2.4.5 was released in March 2012 > > - 2.5 was released in April 2013 > > - 2.6 was released this month (Feb 2015) > > > > During the run to 1.7, we defined a rule about the DBMSs themselves: We do > not > support versions post their end-of-life. That is why Django 1.8 will no > longer > support Postgres 8.4, for example. I suppose a similar rule should apply > to > the drivers. So, the key question becomes, is PG 2.0.x still supported? is > 2.4.x? Since you mention significant new features in 2.4.5, is it even > valid to > talk about 2.4.x? > > > According to Claude, some distros have a python-psycopg2 package which > is > > still on 2.4.5 (or maybe older?). > > > Yep. Debian stable, for one. > > > We have several options: > > - Ensure as much as possible works with old versions of psycopg2 by > > shuffling code around and/or using conditional imports. > > - Making sure everything *outside contrib* doesn't require newer > psycopg2 > > that 2.0.9, and making contrib.postgres require 2.5. This may not be > > possible, but I think it should be. > > - Change nothing but docs, so outside contrib requires 2.4.5, > > contrib.postgres requires 2.5. > > - Just document that Django 1.8+ needs psycopg2 2.5 (pip install it...) > > > > 1.8 is our next LTS. Whatever we commit to, binds us until 2018, more or > less. > I think defining separate dependencies for contrib makes no sense as long > as it > isn't distributed separately. Or rather, unless someone distributes a > Django- > without-contrib. So I tend towards your latter option. > > > The latter would be my preferred option, but then I've never understood > the > > argument for distro packages instead of pip. > > On reasonable distros, you can set things so you get critical updates (and > only critical updates) automatically. That is very attractive for low- > personnel production sites, and there's no reasonable way to achieve this > with > pip. > > My 2 cents, > Shai. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f9b26528-8396-430a-b4be-20605d56bebb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
