[GeoNode-devel] Practices on maintaining a geonode project, PR: "Align to GeoNode master 4.2.0"
Giovanni Allegri
giovanni.allegri at geosolutionsgroup.com
Mon Aug 7 05:31:46 PDT 2023
Thanks for raising this point, and for sharing your solutions.
Keeping a project aligned to GeoNode (and the GeoNode-project itself) can
be really troublesome. We also don't have a one-fits-all solution.
The idea of the create_env.py command was to start creating a set of
utilities to help with the creation and the upgrade of downstream projects.
It was only the first step, and the PR from Alessio improves it.
The next step wanted to be a utility that could track changes and guide the
user in the procedure of updating an existing project, starting from the
.env file which is the principal target of most of the changes.
A very rough idea would be:
1. when a new project is created the commit for the geonode-project
template is written to the .env file by the create_env.py utility
2. the upgrade utility retrieves the commit
3. it compares the .env.sample commit with the target branch to which
you want to upgrade the project
4. it tries to extend the current .env file with any new env var, and
marks them with a specific comment (similar to the fuzzy translation
strings)
5. any var in the existing .env file that doesn't match the new
.env.sample will be marked with a specific comment
The same utility could generate the list of changed files between the
original commit and the target branch.
I'm aware that this doesn't solve all the issues, but it would help a lot.
What do you think?
Hey, I'm not saying that we will do it! :) That would be a nice feature,
but at the moment we don't have plans for it.
Giovanni
Il mar 1 ago 2023, 13:07 Florian Hoedt <florian.hoedt at thuenen.de> ha
scritto:
> Thank you two for the insights,
> I think we should take some time and funding to enable a better
> development experience. Other projects make it easier to add to the core.
> Most of the time those other projects are not as complex as GeoNode though.
> Maybe we as developer community could articulate and define the most urgent
> issues and we (Thünen-Institute) will try to get funding to smoothen the
> path?
>
> Yours,
> Florian
> --
> MSc Florian Hoedt
> Head Research Data Management | OpenData Representative
> Thünen Institute, Centre for Information Management
> Bundesallee 44
> 38116 Braunschweig
>
> Tel: +49 531 596-1428 | Mobile: +49 162 92 50 275
> Fax: +49 531 596-1499
> Mail: florian.hoedt at thuenen.de
> Web: www.thuenen.de
>
> The Johann Heinrich von Thünen Institute, Federal Research Institute for
> Rural Areas, Forestry and Fisheries – Thünen Institute in brief – consists
> of 15 specialized institutes with socioeconomic, ecological and
> technological expertise. The Thünen Institute conducts research and policy
> advice related to rural areas, agriculture, forests and fisheries.
>
> ------------------------------
> *Von: *"Toni Schönbuchner" <toni.schoenbuchner at csgis.de>
> *An: *"Henning Bredel" <h.bredel at 52north.org>
> *CC: *"geonode-devel" <geonode-devel at lists.osgeo.org>
> *Gesendet: *Dienstag, 1. August 2023 11:55:41
> *Betreff: *Re: [GeoNode-devel] Practices on maintaining a geonode
> project, PR: "Align to GeoNode master 4.2.0"
>
> H Henning,
>
>
> Interesting approach. It seems even the blog you mention agrees with you
> when saying "[...] so we had to help all developers apply the filter. That
> is one downside: it’s totally quiet, so failures aren’t readily surfaced."
> :-)
>
>
> Exactly. It somehow always felt wrong.
> Especially Devs not familiar with Geonode had a hard time understanding
> what
> is going on ;))
>
> However, I still assume changes in your working copy
>
>
> Correct, I also have to make some small tweaks in my working copy.
> But trying to keep them as simple as possible:
>
> - INSTALLED_APPS
>
>
> I did not touch settings.py except having the following in the end:
>
> # custom settings
> try:
> from .my_custom_settings import *
> except ImportError:
> pass
>
> Doing so I can extend and override what ever I need like INSTALLED_APPS,
> but keep the rest of settings untouched.
> Of course only things get into my_custom_settings that cannot be
> configured via .env anyways
>
>
> - docker/-compose files
>
>
> Similar as with settings I do override certain parts with a custom compose
> file
>
> docker-compose -f docker-compose.yml -f docker-compose-custom.yml up -d
>
>
> https://docs.docker.com/engine/reference/commandline/compose/#use--f-to-specify-the-name-and-path-of-one-or-more-compose-files
>
> Doing so docker-compose.yml can stay as
>
>
> or requirements.txt
>
>
> Good point! I’ve just changed it and left a comment before my changes.
> But I guess it should also work to mount your requirements into the
> container
> and override the start command a bit:
>
> entrypoint: ["/usr/src/geonode/entrypoint.sh", "bash", "-c", "pip install
> --no-cache-dir -r custom_requirements.txt && uwsgi --ini
> /usr/src/geonode/uwsgi.ini“]
>
> (Untested, and leaving a comment in requirements.txt might be cleaner in
> that case ;)
>
>
> These changes can be kept at a minimum and probably in a local branch, of
> course. Did you also try different approaches with regard to customizing
> geonode-mapstore-client, or do you prefer programming a completely
> different UI (probably this depends ;-))?
>
>
> To be honest, I have blocked adaptations for clients here as much as
> possible. Mainly because the reactive part of mapstore2 doesn't make it
> easy to develop (but that's due to my lack of knowledge).
> Also maintaining a fork is something I like to prevent.
>
> In some cases I have developed small custom viewers that only have geonode
> as a data provider.
> In one particular case, I decided to listen for WFS requests, process them
> as needed and create some DOM elements. This is of course a very messy
> solution as the virtual DOM should not be touched. But in this case it
> could be accepted and I avoided a custom build ;) To get the idea.
>
>
> // Catch WFS request
> var elements = [];
> (function() {
> var origOpen = XMLHttpRequest.prototype.open;
> XMLHttpRequest.prototype.open = function() {
> this.addEventListener('load', function() {
> if (this.responseText.includes(’something')){
> window.items = JSON.parse(this.responseText);
> do_something()
> }
>
> });
> origOpen.apply(this, arguments);
> };
> })();
>
>
> …
>
> // Create the button that opens the compare tool
> waitForElm("#drawer-menu-button").then((elm) => {
> console.log(„mapstore is ready“);
> // I guess there is a mapstore event we can listen on ...
> drawer = document.getElementById("mapstore-drawermenu");
> var i = document.createElement("i");
> i.classList.add("bi", "bi-arrow-left-right", "switch_icon");
>
> var _button = document.createElement("button");
> _button.setAttribute("id", "compare_button");
> _button.setAttribute("data-bs-toggle", "offcanvas");
> _button.setAttribute("data-bs-target", "#offcanvasRight");
> _button.setAttribute("aria-controls", "offcanvasRight");
>
> _button.appendChild(i);
> _button.classList.add(
> "square-button",
> "ms-drawer-menu-button",
> "btn",
> "btn-primary"
> );
> drawer.appendChild(_button);
> });
>
> and so on. Again this is of course a no no ;)
>
> Hope this helps,
>
> Cheers
>
> Toni
>
>
> _______________________________________________
> geonode-devel mailing list
> geonode-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geonode-devel
> _______________________________________________
> geonode-devel mailing list
> geonode-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geonode-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geonode-devel/attachments/20230807/5dee7e37/attachment.htm>
More information about the geonode-devel
mailing list