Removing formtools from contrib (and call for maintainers)

[Tim Graham]

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."

Absent any objections, is anyone interested in leading the effort?

[Greg Chapple]

I think this is a good idea, and I'd be interested in getting involved in this effort. I've been wanting to get more involved so I'll put my name forward for this, and all that it may entail!

Greg

--
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.
To post to this group, send email to django-d...@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/fe893559-def4-4e50-9818-ef2dd1cb8997%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Russell Keith-Magee]

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 %-)

[Josh Smeaton]

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

[Michael Manfre]

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

--
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.
To post to this group, send email to django-d...@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.

[Tim Graham]

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.

[Jannis Leidel]

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

> --
> 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.
> To post to this group, send email to django-d...@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/CAJxq849zwbaMTyrm2c9re1zMhH%3DBdpRu_mbR3-tD1rNgRKXOeg%40mail.gmail.com.

[Gordon]

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?

[Tim Graham]

I think after the 1.7 release will be a good time.