Separate lib and bin dependencies

[wgreenberg]

Describe the feature you'd like
Separate dependencies of trippy's public library components and it's CLI binary tool. This way, when trying to use trippy within another rust project, I can cargo add trippy without its version of clap (or any of the other TUI/CLI related dependencies) clashing with my own.

Describe alternatives you've considered
I'm not sure there is an alternative, besides me not using trippy as a library.

Additional context
I'm trying to use trippy's tracer within another rust project.

[fujiapple852]

Hi there @wgreenberg and thank you for raising this topic.

I previously attempted to split the library and bin out as you describe (see #640) but eventually abandoned the PR as it became very out of date.

I’m still undecided on whether this separation makes sense for Trippy, which will mostly be used as a stand-alone tool rather than a library, but I’m open to being persuaded.

what is your use case for using Trippy as a library?

[wgreenberg]

@fujiapple852 I'm working on software that detects machine-in-the-middle attacks via timing analysis (https://arxiv.org/abs/2308.09213) written in rust, and I'd love to be able to use trippy in-process rather than having to start something like https://github.com/heistp/irtt as a child process.

[fujiapple852]

@wgreenberg this has been merged and the new crates will be published to crates.io in the 0.11.0 release. Note that the public API of trippy-core should be considered highly unstable for the moment, it will change in the future (it was created to support the Trippy tool only, it was never designed for public consumption).

[c-git]

@fujiapple852 thank you very much for taking the time to do the split. I think even if it changes often it will still provide value.

[wgreenberg]

thanks a ton @fujiapple852! agreed, even if it's not stable yet this'll be helpful.