On 2026-01-29 11:34, Michael Keller via subsurface wrote:
On Wed, Jan 28, 2026 at 5:25 PM Dirk Hohndel via subsurface
Today the only purpose of the CLI is to be the API that the web UI
talks to.
I am not sure this is the way I would like to look at it - I think the
CLI should be able to stand on its own, and supply data in a way that
can be used for other use cases than just the web UI - if this isn't
the case then I think we are giving up on an opportunity for others to
come up with ways to use it.
I'd read that as *today* the web UI is the only extant (and currently
planned) user, not that it should not become a stable interface that
other later tools, if someone has the itch to write them, could use?
It may even make sense to include other future users in the main repo
too if they are in the character of something that we as a group would
want to support and maintain in close association for the purpose of
test coverage and official releases. Especially if they have no other
re-use value outside of it and aren't a one-of-many choice users could
reasonably make.
Personally, I've never been much of a fan of git submodules, they mostly
just complicate maintaining something that should either be a proper
part of the repo, or a properly external dependency maintained outside
of it. (and I was a very early and passionate adopter of git, moving
nearly everything directly to it from CVS shortly after first contact,
and after hating anyone who had moved anything I needed to use to SVN,
or who had bet their business workflow on perverse).
If we aren't talking about making the mobile UI a separate project
(and I really hope nobody latches onto that to say *Yeah We Should!!* :)
it seems reasonable that a 'first class' web UI should be a similar
part of it to me.
Thankfully I implemented this so that you can create a simple git repo
to test against, you don't need the backend service. So there's no
upside
to adding XML support to this.
Thinking of test automation, having to create a git repository, and
then load data into it in some way, before being able to use the CLI
to verify that the test data results in expected test outputs is still
a reasonable amount of overhead, and brittleness from the loading.
If we can point the CLI at an XML file, it will become trivial to
repurpose some of the existing test data to verify that it is
converted into JSON in the expected way.
Can't we just point it at a pre-existing git repo in the same way?
That was how I read that plan, not as something we would always
(re)create on the fly from other static data.
And if we point it at a pre-existing specific tree-ish in that test
repo, we can have multiple and/or evolving over time sets of data
for testing with?
Ron
_______________________________________________
subsurface mailing list -- [email protected]
To unsubscribe send an email to [email protected]
