Re: Removing formtools from contrib (and call for maintainers)
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 > wrote: > > > > > On Fri, Jul 11, 2014 at 10:52 PM, Tim Graham > 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
Re: Removing formtools from contrib (and call for maintainers)
I think after the 1.7 release will be a good time. On Tuesday, July 15, 2014 8:35:23 AM UTC-4, Gordon wrote: > > 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 >> wrote: >> >> > >> > On Fri, Jul 11, 2014 at 10:52 PM, Tim Graham >> 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
