When installing net-mgmt/netbox and www/py-graphite-web on the very same host instance, a conflict between both occurs: www/py-graphite-web requires www/py-django22 and net-mgmt/netbox requires www/py-django32 Both django-ports are exclusive.
We might see if www/py-graphite-web can update its dependency to py-django32. Maintainer notified via bugzilla.
Switching www/py-graphite-web to Django 3.2, once upstream supports it, would indeed fix the reported issue. But the problem will come back with NetBox 3.2, which will be released in April, and requires then Django 4.0 to run. It's a known issue with Django as one version cannot co-exist with other versions of Django. Some effort was made some time ago to simplify the use of different Django versions, see review D12592. But it still requires some work to get it into the Ports tree. A workaround to cope with the different Django versions would be to use isolated instances via jails. Regarding www/py-graphite-web and Django 3.2: The current release (= 1.1.8) doesn't support Django 3.x (see issue #2703) and there's a new release planned (see issue #2732). However, it's currently not possible to say whether the new release will also support Django 3.x. I also connect this bug with bug #261313 because it's related to the switchover from Django 2.2 (= EoL in April 2022) to Django 3.2 (= next LTS release).
It(www/py-graphite-web) cannot be done ATM; as mentioned there is currently no exact date of releases when django32 would be supported. What I can do is mark it DEPRECATED along with the django22 EXPIRATION_DATE for the time being. Keep this opened till the last moment to see if there is any progress for django32 support. I am not at all interested to keep ports/software in the tree which cannot keep the momentum on their DEPS. We are not like other Linux distros where we are getting paid to maintain legacies for years after year.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=94d5b74e39987d04e0af6e2ce4bbb4c27d1e4d07 commit 94d5b74e39987d04e0af6e2ce4bbb4c27d1e4d07 Author: Kai Knoblich <kai@FreeBSD.org> AuthorDate: 2022-04-14 16:24:00 +0000 Commit: Kai Knoblich <kai@FreeBSD.org> CommitDate: 2022-04-14 16:27:54 +0000 www/py-graphite-web: Deprecate and set to expire * The current version of py-graphite doesn't support Django 3.2, which is the next LTS (= long-term support) release since Django 2.2 reached its End-of-Life on April 11th [1]. There may be a new release with support for newer versions of Django in the course of 2022Q2 to undeprecate the port. PR: 261086, 261313 [1] Approved by: bofh (maintainer, via D34859) www/py-graphite-web/Makefile | 3 +++ 1 file changed, 3 insertions(+)
Just a short overview of the actual situation: - www/py-graphite-web is not present in the Ports and there's no new release that has Django 3.2 support at the moment. - net-mgmt/netbox requires Django 4.0 and uses its own set of Django 4.0 ports. Technically the issue is "resolved" at the moment but as I already outlined in comment #2 the problem with the conflicting Django packages will come back if, e.g. www/py-graphite-web gets Django 3.2 support and comes back to the Ports tree.
(In reply to Kai Knoblich from comment #5) Just to keep a note on this for my purpose as I will need to bring back py-graphite-web. Are you implying that if someone needs to have py-graphite-web and netbox in the same host that will be the problem of two different conflicting Django installation?
(In reply to Muhammad Moinur Rahman from comment #6) Yes, because each Django version has the same namespace (= "django"). So only one version of Django can be present for a specific Python version. It can be reproduced via installing "py39-django32" first and then "py39-django40". Thus I only can think of following workarounds at the moment: - Make use of jails. - Use different Python versions, e.g. py38 for www/py-graphite and py39 for net-mgmt/netbox. In that case, both www/py-django32 and www/py-django40 still need "USE_PYTHON=concurrent" to make it possible. - Someone(tm), who has much time/brainpower and can craft a useful "USE_PYTHON=django" or "USES=django", e.g. give review D12592 a major overhaul and shepherd it into the Ports tree. - Use a Python virtualenv.