Tool development proposal

[david-bouyssie]

In an other discussion (https://github.com/orgs/rusteomics/discussions/6) we mentioned the idea of developing a Rust app that could test and showcase some Rusteomics features by leveraging the developed libraries (mzcore/mzio for now).

Here is some rationale from @lazear:

I would propose that some Rust application be developed so that the Rusteomics API can grow in a somewhat organic and cohesive way. For example, could leverage some of the MSP/MGF work already done and build a spectral library generator - take a peptide sequence, MGF file, scan number and write out the matched peaks. This should be relatively straightforward and would help to develop some of the core parts of the API.
I think this would solve some of the issues inherent to building a library that has no users - much easier (IMO) to build a library in tandem with an application that is actually using it.

I share the same feeling, as it could ease prototyping new features before having to decide about polishing the final API. And honestly end-users (I mean here MS practitioners) don't really care about well designed APIs. Most of the time, they "just" want to have, quickly, some accurate and meaningful TSV tables.
I think the Rusteomics project goal is to both satisfy bioinformaticians and final end-users.
Libraries with well-designed APIs can satisfy the former, while a dedicated tool/app can satisfy the later, among other benefits (testing the APIs for instance).

[douweschulte]

Building some tool to showcase and test the API is very beneficial I would think. I did the same for my library and that helped shape the direction for implementing new features as well as the api surface. So in general I would be very much in favour. The negative side is that this gives us more code to develop and more stuff to work on.

My current projects based on rustyms are:

• https://github.com/snijderlab/annotator - a simple GUI to load raw files and identified peptide files and look at the annotations and try out new ones. I think this one would be somewhat easy to rewrite to use the new mzcore/mzio libraries under the hood with minimal changes to the actual interface/application code. Though it leans quite heavily on some features that will take a while to be implemented in mzio (namely ProForma parsing).
• https://github.com/snijderlab/align-cli - a tool that primarily does alignment of peptides based on an alignment algorithm I developed/am developing that takes MS errors/mass coincidences/isobaric aminoacid sets into account. As this algorithm is quite outside the scope for the current mzcore setup I do not think this part should be taken over. But something that can be taken over is its interface where you give it a single peptide and it gives the mass, composition, and isobaric peptides, which is something I and my colleagues use on a daily basis.

From my side I would vote for creating a fork of the annotator to rewrite it to be based on mzcore/mzio, but do this only when a couple of PRs have merged and the basics that are needed for this program to make any sense are in place.