How do we organize the repo and packages?

[jia200x]

As promised, here I open the issue to organize the repository.

Some questions:

1. Do we adopt a polyrepo or monorepo approach?

As some members suggest (@sasalatart and me), a lot of companies are migrating to the monorepo
approach because it seems to be easier to maintain, but there are pros and cons of both cases.

2. Regardless of the poly-mono repo approach, how do we organize the current model, CLI and upcoming projects?

For instance, we have talked about a web backend and visualization frontend. IMO, we could adopt
the following encapsulation:

• One package for the model and CLI
  I would include the CLI here because in the future someone could simply type:

pip install open-sir
open-sir PARAMS > data.csv

Having the CLI in another package means the user would need to install an extra package.

• One package for the backend
  If the backend has its own repository, it can be used without the frontend (for instance, for fetching data from online dashboards).

• One package for the frontend
  The frontend can be packed as one package

• Tutorials and guides (including Jupyter)
  I would pack here the Jupyter notebook and all guides that could be pointed from the official documentation.

What do you guys think?

[felipehuerta17]

Hi @jia200x

I agree with the structure. Monorepo seems much more appropriate for us because:

Research computing software is frequently developed and maintained by a small team as it requires a lot of technical and domain specific knowledge. So in terms of scalability, there can be many collaborators but it will be very strange to have a lot of people developing lots of code.

I think we are working pretty well under implicit agile methods. Monorepo seems better for that too.

The Jupyter notebooks will very likely change with the back end, as well as it is easy to break the front end with some PR on the backend and it would be great to have all of this integrated within the tests.

The only exception that I would make for Monorepo is a separate repository for the Tutorials. But I would do this three months from now when the API is mature enough, as having a separate "teaching" repository with many Jupyter notebooks exploring interesting cases would be a great way to foster discovery.

[gwenzel]

Hey all,

I agree with monorepo. We are still a small and manageable team, so coordination should not (yet) be an issue. If the project scales quickly, we can always change later. Another big advantage I see with this approach is that keeping track of changes will be easier if each release covers the whole project.

[leandrolanzieri]

I agree with what it is being said: We are still on an early phase, we do not have yet scalability issues, and our APIs will very likely be changing a lot. This last point means that keeping all sub-projects in sync would be harder with the polyrepo approach. I like @felipehuerta17 's idea of a 'Tutorials' repo.

Regarding packages I think it's good for the user to get the models and CLI in one package, because it's easier to quickly try it out. The other packages that you propose make sense to me as well, but I would rather have the tutorials and guides on a repo rather than a package. 👍

[sasalatart]

I also prefer the monorepo approach for all reasons that you have said so far.

My only question with this discussion is about frontend vs backend package separation. I think @javalosp's input here will be very valuable as I believe he has been working more on that side. If the frontend is meant to be rendered directly by the backend because it is tightly coupled (which is not something bad in this case), then maybe we should just have a "web" package.

If frontend is easily separated from the backend (a React/Angular/Vue/etc app, or something by the lines), then we could have them as separate packages.

TBH I haven't yet seen the branch which has the current web progress.

[jia200x]

Ok, so there seems to be rough consensus on the following stuff:

• Go with monorepo
• Pack Model and CLI together
• Tutorials repo (not package)

For the frontend/backend part, we can leave it open until it's more clear how the web package would look like.

Does this seems reasonable to everyone? If so, we can already start packing the know components

[felipehuerta17]

@all-contributors please add @sasalatart for code, maintenance and data

[allcontributors]

@felipehuerta17

This project's configuration file has malformed JSON: .all-contributorsrc. Error:: Unexpected string in JSON at position 363

[felipehuerta17]

@all-contributors please add @sasalatart for code, maintenance and data

[allcontributors]

@felipehuerta17

I've put up a pull request to add @sasalatart! 🎉

[felipehuerta17]

@all-contributors please add @leandrolanzieri for code and maintenance

[allcontributors]

@felipehuerta17

I've put up a pull request to add @leandrolanzieri! 🎉

[felipehuerta17]

@all-contributors please add @gwenzel for ideas, userTesting and example

[allcontributors]

@felipehuerta17

I've put up a pull request to add @gwenzel! 🎉