*: Create Django 3.2 ports for net-mgmt/netbox

[kai]

Summary

Create Django 3.2 ports for net-mgmt/netbox

* Django 2.2 is currently the "default" version in the ports tree due
  its long term support until April 2022.  Thus ports that are assigned
  to that version will exist until then.

  The following ports are required to make the upgrade of
  net-mgmt/netbox to the 2.11 release possible because it requires
  Django 3.2.

  - devel/py-dj32-django-rq
  - www/py-dj32-django-auth-ldap
  - www/py-dj32-django-cacheops
  - www/py-dj32-django-cors-headers
  - www/py-dj32-django-debug-toolbar
  - www/py-dj32-django-filter
  - www/py-dj32-django-js-asset
  - www/py-dj32-django-mptt
  - www/py-dj32-django-prometheus
  - www/py-dj32-django-redis
  - www/py-dj32-django-tables2
  - www/py-dj32-django-taggit
  - www/py-dj32-django-timezone-field
  - www/py-dj32-djangorestframework
  - www/py-dj32-drf-yasg

* Add/update the related CONFLICTS_INSTALL entries as well.

Test Plan

poudriere -> OK (11.4-RELEASE, py36, py37, py38, py39)
portlint/portclippy -> OK
make index -> OK

Note:
Although the py-dj32-* ports were created on the basis of their respective originals, Phabricator shows that they were created on the basis of the py-dj31-* ports.

For instance, www/py-django-auth-ldap was copied to www/py-dj32-django-auth-ldap but Phabricator shows that some lines were copied from www/py-dj31-django-auth-ldap.

By the way, the py-dj31-* ports will only stay in the Ports tree until the end of this year, because the extended support of Django 3.1 will have expired by then. (Deprecation of the www/py-django31 port should start somewhere around in 2021Q3).

[kai]

@sunpoet: It's ok with you if you take maintainership of the new ports devel/py-dj32-django-rq , www/py-dj32-django-debug-toolbar and www/py-dj32-django-redis ?

[kai]

• Assume maintainership of the new ports devel/py-dj32-django-rq, www/py-dj32-django-debug-toolbar and www/py-dj32-django-redis as well.

• Remove Created by lines from the new Django 3.2 ports.

[koobs]

Apart from requiring new copies of django ports for each supported version, where proper django support in the framework would be preferred, the change good @kai

Can we sort out the category for django-rq (to www/) before this change lands?

Also, if we have known EoL dates for any django ports now, we could get a headstart by setting expiration_date, buuuuuuuuuuuut the ports handbook says ....

It is possible to set DEPRECATED without an EXPIRATION_DATE (for instance, recommending a newer version of the port), but the converse does not make any sense.

It'd be cool to be able to set eol dates that are known ahead of time so users can prepare/know well in advance. This also would give us opportunities to start warning earlier (automatically)

I wonder what breaks if EXPIRATION_DATE is set without DEPRECATED. :)

[1] https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-deprecated.html

[kai]

• Place py-dj32-django-rq to the www category as suggested by @koobs.

[kai]

In D30977#700968, @koobs wrote:

Can we sort out the category for django-rq (to www/) before this change lands?

It's done for py-dj32-django-rq, but for py-django-rq and py-dj31-django-rq approval from @sunpoet is required to move these ports to www/ as well. IMHO, I would wait for it until net-mgmt/netbox is updated to 2.11.x . It's easier then to move both ports because they don't have any consumers at this point.

Also, if we have known EoL dates for any django ports now, we could get a headstart by setting expiration_date, buuuuuuuuuuuut the ports handbook says ....
[...]

As soon as the new Django 3.2 ports are present in the Ports tree and net-mgmt/netbox is updated to 2.11.x, I plan to create another review regarding the deprecation/expiration of www/py-django31 and the related ports. The discussion about EXPIRATION_DATE/DEPRECATED could then be continued in the newly created review.

[sunpoet]

In D30977#697015, @kai wrote:

@sunpoet: It's ok with you if you take maintainership of the new ports devel/py-dj32-django-rq , www/py-dj32-django-debug-toolbar and www/py-dj32-django-redis ?

I'm OK this that.
BTW, I'll put NO_ARCH before CONFLICTS_INSTALL.

[sunpoet]

In D30977#700968, @koobs wrote:

Can we sort out the category for django-rq (to www/) before this change lands?

I'm not sure if we have to put django-* in www.
At least we have:

• devel/py-django-rq
• graphics/py-django-easy-thumbnails
• mail/py-django-mailbox
• mail/py-django-mailman3

[kai]

• Move devel/py-dj32-django-rq back to devel/
• Set @sunpoet as maintainer for devel/py-dj32-django-rq, www/py-dj32-django-debug-toolbar and www/py-dj32-django-redis and change the order of CONFLICTS_INSTALL and NO_ARCH there as well.

[kai]

In D30977#701349, @sunpoet wrote:

In D30977#697015, @kai wrote:

@sunpoet: It's ok with you if you take maintainership of the new ports devel/py-dj32-django-rq , www/py-dj32-django-debug-toolbar and www/py-dj32-django-redis ?

I'm OK this that.
BTW, I'll put NO_ARCH before CONFLICTS_INSTALL.

Ok, the three new ports have been updated accordingly, including the order of CONFLICTS_INSTALL and NO_ARCH. FWIW, portclippy now complains that both variables aren't order.

[kai]

In D30977#701350, @sunpoet wrote:

In D30977#700968, @koobs wrote:

Can we sort out the category for django-rq (to www/) before this change lands?

I'm not sure if we have to put django-* in www.
At least we have:

• devel/py-django-rq
• graphics/py-django-easy-thumbnails
• mail/py-django-mailbox
• mail/py-django-mailman3

In this case it makes sense to look at this in a separate diff. Maybe then, as soon as there is a consensus, we can move all of these ports to www/ at once.