www/py-djangorestframework: Update to 3.11.0

[kai]

Summary

* Switch the port to Django 2.2 (current LTS release) as well because
  Django 1.11 is End-of-Life since April.  Do the same for www/py-drf-yasg.

* Change RUN_DEPENDS of www/py-django-annotations and www/seahub to use
  www/py-djangorestframework36 for a while because both ports have no
  support for Django 2.0+ (yet).

* Drop the Python 2.7 support of the remaining consumers to avoid breakage
  of "bulk -a".

* Mark both repo-copied ports www/py-dj22-{djangorestframework,drf-yasg} as
  deprecated because they're obsolete now.

Test Plan

• poudriere -> OK (11.3-RELEASE amd64 for each py27, py35, py36, py37 and py38 flavor)
• Test of reverse dependencies -> OK
• poudriere bulk -n -a -t with BUILD_ALL_PYTHON_FLAVORS=yes in make.conf -> OK

Please see also https://wiki.freebsd.org/Ports/Django for an overview about the actual progress of switching the remaining Django 1.11 ports to Django 2.2.

[sunpoet]

LGTM. Thanks!

[ultima]

According to version 3.11.0[1] (the latest release), this port still supports django 1.11. I'm a bit unclear as to why the 3.6.4 version exists. As far as I can tell, the only reason to make another version of djangorestframework would be to support python 2.7 as it was dropped in 3.10 or setting a new django default version. Is there a reason for not upgrading past version 3.6.4?

I think I would rather stay on the newest supported version of djangorestframework that supports django 1.11, assuming there are no compatibility issues. (which I'm not currently aware of any)

[1] https://github.com/encode/django-rest-framework/tree/3.11.0

[kai]

In D24850#549002, @ultima wrote:

According to version 3.11.0[1] (the latest release), this port still supports django 1.11.

That's right and I'll come back to it at the end of this comment.

I'm a bit unclear as to why the 3.6.4 version exists. As far as I can tell, the only reason to make another version of djangorestframework would be to support python 2.7 as it was dropped in 3.10 or setting a new django default version.

The port www/py-djangorestframework36 is a remnant of the time when Django 1.8 and Django 1.11 co-existed in the Ports tree. Django 1.8 then was the "default" version and reached its End-of-Life, which made an migration to Django 1.11 necessary.

Because djangorestframework dropped the support for Django 1.8 with the 3.7.x branch, www/py-djangorestframework36 was created via repo-copy in rP467652 and was used then as a transitional package for the www/seahub and www/py-django-annotations ports to retain backwards compatibility with Django 1.8.

Django 1.11 is now End-of-Life since April 2020 and there's already progress (see the wiki link in the summary from above) to switch to Django 2.2 (current LTS release) as new "default" version in the Ports tree.

Is there a reason for not upgrading past version 3.6.4?

Technically there's no problem to update www/py-djangorestframework36 past version 3.6.4, but it would be IMHO a bit confusing to end up with a port name that refers to the 3.6.x branch but has a different port version.

I had already considered www/py-djangorestframework36 to be removed (see PR246082) because it's not compatible with Django 2.2+ and has no consumers at the moment.

On further progress I had the idea to "recycle" the www/py-djangorestframework36 port as www/seahub doesn't require a specific version of djangorestframework according to its requirements.txt and www/py-django-annotations already used www/py-djangorestframework36 in the past.

By the way, www/py-django-annotations will reach its expiration date on 25th May so www/seahub would be the only consumer of www/py-djangorestframework36 at the end.

I think I would rather stay on the newest supported version of djangorestframework that supports django 1.11, assuming there are no compatibility issues. (which I'm not currently aware of any)

This could be realized by removing www/py-django111 from RUN_DEPENDS in www/py-djangorestframework because the supported Django versions are given only as soft requirements via the Trove classifiers (e.g. Framework :: Django :: 2.2) in setup.py.

Django 1.11 was still set as a hard-requirement to primarily prevent issues like in rP457543 and to better distinguish between ports that work for a specific versions of Django until a long-term solution like D12592 lands into the Ports tree.

So if using www/py-djangorestframework36 is not an option for a transition period until www/seahub works with Django 2.2, the following two approaches would come to mind with option a) as preferred one:

Option a):

• Repo-copy www/py-djangorestframework in its current state (= version 3.9.4) to www/py-djangorestframework39
• Assign www/py-django-annotations and www/seahub to www/py-djangorestframework39
• Update www/py-djangorestframework to 3.11.0 and switch it to Django 2.2
• Once www/seahub works with Django 2.2, switch it back to www/py-djangorestframework and deprecate/expire www/py-djangorestframework39.

Opton b):

• Remove www/py-django111 from RUN_DEPENDS and update www/py-djangorestframework to 3.11.0

[ultima]

Thanks for your explanation for all this Kai. Everything is clear.

Option a):

Repo-copy www/py-djangorestframework in its current state (= version 3.9.4) to www/py-djangorestframework39
Assign www/py-django-annotations and www/seahub to www/py-djangorestframework39
Update www/py-djangorestframework to 3.11.0 and switch it to Django 2.2
Once www/seahub works with Django 2.2, switch it back to www/py-djangorestframework and deprecate/expire www/py-djangorestframework39.

I would prefer to go with option a with the exception of also upgrading the forked port to 3.11.0 (and of course the name to be appropriate to the version) with a different Django version as it still supports Django 1.11.

If Seahub is going to exclusively use the port, I can maintain that port if you would like and switch it back to the upstream port when Django has been upgraded in Seahub.

Django 1.11 was still set as a hard-requirement to primarily prevent issues like in rP457543 and to better distinguish between ports that work for a specific versions of Django until a long-term solution like D12592 lands into the Ports tree.

Yeah I think I would rather keep this approach until the Django USES has been introduced. Users should not have broken applications due to dependency problems like this. I know we all do our best and it is the nature of being on the latest though.

[kai]

• Repo-copy www/py-djangorestframework to www/py-djangorestframework311.

• Switch www/seahub to the repo-copied www/py-djangorestframework311.

• Omit changes for www/py-django-annotations because it's gone since rP536643.

[kai]

In D24850#549738, @ultima wrote:

Option a):

Repo-copy www/py-djangorestframework in its current state (= version 3.9.4) to www/py-djangorestframework39
Assign www/py-django-annotations and www/seahub to www/py-djangorestframework39
Update www/py-djangorestframework to 3.11.0 and switch it to Django 2.2
Once www/seahub works with Django 2.2, switch it back to www/py-djangorestframework and deprecate/expire www/py-djangorestframework39.

I would prefer to go with option a with the exception of also upgrading the forked port to 3.11.0 (and of course the name to be appropriate to the version) with a different Django version as it still supports Django 1.11.

If Seahub is going to exclusively use the port, I can maintain that port if you would like and switch it back to the upstream port when Django has been upgraded in Seahub.

Thank you for the info and pointers. I updated the review accordingly.

P.S.: I also opened an issue at upstream to give them a heads-up about the End-of-Life of Django 1.11. Maybe www/seahub can be switched in early Q3 to Django 2.2 then.

[ultima]

I completed my tests on seahub with the newer version of djangorestframework and everything came back green. Thanks for working on this.