I think the "blessed packages" idea is a good one - especially if it entails inclusion into the build/test system. At the moment it is very difficult to know if any changes that are made will affect third party libraries unless you have an extremely good grasp of an entire sub-system (ORM, I'm looking at you). On the other hand, should changes to core be prevented from landing if it breaks these blessed libraries using undocumented features?
As for formtools, are there any proposals for features that would make breaking it away from core profitable? If it hasn't changed in the last 18 months it certainly doesn't mean it will gain features just because it is extracted. Also, I know that I'm wary of using a third party library if it hasn't been updated in over a year but I'm more than happy to use a non-updated package in core. Josh On Saturday, 12 July 2014 09:25:48 UTC+10, Russell Keith-Magee wrote: > > > On Fri, Jul 11, 2014 at 10:52 PM, Tim Graham <timog...@gmail.com > <javascript:>> wrote: > >> continuing >> https://groups.google.com/d/topic/django-developers/km2xIHM-gIA/discussion >> under a better subject (was "FormWizard needs confirmation step logic. >> ticket #21644")... >> >> I'd like propose removing formtools from contrib. >> >> Reason to move it out: >> - Allow more maintainers next to Django core devs >> - Release individually from Django (perhaps more often) on PyPI as >> django-formtools >> >> Reasons something should be in contrib (from Marc Tamlyn): >> >> - The application is of vital importance to the vast majority of Django >> sites, and needs to be done "correctly". Examples include auth and >> staticfiles, sessions. >> - The application closely depends on internal, undocumented features of >> Django or is strongly intertwined with the core features like the ORM. Such >> applications are often very difficult to maintain their feature support >> across multiple versions of Django. Examples include gis, postgres, >> contenttypes. >> >> (Marc again): "To me, formtools meets neither of these requirements. It >> is not a 90%+ use case application like the admin or auth, and I don't >> believe there is much to it that is not workable outside of Django itself. >> It is useful, and does not deserve to be abandoned (like comments). Under >> github.com/django seems ideal to me." >> > > The definition that we used "back in the day" was "Contrib is a collection > of optional, defacto standard implementations of common patterns." > > * Optional - if we deleted the directory, Django would still work, and > you could build the deleted functionality yourself. > * Defacto Standard - This is "the way you should do it". No point in > having multiple auth or session frameworks for 99% of users. > * Common Patterns - Things that needs to be done, so lets give them an > obvious way to do it. > > By that definition, formtools falls is caught as a common pattern. Wizards > may not be needed on every website, but Wizard functionality is definitely > something I've had to build a bunch of times, and it's fiddly to build it > yourself. Having an "in the box" way to do wizards was helpful for those > cases. > > One of the major reasons to do this back in the day was because Python > packaging was such a mess, and the only way to make sure people had a good > out-of-the-box experience was to package all the bits they'd need. This is > no longer true. To that end, I'm fully in support of repackaging most of > contrib as separate modules, with their own release schedule, maintenance > teams, and so on. > > However, the other role that contrib plays is drawing attention to > specific packages as trusted sources of functionality. *This* is a role > that still exists, but it's one that I don't know we're doing a good job > with at the moment. > > I've suggested this before, but since we seem to be in a new round of > purging stuff from contrib, I'll suggest it again: should we be building a > repository of "trusted" packages? > > By this, I mean a collection of packages that have been vetted by the core > team as "well built and important" - exiles from contrib are obvious > candidates, but it might also include packages that are completely external > like ReST Framework. > > The point here isn't to take over the hosting, project management, or > anything else. It's purely to say "We know this package exists, and you > should too, because it's important". What we'd be adding is: > > * An index of these "trusted" packages somewhere in our docs/website. > Maybe a management command to help "search" for specific functionality? > (./manage.py find "wizard" -> "django-formtools: A package of useful form > utilities, include wizards.... ") > > * Additions to our build system to make sure these "trusted" packages are > tested against new Django releases. We're about to push out 1.7 - can > anyone say with confidence what impact this release will have on the major > players in our ecosystem? If we run their tests with Django 1.7, we can at > least report (to the community, if not to the project maintainers) what > impact an upcoming release will have on their packages - so we don't end up > with the situation where we push out a release, and *then* we discover that > all the important apps in the community don't work. > > As it stands, we're purging a bunch of stuff from core, and some of that > stuff just needs to die - but some of it is very useful functionality. Many > of these projects end up with little more than a Github README by way of > project identity. They deserve a better fate than this. > > Thoughts? > > 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 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/e7db3e75-5c18-4064-b3c8-9ee6594fc133%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
