Expose tailspin as a crate / library

[bensadeh]

Expose the highlighting functionality of tailspin as a crate / library to enable easier integration with other Rust programs.

See for example:
#116 and zifeo/whiz#117

[georgalis]

Perhaps my question will help identify requirements and api for a tailspin library. Since tailspin is normally used as a shell program, with options, stdin/stdout, and file configuration largely according to local, interactive cli needs; how would tailspin be used as library, or what context and benefit would a library serve over manual binary execution, or basic scripted automation? Eg, if you are developing a log monitoring application and want to integrate the library, how would the library use make local implementation easier for arbitrary other sites? How would a library be worth the effort?

AI generated clarification:

Tailspin is typically used as a shell program with command line options, standard input/output streams, and configuration via files to support interactive use cases. What value would a tailspin library provide over just executing the tailspin binary manually or via scripts?

• Potential benefits of a library could include:
  • More flexibility - the library API could expose internals/capabilities not available via the CLI
  • Performance - avoiding overhead of spawning processes, could be optimized better
• The library would need to design appropriate requirements around:
  • API functionality exposed
  • Handling of configuration/options
  • Cross-platform support
  • Build/link dependencies
  • Threading models
  • Performance considerations
  • Documentation and examples

[joshka]

I'd definitely like to see this happen. Taking a read through the source, I can see why it's not a trivial task to do like the linked PR. The CLI-ness seems to invade quite a few of the types and methods. To name a few:

• themes are loaded from a config file (methods rely on filesystem / xdg etc.)
• config is based on cli parameters, and deals in terms of Stdout, StdIn, files, etc.
• highlighters take cli parameters and theme

I think what might work for this is to make a tailspin-core cargo project and convert this repo into a workspace. Gradually move each module / type over to the lib crate while separating out the cli and filesystem specific parts. Use the https://crates.io/crates/stability crate to mark anything that doesn't quite feel right yet, and to make it easy for consuming code to be aware of not relying on unstable abstractions.