9 ms·

In general, my take is: 'bout time. Even if this particular project doesn't make it into django.contrib, it is nice to see movement in this area.

IgorPartola 13y ago
It never will: Requirements Django 1.5+ Python 2.7+ or Python 3.3+ django-braces django-extra-views django-floppyforms django-rest-framework Sphinx (for documentation) Django comes all bundled together or not at all. IIRC, this was one of the reasons why bcrypt wasn't enabled for so long: the canonical Python library came bundled with C code. I am excited for this, but I don't see it going into django.contrib.
- andrewingram 13y ago
  FYI: I wouldn't be surprised if the parts of django-braces and django-extra-views we're using end up making it into django.core. As for the other dependencies (floppyforms and rest-framework), I'm sure there'll be further discussions if and when we start pushing for inclusion in django.contrib.
  - IgorPartola 13y ago
    I think that's reasonable. Another thing to watch out for is Django's support for older versions of Python. While I personally know the pain of "hey this feature/syntax isn't supported in 2.6 yet", Django's team is pretty strict about that. In either case, good luck. The project looks great.
    - maaku 13y ago
      The next version of Django (current git master) will drop support for Python 2.6.
- huxley 13y ago
  I think the versions of Django or Python don't play into it, if it was to be included in contrib it would probably happen around Django 1.7+. By then Python 2.7/3.3 will likely be the minimum required versions of Python. Django's docs already use Sphinx as an optional install. Django-braces and Django-extra-views are excellent but modest extensions to Django's class-based views and would likely either become part of Django or be good starting points for extending Django's generic CBV IMHO. So the only really controversial additions would be django-floppyforms and django-rest-framework. I seem to recall that there has been talk in recent years about all or parts of contrib being de facto split-off from core (as opposed to the technically distinct but included status of being a contrib module), so that might factor into it too.
  - mazelife 13y ago
    Your remember correctly. At the moment, the momentum seems to be too move things out of contrib (e.g. localflavor, comments). The possibility of doing the same with the admin has come up at a couple of DjangoCon panels with the core devs and on the django-dev mailing list regularly in the last few years. Two quotes from core devs on the mailing list suggest to me there isn't necessarily a consensus about what to do: Alex Gaynor: "Perhaps this is too far in the future looking. But at a certain point the admin must become a separate project."" Russell Keith-Magee: "[The] admin is a contrib app for a reason -- it's a standalone app. It's entirely possible to recreate everything Django's admin does as a third party application. If a third party admin implementation were to appear that had a better feature set than the existing admin, and/or a better codebase to start from, and there was a reasonable migration path from old admin configurations to new admin configurations, that might be a viable way to get a new admin into Django." In any case, I wouldn't be in such a hurry to rush this into django.contrib, even if that were possible (and it's not). I think that there's a lot to be said for decoupling the admin from Django's development cycle and keeping it under the management of it's own team. Otherwise, there's a risk of once again ending up right back where we are now.
    - csense 13y ago
      From a development standpoint, it's good to have Django administration be a separate app, because a modular codebase is easy to develop. If you're a Django user, modular is good, because you can get performance and security benefits by turning off parts of the framework you don't use. From a distribution or marketing standpoint, however, one of the best features for Django beginners -- and one of the project's original motivations -- is the ability to quickly get a basic CRUD app running, so basic usage and data entry can start to happen while advanced features are still under development. If Django doesn't have the admin functionality out of the box, and instead the user has to confront a bewildering array of third-party add-ons, it makes the framework less attractive to new users. If Django is trying to morph into a minimalist framework like Flask, where only the most basic functionality is included, it might lose too much of what makes it strong.

IgorPartola 13y ago

It never will: Requirements Django 1.5+ Python 2.7+ or Python 3.3+ django-braces django-extra-views django-floppyforms django-rest-framework Sphinx (for documentation) Django comes all bundled together or not at all. IIRC, this was one of the reasons why bcrypt wasn't enabled for so long: the canonical Python library came bundled with C code. I am excited for this, but I don't see it going into django.contrib.

andrewingram 13y ago
FYI: I wouldn't be surprised if the parts of django-braces and django-extra-views we're using end up making it into django.core. As for the other dependencies (floppyforms and rest-framework), I'm sure there'll be further discussions if and when we start pushing for inclusion in django.contrib.
- IgorPartola 13y ago
  I think that's reasonable. Another thing to watch out for is Django's support for older versions of Python. While I personally know the pain of "hey this feature/syntax isn't supported in 2.6 yet", Django's team is pretty strict about that. In either case, good luck. The project looks great.
  - maaku 13y ago
    The next version of Django (current git master) will drop support for Python 2.6.
huxley 13y ago
I think the versions of Django or Python don't play into it, if it was to be included in contrib it would probably happen around Django 1.7+. By then Python 2.7/3.3 will likely be the minimum required versions of Python. Django's docs already use Sphinx as an optional install. Django-braces and Django-extra-views are excellent but modest extensions to Django's class-based views and would likely either become part of Django or be good starting points for extending Django's generic CBV IMHO. So the only really controversial additions would be django-floppyforms and django-rest-framework. I seem to recall that there has been talk in recent years about all or parts of contrib being de facto split-off from core (as opposed to the technically distinct but included status of being a contrib module), so that might factor into it too.
- mazelife 13y ago
  Your remember correctly. At the moment, the momentum seems to be too move things out of contrib (e.g. localflavor, comments). The possibility of doing the same with the admin has come up at a couple of DjangoCon panels with the core devs and on the django-dev mailing list regularly in the last few years. Two quotes from core devs on the mailing list suggest to me there isn't necessarily a consensus about what to do: Alex Gaynor: "Perhaps this is too far in the future looking. But at a certain point the admin must become a separate project."" Russell Keith-Magee: "[The] admin is a contrib app for a reason -- it's a standalone app. It's entirely possible to recreate everything Django's admin does as a third party application. If a third party admin implementation were to appear that had a better feature set than the existing admin, and/or a better codebase to start from, and there was a reasonable migration path from old admin configurations to new admin configurations, that might be a viable way to get a new admin into Django." In any case, I wouldn't be in such a hurry to rush this into django.contrib, even if that were possible (and it's not). I think that there's a lot to be said for decoupling the admin from Django's development cycle and keeping it under the management of it's own team. Otherwise, there's a risk of once again ending up right back where we are now.
  - csense 13y ago
    From a development standpoint, it's good to have Django administration be a separate app, because a modular codebase is easy to develop. If you're a Django user, modular is good, because you can get performance and security benefits by turning off parts of the framework you don't use. From a distribution or marketing standpoint, however, one of the best features for Django beginners -- and one of the project's original motivations -- is the ability to quickly get a basic CRUD app running, so basic usage and data entry can start to happen while advanced features are still under development. If Django doesn't have the admin functionality out of the box, and instead the user has to confront a bewildering array of third-party add-ons, it makes the framework less attractive to new users. If Django is trying to morph into a minimalist framework like Flask, where only the most basic functionality is included, it might lose too much of what makes it strong.