I'm clearly missing your point here. The web UI is a thin flask app that talks to the CLI. The CLI must be built from the Subsurface source.
I fail to understand the value of having these extremely tightly couple components spread over two repos. Today the only purpose of the CLI is to be the API that the web UI talks to. And given that approximately seven people look at commits to the repo, I'm not sure where the problem is. Ironically it had been in the repo for two weeks and no one even noticed /D On January 27, 2026 7:33:02 PM PST, Michael Keller <[email protected]> wrote: >Hi Dirk. > >On Wed, Jan 28, 2026 at 11:32 AM Dirk Hohndel via subsurface ><[email protected]> wrote: >> >> No argument there. Writing tests for this is actually not all that hard, I >> think. > >I think one way to make testing in an end-to-end way really easy will >be to add a way for the CLI to be backed onto data in a local XML file >instead of a git repository. > >> > As for organisation, I am not sure if we'd want to move the flask app >> > and the web UI styling to a separate repository that consumes the >> > subsurface repository as a submodule or by checking it out, in a >> > similar way to how this is already done for our website in >> > https://github.com/subsurface/new-website/ (or maybe even combine the >> > two?). >> >> Anything that isn't in the main repo is far more likely to go stale and >> bitrot. > >In terms of preventing bitrot, or rather catching it before it takes >hold, just having the flask app and website design in the same >repository isn't going to give us much - we'd also have to set up a >CICD task that builds and spins up a full website plus backend, and >then runs UI tests against it. >I think a better approach to prevent this will be to agree and >document a stable and well formed API for the CLI, and then use tests >on both sides to ensure the implementation stays true to the API >definition. > >> Also, please note that the webUI has nothing to do with the website, it would >> be the completely wrong place for it. The website is NOT hosted on the cloud >> servers - these are completely different properties and I really don't want >> to >> mix them. Life is hard enough as it is. > >Ok, so I'd go for a separate repository from the website then. >On the flip side, the group of people willing and able to help with >the website is probably the same as the one willing and able to help >with the web UI - and likely not completely identical with the group >willing and able to help with the application and CLI. Hence >separating this out will avoid cross spamming contributors with >'noise' from change in areas that they don't want to hear about. > > >On Wed, Jan 28, 2026 at 9:55 AM Dirk Hohndel via subsurface ><[email protected]> wrote: >> >> The latest version is on GitHub and on https://staging.subsurface-divelog.org >> This includes a dive profile on the dive details page. > >Nice, good going! > >For the profile: >- it seems to be a bit useless to show 'Subsurface GF' up top if we >don't show it - what we show is the dive computer reported GF. And if >we want to show the calculated gradient factor we should really make >it adjustable, as showing the deco obligation for an arbitrary >gradient factor does not add much value; >- not sure if we want to show '(#x of y)' if there is more than one >dive computer if the dive has multiple profiles if we aren't adding a >way for the user to switch between the profiles? >- there is a preference 'Show dive computer calculated ceiling in red' >- applying this for the profile would probably improve the look of the >profile; >- can we please make it possible for the user to choose which unit >system they want their dive profiles to be displayed in? > >On Wed, Jan 28, 2026 at 1:08 PM Dirk Hohndel via subsurface ><[email protected]> wrote: >> >> So you could do things like plan a dive, then have everyone on the team >> review >> it and be able to tweak it, without everyone needing to manually enter the >> same >> data into their own devices or to crowd around a single device looking over >> someone's shoulder. > >I'd guess that before we get to this point we'd probably want to add >support for displaying the extra information needed for technical >dives, like dive mode or actually used gases - I can't see multiple >users poring over the plan for a recreational dive. 😛 > >Ngā mihi > Michael Keller
_______________________________________________ subsurface mailing list -- [email protected] To unsubscribe send an email to [email protected]
