Merge `app` and `full-app` about app HOT 9 CLOSED

This is at its best, a step back to tgve/eAtlas/master branch.

from app.

@layik The only problem I'm aware of that tgve/eAtlas/master had was that it had >200 unpublished commits. (Otherwise I'm unsure what you're referring to.)

One way to focus on whether this makes sense would be to ask ourselves: what would go wrong if we were to merge app and full-app? (Maybe there's something I haven't thought of.)

from app.

@layik What you seem to be after might conceivably be addressed by submodules. But even that seems more complicated than what we actually need!

from app.

I am not saying they cannot merge, and no my issue was not > 200 unpublished commits, a branch is published commits for me. The issue was a single repo and relying on branches was not a good case for "modularity". There was also an element of "user" vs "org" space on GH.

A future full-app is what showcases like saferactive and geopspenser need and not a client app. Now, back to whether we should merge them, I find it a step back to doing too many different things in the same repo and that could lead to > 10 commit branches.

from app.

I like to keep tgve/app for its main purpose, a template to publish data using tgvejs on github pages. In fact, in saferactive project, we find both use cases:

1. https://github.com/saferactive/tgve and
2. https://github.com/saferactive/saferactive-eatlas

from app.

Can I be clear @rolyp and team, I am concerned more about keeping app "clean" right now.

from app.

Ok, thanks for clarifying what you meant about master. Also I agree we should support the “hosting instance” idea as a primary use case for app. What we need to be careful of is duplication (copy and paste) for the sake of supporting different scenarios, as we had with e.g. master and npm.

A copy of a repo is really just copy-and-paste by another route, and it’s certainly confusing to have two repos that differ only by the inclusion of some small files. On the other hand, supporting multiple scenarios (e.g. Python development, Docker development, and plain old hosting) in a single repo is harmless, and standard practice.

from app.

@layik Relatedly, we should probably ask ourselves: what actually depends on the existence of the following files:

• nodejs/server.js
• R/plumber.R
• run.R
• Dockerfile
• tgve.py and tgve-cors.py

given that if we deleted them, the build/deploy workflow for full-app would still succeed. It would be good to get clear onwhat these files are actually for and how to verify that they do something sensible.

from app.

@layik wrote on Slack:

Right, should we define what app does before we agree on the merger?
So far it (app) does:
A1. template to publish data using tgve on GH pages
A2. used as remote instance
A3. used as build workflow of tgver.
A4. as the only showcase for docs in tgvejs
A5. as the workflow for developing tgvejs
A6. not sure if there is more?

What we are trying to add to it:
B1. notebook documentation?
B2. full stack template to publish data on own server
B3. anything else?

B1 goes nicely with A1 & A2, if I ever want to use a notebook with TGVE (which seems likely). So that dispenses with B1. Let's assume B3 is "no", leaving us with B2.

If B2 is a scenario we wish to support (via both R and Python), then I suggest the following:

1. treat them as use cases of app (since it's fine and indeed common for a single app or component to have multiple usage modes)
2. implement two bits of CI, one for R and one for Python, which validate these use cases
   Then a user of the app is free to use it "as is" or to adapt the CI for R/Python to host their own data (if I'm understanding what you mean by "full stack" correctly).

from app.