I mentioned this in the other thread but I will post here as well since it has moved. I would be interested in being part of this. Is there any sort of timeline on the move or is it just a proposal at this time?
On Saturday, July 12, 2014 12:55:52 PM UTC-4, Jannis Leidel wrote: > > Hi all, > > I’m one of the core devs who spent a non-trivial amount of time working on > formtools — last to revamp the form wizard implementation there back in > 2012 (based ironically on Stephan Jaeckel’s django-formwizard app). And > I’ve put a non-trivial amount of time into spinning out another contrib app > — localflavor – with a net positive effect. It’s what made me re-evaluate > the idea of putting more contrib apps in own repos under the django Github > umbrella project. django-localflavor has not only received a README as Russ > put it jokingly, but a complete documentation that didn’t exist in that > form before and a extensive test suite. This in turn has been possible by > many new non-core contributors (38 in total), including some of them who > have have received push permissions as well (e.g. Erik Romijn who is now a > Django core dev as well). > > If there is a chance that some feel like we’re losing an integral part of > Django by moving formtools into an own app, I’m not going to pry it from > their hands. But if there is more interest in maintaining it outside than > inside of Django, I’m happy to help splitting it off. > > To me the whole idea of “blessed” apps is nothing more than handwaving > right now because there are lots of unanswered hard questions about the > blessing process. Such a project would require a community site built, > maintainer team and enough lieutenants to make sure it doesn’t diverge too > much from Django core development. Heck, it even may require answering the > question “What is a good Django app?”, something which is in the spirit of > innovation a slippery slop at best. So for now that imaginary “index” is > the PyPI, as for any other Python package, and the “blessing” happens by > the community via the common tools of public opinion like reviews, blog > posts, conference talks, screencasts, etc. > > Whether djangopackages.com is capable of being such a platform, I don’t > know. As far as I know it’s mostly self-service for the app authors, which > is also the reason why it has some incomplete data about app features (the > “grids”). > > Jannis > > > On 12.07.2014, at 01:25, Russell Keith-Magee <rus...@keith-magee.com > <javascript:>> 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-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/CAJxq849zwbaMTyrm2c9re1zMhH%3DBdpRu_mbR3-tD1rNgRKXOeg%40mail.gmail.com. > > > > 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/def56cca-239c-42cf-9750-7665e5872b2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
