Bug 227149

Summary: Use the www/py-django meta port instead of the www/py-django18 port to move to Django 1.11
Product: Ports & Packages Reporter: Kai Knoblich <kai>
Component: Individual Port(s)Assignee: freebsd-python (Nobody) <python>
Status: Open ---    
Severity: Affects Some People CC: matthew, miwi
Priority: --- Keywords: patch
Version: LatestFlags: bugzilla: maintainer-feedback? (python)
kai: maintainer-feedback+
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227032
Description Flags
Proposed patch
Testcase with django variable in USE_PYTHON
django-testcase-v2.patch none

Description Kai Knoblich freebsd_committer 2018-04-01 00:19:57 UTC
Created attachment 192021 [details]
Proposed patch


this time its a rather large patch that affect all ports that are still tied to www/py-django18 . The patch unties those ports from www/py-django18 and reassigns them instead to the Django meta port www/py-django which uses as default version Django 1.11.

Django v1.11 is the new preferred LTS version and the last one that supports Python 2.7.

The patch is also meant as preparation to update www/py-djangorestframework to the latest version, 3.7.7, which has dropped the support for Django 1.8 since version 3.7.x .

Following ports were excluded from the patch:

- www/py-django-mezzanine (officially supported Django versions 1.8 - 1.10)
- www/py-django-contrib-comments (py-django-mezzanine depends on it)

Ports, that seem to deprecated (dead homepage, stale projects or officially deprecated) and have no dependent ports upon:

- www/feedjack
- www/py-django-configurations
- www/py-django-dpaste
- www/py-django-dojango
- www/py-django-evolution
- www/py-django-keyedcache
- www/py-django-livesettings
- www/py-django-paging
- www/py-django-profiles
- www/py-django-signals-ahoy
- www/py-django-social-auth
- www/py-django-subdomains
- www/py-django-sudo
- www/py-django-templatetag-sugar
- www/py-django-threaded-multihost
- www/py-djangotoolbox

- poudriere (11.1-RELEASE amd64 + i386) -> OK

