On Sat, Mar 2, 2013 at 11:38 AM, Per-Olof Åstrand <[email protected]>wrote:
> First, I would like to give all my compliments to the persons that made > Django what it is. Although my background is in scientific computing since > 25 years back (using python, numpy, scipy, among other things), I came into > contact with Django 0.91 in 2006 when one of my students used it in a > project. I have used it myself since 2009 in a private genealogy project > which is alive at webfactional.com (running django trunk) since a year > ago. > > I can perhaps spend a couple of hours per week on this hobby project, so I > have realized that I have a quite different view on what should be included > in django.contrib than what seems to be the present view on the django > mailing list. Rather than slimming django core, I would like to see more > "best practice" apps included in django.contrib. I (and I think/hope many > with me) simply do not have the time to browse the jungle of third-party > apps to test, compare and find out what might work for my purpose. I would > like to see that some of these decisions are made for me by more > experienced users/developers, if possible. When I see comments on that > admin should be developed separately, I disagree. At least I would like to > see a discussion early in each release cycle to find out if there are any > third-party apps "worthy of" being included in django.contrib, and perhaps > one can be included in each release cycle. > > I see another perspective on this from my work. For our python software, I > allow python, numpy, scipy and a few more packages. To include more > packages is a big deal for a huge number of reasons (project complexity, > learning curve, maintenance, etc). On the other hand, the packages included > in the project should be exploited fully. I think Django face the same > problem in many environments; it is a big deal if a particular third-party > app can be included or not. > > A suggestion is django-debug-toolbar. I think that is the kind of app new > users should learn how to use relatively early in a learning process. Also > if included django, a lot of best practice programming in views and > templates can be documented in a better way if django-debug-toolbar is > available. For me, this is a no-brainer if the app authors are interested, > license conditions is fulfilled, core developer capacity is available, etc.. > > A second suggestion is django-mptt. It is a text-book approach that has > many use-cases, and I cannot see that there is a need for more than one > standard implementation (although there are also other ways to implement > trees which have their use-cases). > > I realize I represent a user group that is not very visible, with only > occasional comments on django-users and in tickets, but I hope my opinions > are welcome anyway. > Hi Per-Olof, Thanks for your feedback. I'll completely agree that django-debug-toolbar is a very useful package. I haven't had occasion to use django-mptt myself, but I've heard many people speak well of it. I'm sure it would be easy to come up with a dozen or more packages that are similarly useful and high quality. However, I don't believe that adding these packages to django.contrib will provide any benefit at all. Adding a package to core won't make the code better. It will be the same code, just in a different repository. Adding a package to core won't increase the number of people working on it, either. The Django core team is already stretched fairly thinly -- adding more responsibilities must result in either parts of the core will get less attention, or we need to add more people to manage the core. However, someone who is a good maintainer of a third-party package may not be the best person to add to core, so all we would be doing is giving them access to a specific part of the contrib tree… which means that once again, nothing has changed -- we've just changed the repository holding the code. The best you can hope for is that by putting some sort of "official" moniker on it, this will attract more attention and thus more contributors. However, this also means that unofficial projects will find it harder to get contributors, regardless of how good they might be. In some cases, this will be a good thing -- nobody benefits from having a dozen social auth integration libraries, for example. But in other areas -- especially when there are multiple technical approaches -- encouraging a monoculture isn't a good idea. There's another side effect of putting more packages in contrib -- you slow the rate of release of the contrib packages to the rate of release of Django itself. Consider, for example, localflavor. The Australian localflavor hasn't needed an update for several years -- there have been no new states added, and phone number formats haven't changed. The Indonesian and Italian localflavors have both required changes due to changes in provincial naming. However, if the change to Italian provinces occurs just after the release of Django 1.4, we can't issue an update until Django 1.5. What we need is to be able to issue an update of *just* the Italian localflavor. Moving to separate packaging allows us to do this. The problem is also observable in other contrib packages. There's absolutely no reason that the release schedule of Django's admin needs to be tied to that of Django itself. We should be able to release a new version of Admin independently of Django core, and vice versa. When new changes or features are introduced, there might well be a coordinated release of both, but that coordination can occur without the two packages being locked into the same repository. The aim behind making django.contrib smaller is to make it easier to manage the core of Django. By taking standalone parts of Django (which is what all the parts of contrib should be), and putting them into separate repositories, we're divesting control and making the core team responsible for less. The end goal is to focus the attention of the core team on the core, and let the community assist in making the broader Django environment richer. Now, of course, this doesn't address your base complaint/request -- that the ecosystem of Django packages is large; it's difficult to know which packages are up to date, tested, reliable and documented; and by expanding django.contrib, you would need to spend less time choosing packages, and more time using them. I put it to you that in order to achieve this, we don't need to expand contrib -- we need a different beast altogether. djangopackages.com already does what you describe to a certain extent -- tracking packages by category, and providing some objective statistics that might be useful indicators of quality (e.g., number of downloads, commit history, committer names, documentation, and so on). Another approach would be for someone to take on the task of curating a collection of packages. In some respects, this is what Pinax does. The problem -- and also the opportunity -- is that "the best package for X" is a matter of taste, so there's potential for more than one curated group in this space. There might even be the potential to sell this as a service -- i.e., for someone to sell their engineering 'taste' by way of a curation service. Now - I'm not saying that the core team should *completely* divest itself of all responsibility here. I think there's definitely room for the core to assist the broader ecosystem, but mostly in the way of providing infrastructure, rather than an 'official' imprimatur. This is one area where I think Flask has a model worth following. Flask maintains a registry of extensions [1]. Anyone can submit a package to this registry; packages must follow standardized formatting rules, and the list is moderated to enforce those rules. This ensures that there is an index of all available Flask packages, and that this index maintains basic quality control. [1] http://flask.pocoo.org/docs/extensiondev/ Flask also has the concept of approved extensions -- these are extensions that are blessed, and as a result, form part of the testing cycle for new Flask releases. The constraints for approved packages are more strict than for normal indexed packages, and also have to provide guarantees about project maintenance, providing additional quality guarantees. Personally, I think the solution to your original problem lies somewhere between all three -- an analog of Flask's packaging tools for Django's community, overlaid with tools that provide objective (a-la djangopackages.com) and subjective (a-la Pinax) measures of quality. Of course -- this idea all hinges on tools that don't currently exist. But the fact that the tools don't currently exist doesn't mean that the better solution is to just pack everything into contrib. I hope I've been able to explains the reasoning behind Django's current strategy with regards to contrib. If you think I've missed something important here, please let me know -- just be aware that any suggestion that hinges on "you should volunteer to do more work, because that would help me a great deal" isn't especially compelling on my part. Yours, Russ Magee %-) -- 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.
