@Lcrossman , Istvan's excellent comments could have been probably handled by offering something that had everything already set up for the curious user so that 'it just worked'. From what I can tell, this doesn't need a lot of computational power, at least for these small-scale examples, and so they are quite amenable for offering via Jupyter's MyBinder service that integrates very well with GitHub repos.
To demonstrate, I forked the repo and made some configuration files in a directory named binder. So now if you go to my fork and hit a launch badge, you'll get a session where everything is already set up to run.
To save those curious from an extra step, one can just press the launch badge on the next line to get a remote session with two notebooks available to demonstrate the package:
That content is just mainly placeholder content to show you what is possible. Hopefully with it, you can see how you could set up things to do as Istvan says 'make sure to demonstrate all use cases in Python'.
Aside from making it easy for introducing new users to your package, going this route quickly helps highlight where you, as the developer need to focus because you get a new machine each session. Furthermore, it eliminates the 'on my machine' issue that will arise often with users filing issues. Offering a level playing field can help in a lot a ways.
Opinions will differ, but I don't think any of the tasks you describe is a major bottleneck. Whether a BLAST XML file is parsed in 7 seconds or half a second should be of no consequence to most people.
While I think it is nice to have a collection of these tools in one place, you may need to find another selling point that goes beyond speeding up something that already doesn't take a long time.
Thanks for your feedback Mensur Dlakic I appreciate receiving it, however, I would like to bring this to your attention which exactly happened to me after building these scripts and that is why I made them available as open source.
Whilst I was converting 10,000 gbk files to protein fasta - this took 4 hours in Python but only 25 minutes in microBioRust. I could have downloaded all the files in protein fasta format - but then I would have to store it, and it is more traffic for the databases.
Even if so another way of looking at it is - if 10,000 people convert 1 gbk file to protein fasta in microBioRust instead of Python = a large impact in compute resource. Someone is saving $.
That is why we are working to get it speedier which we have already pinpointed a further inefficiency, along with adding other functionality.
L
Each one of those 10,000 people i s saving money, to the tune of $0.00000001 or so. As to your 10,000 files, it is my guess that not many people have to do that conversion. Even if they do, it can't be very often. Good luck selling a software to people that saves them a second or two and an amount of money that can't be calculated without a scientific calculator.
Alternative view - it's great to see many more fast tools written in Rust these days which make my life easier as a pipeline author by often being a single binary. Thanks!
Thanks colindaven !
Actually, it's important feedback to find out what people are thinking on this, so we can clearly state our point.
For the single user, it is a question of scale as well, for example, if I put a single plastic bottle in the recycling, this does not directly benefit me as a single user at that one time at all. It might even be annoying to have two separate bins/trash cans. The benefit is much further down the line.
Yet someone sold that idea to everyone.
If you pay for your compute directly as I do, saving compute is more directly a benefit but saving time and compute is still green. So we are aiming to build this repo to include other fast tools!