CLI or package?

Hi folks,

I have been thinking about releasing the project that I am working on (my final PhD project) but I have some doubts/questions. I would appreciate it if any of you throw some ideas at me (links, keywords, etc.).

The project is a concurrency testing framework. It takes a go source as input, automatically instruments and collects a set of traces, and does some analysis on the collected (stored) data. Its ultimate focus is on exploring interleaving space and covering some concurrency coverage criteria.

For doing that, I inject some additional code to the runtime (by a pre-written patch), connect to a SQL database and query the database for analysis. So it is not a straightforward API to be usable through a package. However, I have been thinking about building the project somehow through to the built-in “testing” package of Go. This way users can enhance their unit testing with some concurrency testing too; but I am not sure how feasible is that.

With that being said, what do you think is a better option. Which on is a better fit for such a tool, a CLI or a package? What are the factors in making such a decision? Any input is much appreciated. I would be more than happy to clear things out if you have questions.

Cheers

Just a couple of thoughts that might help you think thru this…

  1. Having an SQL database is a huge dependency problem. I’d rethink how to manage the data without one
  2. Today Go testing has Test* and Benchmark*; I suppose you could add a third (Analyze* ?). But patching the Go source seems way too much to be able to use this.

I’d suggest making a package and then provide a CLI using the package. This would give a users a concrete example of how to use it.

Good luck!

2 Likes

Thanks for the ideas. I much liked the idea of having both CLI and package (CLI uses the package).

It is going to be a research tool and not production. Although I agree with your statement of SQL being a huge dependency, I think researchers would not mind giving the tool a try or build on top of it. The data and their relation (and consequently the queries) can get overwhelmingly huge and complex.