Bacon for everything - a roadmap

You want to use bacon on non rust projects? So do I.

Bacon watches sources, executes cargo tasks on changes (compile, lint, test, etc.), then, on end, analyzes the result, sorts it and displays it.

It's full of convenient features, like keeping the previous result available during computation of the next one, applying gitignore rules, sending problem locations to your IDE, paging and rewrapping on resize, switching task on key shortcuts.

And it turns out that other language ecosystems lack such tool.

For 5 years, the obvious opportunity wasn't discussed because we were few programmers using bacon, and I had no intention of doing anything else than rust anymore.

Then bacon started to be known, and I had a look back at some old non rust projects.

It's time to unleash bacon and I'll try here to define the plan.

Support launch without bacon.toml file

The bacon.toml file is useful to find the enclosing workspace, or the external source directories (eg on dependences given by a path).

But it should be possible to launch bacon when no such file exists.

That's the first step and what this Pull Request should make possible.

Progress:

• bacon 3.3+ supports being launched without Cargo.toml

New analyzers

An analyzer labels the lines that a tool ran by bacon returns on stdout and stderr, then builds a report with all the errors, warning, test failures.

The concept of selecting an analyzer for a bacon job appeared in bacon 3. Its first goal was to support nextest, which, while integrated in cargo, had a different output structure.

Here's bacon with eslint:

Here's the matching bacon.toml file:

default_job = "eslint-server"

[jobs.eslint-server]
command = ["npx", "eslint", "--color", "libs/*"]
need_stdout = true
analyzer = "eslint"
watch = ["libs"]

What would be needed now is developpers either asking for other analyzers or contributing some.

Progress:

• eslint analyzer included since bacon 3.3.0
• python_unittest analyzer included since bacon 3.3.0
• python_pytest analyzer included since bacon 3.4.0

Improve the analyzer framework

Writing an analyzer is still rough.

There's code duplication, non obvious things to do, and I expect some tools' outputs won't be as easy to analyze as the ones I added support for already.

The LineAnalysis struct and the LineType enum were designed for cargo outputs, they need to be modified. Most notable, a line should be able to have more faces, eg contain both the title of a test failure and the line and column in the file (but not the file path).

It looks also needed to allow the analyzer to produce the lines which are displayed before computation end, while it progress. This will allow for exemple bacon to be feed cargo JSON outputs, or similar streams.

And finally, as there are now several analyzer, any tedious job which is today done in the specific analyzer and which could be moved to the framework should be moved.

This effort runs in parallel with the addition of new analyzers as their implementation and the problems encountered help define the needs.

Progress:

• the new analyzer framework was included in bacon 3.4.0
• a cargo_json analyzer has been added in bacon 3.4.0 , able to work with the output of cargo check --message-format json-diagnostic-rendered-ansi. This analyzer illustrates the new abilities of the framework (especially having lines displayed during computation which aren't the exact output of the tool)

Introduce BURP

Rather than having bacon decypher the output of the program it calls, the symmetric approach would be to have the called program write an output that bacon can understand.

This implies a normalization. Let's call it BURP: Bacon Unified Report Protocol.

This protocol must describe how to have, in a STDOUT or STDERR stream, items which

• would have a kind among error, warning, test failure, test success, maybe other ones (benchs?),
• whould have a summary
• would have one or several locations (path to the file, line, column)
• could have a type
• could have some details in text (explanation, solution, etc.)
• could have its own STDOUT and STDERR (think tests)

The first draft of BURP would be "Do it as Cargo does, with the same ANSI escape sequences.".

Almost immediately would come the need to add some capabilities or alternate ways to produce the information. Hopefully it would still be a superset of what Cargo does.

If people serioulsy want to adapt some tools for bacon, or to write some adapters, we'll have to write a more detailed specification, of course.

BURP transformers

Waiting for all tools to be adapted won't be a reasonnable option.

A complementary approach is to write programs transforming the output streams of a command into a BURP compliant stream or pair of streams.

The good cases will be when we don't have to wait for the end of the command execution and we can keep items flowing as they're discovered by the tool. This probably won't always be possible.

Support transformers in Bacon

Good and reliable transformers for widely used tools should be directly integrated in bacon so that we can simply define jobs with a transformer=something parameter.

This of course implies that those transformers be written in Rust.

And it makes it obvious that a crate dedicated to producing BURP compliant lines will be useful. The good news is that it's trivial to write.

Configuration based generic BURP transformers

If we make BURP generic enough, there's a whole class of tools for which a transformer could be defined with simple pattern based line by line transformations.

So we could have a generic transformer defined simply with a configuration file.

If the approach reveals powerful and generic enough, this configuration could even be included in the bacon.toml file.

Job Sequences

The cargo world is quite exceptionnal in its simplicity. Most Rust projects are built with just a cargo build.

Extending to other ecosystems will increase the already identified need.

I'll be cautious here, I don't want bacon to become another Makefile like tool, as none of them can be general enough to support all needs. I'd rather encourage having the output of those tools being consumed by bacon.

But some minimal features appear necessary, at least chaining commands.

Analyze projects

To be fair, bacon does more for Rust than just understanding the output of the tools it calls: it also determine what directories to watch, even in complex workspace contextes.

It also knows how to deal with features, backtraces, etc.

At some point, specific behaviours will probably be needed for non-rust ecosystems too.

Be involved

Some work is necessary and this blog post isn't even a proper roadmap yet.

I'm working on this when I can but if I'm alone, a "bacon ecosystem" will be limited to what I need. At the very least I need people to tell what they'd need.

If you want to help bacon land on more languages and more tools, if you want to improve this roadmap or work on the implementation, please come to the chat.