Josh, as I posted on the other thread, my observation is that not many core developers seem interested in contrib.formtools these days. It was added by Adrian in 2006, but as you noted, it hasn't received much love lately. If we break it out and find people that are enthusiastic about maintaining it, I believe it'll have a better chance to improve.
A curated list of packages makes sense (I'd opt to add this functionality djangopackages.com if possible rather than reinventing something new). I'm skeptical of the idea of integrating 3rd party packages builds with our own build system. Shouldn't it be up to those maintainers to test their packages with new versions of Django and report bugs to us? I don't think we have the resources to do it the other way around. On Friday, July 11, 2014 8:24:59 PM UTC-4, Michael Manfre wrote: > > Python packaging is definitely a lot better than it was and starting to > move the contribs to their own repos and packages would be a good thing to > do. > > Regards, > Michael Manfre > > > On Fri, Jul 11, 2014 at 8:15 PM, Josh Smeaton <josh.s...@gmail.com > <javascript:>> wrote: > >> 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> 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-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/django-developers/e7db3e75-5c18-4064-b3c8-9ee6594fc133%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/82bb89cc-1497-4f07-a2cb-59954b63566e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
