is it time to start deprecating parts of contrib

[ptone]

At DjangoCon.us there was positive reception to Jacob's thoughts that
Django core could be leaner - people liked the kernel analogy.

Talk of reducing contrib has been around a long time.

Per policy, it takes 3 minor versions to remove something from Django
- near as I can tell, a PendingDeprecation warning could be reversed
if there was a large change of opinion.

There is perhaps no more humorous a line in all of the Django docs
than this:

"Databrowse is very new and is currently under active development. It
may change substantially before the next Django release."

My top nominations for contrib apps to go away are:

Databrowse
webdesign
formtools

What are yours?

Given the 3-version deprecation process, I figure it could be time to
start pulling some weeds.

-Preston

[Jannis Leidel]

On 20.09.2011, at 14:13, ptone wrote:

> At DjangoCon.us there was positive reception to Jacob's thoughts that
> Django core could be leaner - people liked the kernel analogy.
>
> Talk of reducing contrib has been around a long time.
>
> Per policy, it takes 3 minor versions to remove something from Django
> - near as I can tell, a PendingDeprecation warning could be reversed
> if there was a large change of opinion.
>
> There is perhaps no more humorous a line in all of the Django docs
> than this:
>
> "Databrowse is very new and is currently under active development. It
> may change substantially before the next Django release."
>
> My top nominations for contrib apps to go away are:
>
> Databrowse
> webdesign
> formtools

FYI, formtools is unlikely to go away anytime soon, as we've just
recently added a new class based views wizard [1]. Next step would
be to refactor the form preview tool to be class based, too [2].

Jannis

1: https://docs.djangoproject.com/en/dev/releases/1.4/#new-form-wizard
2: https://code.djangoproject.com/ticket/16174

[Carl Meyer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/20/2011 06:13 AM, ptone wrote:
> At DjangoCon.us there was positive reception to Jacob's thoughts that
> Django core could be leaner - people liked the kernel analogy.
>
> Talk of reducing contrib has been around a long time.
>
> Per policy, it takes 3 minor versions to remove something from Django
> - near as I can tell, a PendingDeprecation warning could be reversed
> if there was a large change of opinion.
>
> There is perhaps no more humorous a line in all of the Django docs
> than this:
>
> "Databrowse is very new and is currently under active development. It
> may change substantially before the next Django release."
>
> My top nominations for contrib apps to go away are:
>
> Databrowse
> webdesign
> formtools

I would be +1 on starting with deprecation of both databrowse and
webdesign, -0 on formtools at this point for the same reason Jannis
mentioned; it is actually actively maintained and used, and recently got
some major improvements. In the abstract I do think that formtools is a
fine candidate to be an external app rather than live in contrib, I just
think we may as well start with the lower-hanging fruit here.

Databrowse could easily be spun off into an external app if anybody
cared to maintain it.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk547rMACgkQ8W4rlRKtE2cLvwCg6x/sCROjtIG6GBBFuQljV4pw
u+IAoMrXUYg7MLr61CNKPRYTfhPFIZWu
=6hxI
-----END PGP SIGNATURE-----

[Justin Holmes]

It depends how surgical this discussion is; if we're at the model
level, then it's pretty clear that we need to reinvent auth.User and
deprecate functionality accordingly.

I'm not hearing anyone say that contrib.auth is an undesired battery
tout court, but the sentiment that it fails to "get out of the way" is
basically universal, and has been for some time.

A small group of us began a brainstorm on day 2 of the sprints in
Portland. It is ongoing here:

https://code.djangoproject.com/wiki/UserHasABadMotivator

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>

--
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

[Paul McMillan]

I'm also +1 on deprecating Databrowse.

+0 on webdesign, since it's functionality that's probably in transient
use by the more invisible members of our community. If it were more
fleshed out, I'd say leave it, but since it's just that single
function, it should probably go eventually.

-Paul

[Markus Gattol]

+0 on webdesign, since it's functionality that's probably in transient
use by the more invisible members of our community. If it were more
fleshed out, I'd say leave it, but since it's just that single
function, it should probably go eventually.

I'd miss it even though it's just a tiny piece of code and trivial, it's quite useful when you mock up a site and thus need some text to get a feeling for its layout when there's lots of text involved. I am sure, as you say, there are quite a few people out there who would miss it too.

[Gabriel Hurley]

+1 on deprecating databrowse. Dead code should be excised.

As for webdesign, why not roll the one piece in it (the marginally-useful lorem tag) into the main library and deprecate the hook in contrib?

-0 on deprecating formtools.

For the sake of argument I could see admindocs being deprecated and spun off into it's own app.

Otherwise I can't see any other contrib modules being deprecated in the near future.

All the best,

    - Gabriel

[ptone]

I saw enough +1 on deprecating databrowse that I've opened a ticket:

https://code.djangoproject.com/ticket/16907

further action can happen there.

-Preston