On Saturday, March 2, 2013 8:00:22 AM UTC+1, Russell Keith-Magee wrote: > > > On Sat, Mar 2, 2013 at 11:38 AM, Per-Olof Åstrand > <[email protected]<javascript:> > > 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 %-) > > Hi Russ,
Thanks for your very detailed reply that I think very well summarizes and motivates the view that can be perceived by following the Django mailing lists, and also was the reason for that I wrote the first message. I also learned some new things; I indeed need to read up on Flask. Perhaps Django needs something to replace contrib; I will not argue against that. But packaging is important not only from a developer perspective but also from a user perspective. Let's take the numpy array as an example, and let's, for the sake of argument, assume that we can all agree on that the numpy array is much more flexible and efficient than the python array. Thus there is no reason whatsoever to not use the numpy array when it is available. From the developer's perspective I can only assume that the numpy array is doing just fine in numpy, and there is no reason to include it in python itself. Still, I am certain that if someone coded something for django core using the numpy array it would be dismissed. That would of course be the correct decision since django cannot open up for using numpy and perhaps 20 other packages that are not absolutely necessary for developing django. So which package something belongs to is important, and everything that is included in various django-xyz packages would be "second-rank" not because of the quality of the code but since there will be a high barrier in the user community before it is used. So that is why I would like to see django include more functionality not less, and that includes functionality that also "equally well can live in an external package" if it is useful enough for a broader community. Instead of localflavor, I would like to take South as a typical example. I am not sure what the policy is for South and I have only followed it from distance, but as far as I can understand at least a part of South will be included in Django (however, I would like to see all of it included). It has a certain degree of complexity, a good and nontrivial implementation, used by a lot of people, a developer willing to contribute to Django and accepted as a core developer, but it is not the only option for schema migration for the Django community. I might be wrong, but I interpret your answer as you would like to see infrastructure for schema migration included in Django, but not a full-fledged schema migration tool. If I understood this point right, I think we are at the core of the concern that I tried to express in my first message. Best regards, Per-Olof -- 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.