Comment 1 Antoine Brodin freebsd_committer 2018-04-01 05:57:56 UTC
In my opinion the metaport is not the right solution.
Flavors should be used instead.
Comment 2 Kai Knoblich freebsd_committer 2018-04-01 07:35:36 UTC
(In reply to Antoine Brodin from comment #1)

Hello Antoine,

thank you for your input. Would this be a better solution if I replace those lines from

> RUN_DEPENDS=  ${PYTHON_PKGNAMEPREFIX}django>0:www/py-django@${FLAVOR}


> RUN_DEPENDS=  ${PYTHON_PKGNAMEPREFIX}django111>0:www/py-django111${FLAVOR}


I would exclude the deprecated ports from this and leave the RUN_DEPENDS at their current value as given in the ports tree. Then it would be easier to drop those ports in near future.

What do you think?
Comment 3 Antoine Brodin freebsd_committer 2018-04-01 08:34:10 UTC
I think the right solution would be to have something like:

USE_PYTHON= django
USE_PYTHON= django:1.8

and it would automatically create flavors depending on allowed versions of python and allowed versions of django

For instance

USES= python
USE_PYTHON= django

would give:


USES= python:2.7
USE_PYTHON= django:1.8

would give:

Comment 4 Antoine Brodin freebsd_committer 2018-04-01 08:36:16 UTC
See also https://reviews.freebsd.org/D12592 for an attempt to do it
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2018-04-01 09:10:13 UTC
-1 on this too. It feels odd switching to less explicit django version for each ports dependency, via a meta port who's versions will change over time. This is especially the case given some complex interdependent version dependencies for many django ports (and future ones), particularly over time as version compatibility changes.

Essentially, only a single installed version of django can be supported at any one time in a single python version system site-packages location, the proper solution to which is DEFAULT_VERSIONS support (See: bug 222724's review, leaving aside implementation specifics/design choices).

That said, if the metaport ONLY implemented (and depended on) the users selected (or the default) DEFAULT_VERSION of django, that might be nice, if its possible.
Comment 6 Kai Knoblich freebsd_committer 2018-04-01 10:43:08 UTC
Thank you for the references to the review and PRs. If I understand this right by the given facts/suggestions then the desired approach would be like:

- create a new variable, e.g. DJANGO_DEFAULT in bsd.default-versions.mk 
- create a new variable, e.g. django:X.XX[+] for USE_PYTHON in Uses/python.mk

For the next examples I'll refer to following django ports:

- www/py-django-filer (depends also on graphics/py-django-easy-thumbnails
- graphics/py-django-easy-thumbnails

Let's assume that the new variables above mentioned are implemented into the ports framework, then the sections for RUN_DEPENDS and USE_PYTHON should be changed to:

For www/py-django-filer:

> RUN_DEPENDS=  ${PYTHON_PKGNAMEPREFIX}django-easy-thumbnails>=0:graphics/py-django-easy-thumbnails@${FLAVOR} \
>              ${PYTHON_PKGNAMEPREFIX}pillow>=0:graphics/py-pillow@${FLAVOR}
> USE_PYTHON=     autoplist distutils django

For graphics/py-django-easy-thumbnails (the RUN_DEPENDS can be removed):

> USE_PYTHON=     distutils autoplist django

A bulk run for both py27 and py36 flavors with a Django default version of 1.11 will produce following Django v1.11 packages:

- py27-django-filer
- py27-django-easy-thumbnails
- py36-django-filer
- py36-django-easy-thumbnails

If I understood the extent to that point correctly, then the following example should fail with DJANGO_VERSION set to 1.11 (as intended):

For port graphics/py-django-easy-thumbnails change USE_PYTHON to:

> USE_PYTHON=     distutils autoplist django1.8

This should produce a build error for both py27 and py36 flavors if I'm correct?

To resolve that issue, one can change USE_PYTHON to:

> USE_PYTHON=     distutils autoplist django1.8+

Then the build of both Python flavors should work again.

Comment 7 Matthew Seaman freebsd_committer 2018-04-02 17:44:39 UTC
(In reply to Antoine Brodin from comment #4)

Yes, I think your suggestion of handling django flavouring within Uses/python.mk is the best way forwards here.  Unfortunately I don't have any spare time to look into that right now.  

There is an architectural problem with flavours to do with handling ports where more than one type of flavouring applies, but that's a whole lot more work to handle.
Comment 8 Kai Knoblich freebsd_committer 2018-04-02 19:52:49 UTC
Created attachment 192117 [details]
Testcase with django variable in USE_PYTHON

Hello everyone,

thanks for all your input. Attached is another patch which implements Antoine's and Kubilay's suggestions.

A short overview about what the patch does:
- create a new variable DJANGO_DEFAULT in Mk/bsd.default-versions.mk
- add support for django for USE_PYTHON in Mk/Uses/python.mk
- all ports, that depend on Django (except the meta port), are patched (deprecated ports have the value django:1.8 otherwise django is set either to django:1.8+ or django:1.11+

This patch still lacks support for specific naming for django packages.

The expected behavior for packages, that don't match the specific Django version, should be ignored. The patch needs of course thorough testing.

Please consider this patch as a testcase and possible suggestion to develop the idea further with it. It's not the definitive solution - for that the patch is too far away to be perfect.
Comment 9 commit-hook freebsd_committer 2018-08-19 13:55:54 UTC
A commit references this bug:

Author: rene
Date: Sun Aug 19 13:55:44 UTC 2018
New revision: 477575
URL: https://svnweb.freebsd.org/changeset/ports/477575

  www/py-django: remove support for end-of-life Django 1.8

  PR:		227149 (related to)
  Submitted by:	Kai <freebsd_ports@k-worx.org>

Comment 10 Kai Knoblich freebsd_committer 2018-08-28 23:19:57 UTC
Created attachment 196657 [details]

Now that Django 1.8 has been removed from the ports tree (thanks to all who have been involved in this) here's is an rebased and updated patch against @r478329 .

- introduces "django" keyword for USE_PYTHON
- valid arguments are <version>, build, run, test
- <version> can be 1.11+, 1.11-2.0, -2.0 or kept blank to use the default Django version
- if the Django version given by the user/ports framework doesn't match the Django version(s) in a port's Makefile the port will be ignored.

- Tested on 11.2-RELEASE with Django 1.11, 2.0 and 2.1 as default versions

If this approach makes sense I would open a review for it in phabricator. In that case please let me know who I should add as reviewers.