Created attachment 192021 [details] Proposed patch Hello, 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 QA: ~~~ - poudriere (11.1-RELEASE amd64 + i386) -> OK -- Cheers Kai
In my opinion the metaport is not the right solution. Flavors should be used instead.
(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} to > RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}django111>0:www/py-django111${FLAVOR} instead? 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? -- Cheers Kai
I think the right solution would be to have something like: USE_PYTHON= django or 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: py27-django18-foo py27-django111-foo py36-django18-foo py36-django111-foo py36-django20-foo USES= python:2.7 USE_PYTHON= django:1.8 would give: py27-django18-foo
See also https://reviews.freebsd.org/D12592 for an attempt to do it
-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.
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. -- Cheers Kai
(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.
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. -- Cheers Kai
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 Log: www/py-django: remove support for end-of-life Django 1.8 PR: 227149 (related to) Submitted by: Kai <freebsd_ports@k-worx.org> Changes: head/www/py-django/Makefile
Created attachment 196657 [details] django-testcase-v2.patch 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 . Summary: - 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. QA: ~~~ - 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.
(In reply to Kai Knoblich from comment #10) (Bugmeister note: it seems this work has not yet been committed as of 20240207.)