Re: [Tools-arch] Recommendation 10: One-stop shop tool

[Martin Thomson <[e-mail]>]

On Fri, Apr 9, 2021, at 16:50, Jay Daley wrote:
> Imagine we were to give people everything they wanted:
> - ability to use XML or Markdown or ?? end to end
> - a single one-stop-shop tool and all the tools as separate command 
> line tools, as separate web interfaces, as separate plugins to their 
> favourite editor, as separate automatable services 
> - ability to integrate with GitHub, GitLab, Bitbucket, etc

My experience with these integrations is that they rot too fast to be useful long-term.  At various times in my career I have used numerous integrated chains, but they all ultimately break down pretty quickly.  For an enterprise, there is value in standardizing on a single integrated solution, but that requires deliberate, sustained effort.  With <40 developers at one shop, the Eclipse integration we had was a huge productivity boost.  But that was largely because the tool already provided such immense generic value for Java development that the incremental effort really paid off.

We have two countervailing forces at work here: 

1. The community that can't even decide what Markdown variant to use.  Most even seem to prefer XML.  I can't pretend to understand why.  They certainly can't be expected to agree on an editor.
2. The value an integrated tool might provide is at best minimal.  That is, the functions we might rely on are either generic to all text editors, or entirely bespoke (and therefore unlikely to be well-integrated).

So it's all about cost-benefit.  My sense is that integration work is unlikely to produce significant productivity gains.

I tend to think that the sorts of tool that Mark has produced here in https://pypi.org/project/sf-rfc-validate/ is exactly the sort of thing we need more of.  That is, something that takes a well-defined format and produces a succinct report.  Linting tools like that are an area we could improve (with yang validation being another example; idnits is almost a counter-example as it aims to be all-encompassing and integrated, to its own detriment).  Having more linters wouldn't be so bad.

Speaking of which, we need a way to filter documents for sourcecode; we shouldn't need to build that functionality multiple times.  There's a nice tool/library idea.

There are also other unexplored areas, if we want to speculate.  I've recently realized that a ctags-like tool might be worth building as well, which would lead to a lightweight, targeted integration for editors.