update requeriments to django 4.2

[cesarbenjamindotnet]

Overview

i'm playing with geonode since prelerease 4.0, i notice that it requires django 3.2 which is a bit old, i was waiting for 4.1 release with the hope of updates about this, but still uses django 3.2, i'm trying to discover what is the reason for that, at first not seems a logical choice. But now i'm trying to install from scratch reviewing each package in requerimets.txt looking for update most of them with recent versions, most of cases seems work well and don't cause imcompatibily among packages... until i reach dynamic-rest, which is highly used for rest serializers and so on, so, i went to the lib repo and it seems a bit abandoned, so i now understand why exists this linkage to django 3.2 as maximum version supported.

So, i'm working in update dynamic-rest from my own way for now, i will made a pull request, but i'm not sure if it can be approved, but what about of using a customized dynamic-rest repo?

this is the alt repo compatible with django 4.2 and drf 3.14

it's possible that breaking things appears, so, i'm working in this a lot because i have the need to update to django 4.2 for use with Wagtail 5.2 because a specific need for a local goverment where i'm working on, so is a real project need.

Proposed By

César Benjamín

Assigned to Release

This proposal is for GeoNode <4.1.x>.

State

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

Motivation

i guees software keeps fresh and updated, keep outdated becasue an outdated dependency lib is a bad mark for the product.

Proposal

change dependencies in requeriments.txt for django djangorestframework and dynamic-rest, respectively to:

django==4.2.7
djangorestframework==3.14.0
-e git+https://github.com/cesar-benjamin/[email protected]#egg=drf-dynamic-rest

Backwards Compatibility

Not sure

Future evolution

maybe i'll involve in dynamic-rest updates or can colaborate in an official geonode-dynamic-rest fork

Feedback

Voting

Project Steering Committee:

• Alessio Fabiani:
• Francesco Bartoli:
• Giovanni Allegri:
• Simone Dalmasso:
• Toni Schoenbuchner:
• Florian Hoedt:

Links

[mattiagiupponi]

hi @cesar-benjamin i'll take a look and i'll investigate the possibility to upgrade geonode to django 4.2.x (it will be the next LTS version)

So, i'm working in update dynamic-rest from my own way for now, i will made a pull request, but i'm not sure if it can be approved, but what about of using a customized dynamic-rest repo?

In case this will be needed (custom repo) we will fork the project in the official geonode and we will use that

[cesarbenjamindotnet]

Thanks for the answer, i'm interested in collaborate for this upgrade, actually i have work done, i completely upgrade all dependencies for run completely with fresh versions, is a nightmare btw because there is a lot of old fashioned breaking code, like ugettext in many (it seems) abandoned libraries. i have a fork for each with the fixes needed to work well with django 4.2.7, yo can see a for-development-purposed instance running at http://35.202.175.91 and you can see all the upgraden libs at my repos at https://github.com/cesar-benjamin?tab=repositories. my instance some times can be sleep because is a GCP Spot instance, which can be stopped some times, and if i'm not using it i can't know that if the vm is working or not, but mainly i'm using it, because is my sandbox for upgrade to django 4.2.x because i need it for integrate a few things that need django 4.2.

upgrade to django 4.2 is a very very very hard work because the dependence tree nightmare and the compatibility of all that. But is ready done for me.

only remains a thing that don't work well about keywords which use select2 and is not working well but i'm still working on it.

the branch i'm working with are 4.1.x at projects geonode and geonode-project, my custom changes don't work on master

[cesarbenjamindotnet]

You can see it running here: http://35.202.175.91

[giohappy]

@cesar-benjamin it would be great if you could send PRs for each repo that need fixes. We can create dedicated branches for them

[mattiagiupponi]

upgrade to django 4.2 is a very very very hard work because the dependence tree nightmare and the compatibility of all that. But is ready done for me.

I see, i tried on my local instance too and there are some changes to perform. I check you repo, but i guess removing the fixed version for each library could create other issues since it might need work on the geonode side. I would try to upgrade ONLY what is needed to switch to django 4.2 as first step

only remains a thing that don't work well about keywords which use select2 and is not working well but i'm still working on it.

This could be raised by my previous message

the branch i'm working with are 4.1.x at projects geonode and geonode-project, my custom changes don't work on master

ok AFAIR, the django upgrade would be introduced after the release of geonode 4.2.0, so i guess is better to do this work from the master branch

@cesar-benjamin it would be great if you could send PRs for each repo that need fixes. We can create dedicated branches for them

This is really helpful, so i can review it and help you with the upgrade procedure

[mattiagiupponi]

Closed in favor of #11821

[cesarbenjamindotnet]

@cesar-benjamin it would be great if you could send PRs for each repo that need fixes. We can create dedicated branches for them

Thanks, i will, sorry for the delay, i'm ooo, afk, and so on, the next week i'll return to my activities/home/computer, etc, so, i have to move a bit of stuff to move my changes to master branch and make a PR, because is not only a thing about of dependencies, in my repo in the branch 4.1.x all that things has been fixed, i'll decide to make this on 4.1.x because is a released branch, btw, while i was moving stuff i found some orphan stuff and many things that i guess need attention too.

at the other hand i'm working on a particular-case vuejs client because the actual mapstore client have a mix of things that together dont work well, i mean, why if is using react, keep using django template systems? i can't understand the logic behind this decision but i think that or it uses django templates or it uses a pure js client, not mixed. Sorry, i know this is another topic but i guess must be improved ASAP too