On 31 touko, 16:58, Michael Manfre <[email protected]> wrote: > On Fri, May 31, 2013 at 8:51 AM, Marc Tamlyn <[email protected]> wrote: > > In terms of non-core backends (and I include Oracle in this) - my > > preferred option would not be to include them all in core Django, but to > > collate them in and manage them under the Django project - i.e. > > github.com/django/django-mssql. These are "looked after" by the Django > > project to ensure that there is one place to find that code base, but are > > externally maintained. This is effectively similar to the way that > > localflavor is progressing, although we should wait and see how that plays > > out first - there are some teething issues there at the moment. > > Django-mssql can be installed with pip and the project's pages (code, docs, > etc) are the first several hits on the popular search engines. Moving a > repo for the sake of moving it is a non starter for django-mssql. I'm > guessing that most of the other 3rd party database backends would object as > well, especially those not currently hosted on github. Relocating a repo is > disruptive to the developer(s) and also the users. I've gone through this > once when I moved the project from google code to bitbucket, which had the > huge benefit of making it easier and more enjoyable for me to work on the > project. > > The disruption associated with relocating the project in to the core would > at least be balanced by many benefits. Just to name a few, easier test > integration, backend's issues in trac, no more django version/feature > checking in the backend, and more eyes watching commits (even if no one > else works on the backend). There is also the potential of easily fixing > the poorly named flags on DatabaseFeature.
>From ORM coding perspective the issue is this: I want the ability to alter backends API at will. Of course, we have already changed the API when needed (transaction handling changes, connection initialization changes for example), and we will likely do this in future, too (support for database schemas for example). Of course, this doesn't mean the API should be changed without reason. But if there is a reason, then we must be able to change the API. (Same goes for other internal APIs, too). If unstable APIs are OK for 3rd party backend devs, then all is OK. I don't think there is point in moving code anywhere for the sake of moving it. The reason must be making development easier for both 3rd party devs and core devs. I don't see much difference for users, pip install is easy enough to do. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
