Suggestion: Split reference site generation code from SSOT
andylolz opened this issue · 7 comments
Various tickets against this repo really relate to reference site generation. Also, reference site generation should be independent of IATI version. So I suggest splitting out reference site generation code out from the rest of the SSOT.
I made a start at this work a while ago:
https://github.com/andylolz/iati-sitegen
…but then stopped when it wasn’t apparent whether this would ever be used.
I emailed @bill-anderson / @PetyaKangalova / @amy-silcock about this back in May, and mentioned it in #164 (comment) too. Flagging again because it was mentioned at TAG that the SSOT will be a priority. I really think this could be a useful step.
Hi Andy, I do totally agree with you on this, and I have been thinking about how to split the two main parts.
I'm evaluating how to move away from Sphinx alltogether as well, as as we both know, it is very limited. It's going to be my main focus for this week, so expect more chats and updates (hopefully) on this :)
What I want to avoid tho is to add more repos that split building logic out (a la deployments, for instance) and instead keep it all collated in a single place, just modernize it all a bit
What I want to avoid tho is to add more repos that split building logic out (a la deployments, for instance) and instead keep it all collated in a single place
Hmm I don’t think I explained very well above. It’s clearer in the email, which I can forward.
So for instance, the fix for #228 would currently have to be done 5 times (once for each branch). If build code were instead decoupled from the SSOT, this wouldn’t be necessary.
Also, others might be interested in pulling the SSOT into their projects, but they’re probably not interested in pulling in the code to build their own copy of the reference site. It seems weird that these build scripts are part of this repo.
In fact, w.r.t. #228, @hayfield even points out:
Helpfully, the template is different at different integers [/s].
This is only an issue because the build script and templating live in the SSOT repo, and have become out of sync between branches. Decoupling would prevent that.
just modernize it all a bit
+1 to modernising, but I think monolithic -> microservices counts as modernising :)
Ah now I understand, I think we're both saying/thinking the same thing here.
Looked at your sitegen repo, let me try to figure out the reasoning behind it:
- decouple each
SSOTcomponent's scripts from the actual components files - decouple the
SSOTmain scripts as well (maybe?) - use the
sitegenrepo to loop through each component's scripts and generate everything
I possibly described it too simplistic, but that is the approach I wanted to take, except for a minor difference: I wanted to convert the current SSOT repo into a generating-only repo (bringing in each component's scripts) which just pulls the correct version of the Standard it's trying to build (either via a list of params or by default, all of them). I think it would end up being exactly the same as your repository though, just with a different approach (yours takes existing files into a new repo, mine removes stuff from the current SSOT repo).
FYI, I'm feverish, so I might also be blabbering too much. I think the approach is good and yup, definitely up for a collab on this!
Aha! I see what you mean now. Yes, sounds good!
Bumping this ticket again, because I notice this repo being referred to as the "SSOT reference site".
This repo hosts the single source of truth, as described here. It’s true that it does also include code that generates the reference site, but that’s not what the repo is principally for. Perhaps confusion could be avoided by splitting the reference site generation code out from this repo, as this ticket suggests.
Don't know if you have seen it, but https://github.com/IATI/IATI-Standard-SSOT/projects/1 is now collating all my previous work to decouple SSOT from the generation of the reference site.
It's just been parked due to re-shuffling of the dev plans and priorities to give more space to tools and upgrades that need a bit more attention from us.