Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Split reference site generation code from SSOT #227

Open
andylolz opened this issue Nov 18, 2018 · 7 comments
Open

Suggestion: Split reference site generation code from SSOT #227

andylolz opened this issue Nov 18, 2018 · 7 comments
Assignees

Comments

@andylolz
Copy link
Contributor

andylolz commented Nov 18, 2018

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.

@samuele-mattiuzzo
Copy link
Contributor

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

@andylolz
Copy link
Contributor Author

andylolz commented Nov 19, 2018

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.

@andylolz
Copy link
Contributor Author

andylolz commented Nov 19, 2018

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 :)

@samuele-mattiuzzo
Copy link
Contributor

samuele-mattiuzzo commented Nov 20, 2018

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 SSOT component's scripts from the actual components files
  • decouple the SSOT main scripts as well (maybe?)
  • use the sitegen repo 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!

@andylolz
Copy link
Contributor Author

Aha! I see what you mean now. Yes, sounds good!

@samuele-mattiuzzo samuele-mattiuzzo self-assigned this Nov 27, 2018
@samuele-mattiuzzo samuele-mattiuzzo added this to Backlog in SSOT Decoupling Mar 1, 2019
@andylolz
Copy link
Contributor Author

andylolz commented Apr 29, 2019

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.

@samuele-mattiuzzo
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
SSOT Decoupling
In progress
Development

No branches or pull requests

2 participants