add trycycler 0.5.3

[kapsakcj]

https://github.com/rrwick/Trycycler/releases/tag/v0.5.2

need to upgrade the muscle version, since this new release supports muscle v5. Might need to install manually instead of via apt

[kapsakcj]

looks like trycycler is compatible with either 3.X or 5.X versions of muscle https://github.com/rrwick/Trycycler/commit/8e475a898c395ad8dc8aa183d80c4def53ca8e57

[kapsakcj]

and now 0.5.3!

[jrichardsz]

Hi.

The 0.5.3 Dockerfile will be is almost the same as 0.5.0. Just change some versions in the Dockerfile is required or could work just passing the version as a build argument.

In this case, Is it required to create a new folder 0.5.3 with another Dockerfile and readme?

[k-florek]

@jrichardsz our practice is to keep separate Dockerfiles for each new version. New versions of tools can sometimes have a big impact and some users may never update to the new version. So its sometimes best to think of each version as a completely new tool and why we keep separate Dockerfiles for each new version that gets released.

[jrichardsz]

@k-florek If I want to help adding the trycycler 0.5.3, How can you test this specific version before approving my pull request? Does some member of your team have to download my Dockerfile, build, run and test it?

Reviewing the last version : https://github.com/StaPH-B/docker-builds/tree/master/trycycler/0.5.0 I don't find any kind of test of this dockerized version.

But the real trycycler repository https://github.com/rrwick/Trycycler/tree/main/test has several tests to ensure that new changes on its core (python) don't break anything.

My intention if you allow me, is try to add some dockerized version of some tool without break anything :)

If you have some tool that has not been dockerized yet, due to some complexity, I'm ready to help.

[k-florek]

@jrichardsz Essentially yes, if you would like to work on adding trycycler 0.5.3 feel free to open a pull request with the 0.5.3 dockerfile in a subfolder under trycycler labeled 0.5.3. We would then run and test it before incorporating it into the repository and building the docker image.

[kapsakcj]

Just FYI the author of Trycycler provides multiple test datasets which can be used to ensure functionality of the tool.

Some details here: https://github.com/StaPH-B/docker-builds/pull/238

I have the "Great Dataset" downloaded locally, so I'm happy to test once a dockerfile is available for v0.5.3

[jrichardsz]

@kapsakcj Do you think that if we automate this test, it would be helpful reducing human effort and/or ensuring integrity?

Let's imagine this:

approach 1 (easy)

• StaPH-B, proposes a standard that every new tool should be accomplish if wants to be part of State Public Health Bioinformatics Workgroup
• This standard says that if the tool is oriented to the shell, it must have a command called help with a zero as exit code. This command could return some details like version, build date, other commands. etc . In the trycycler example could be: trycycler --help
• If trycycler and every tool to be dockerized, accomplish this, it would be easy to develop a simple bash script at the root of repository whose goal will be :
  • iterate all tools
  • on each iteration, build and run executing the help command

  docker build --rm -t trycycler:0.5.3 .
  docker run exec -it trycycler:0.5.3 trycycler --help
  

  • if help command throws an error, it would tell us that: Dockerfile has a bug that makes even the most basic command not work
• This should be easy to run manually by a human(which is ready to test the entire repository with one click), using github actions, before to perform a pull request, etc, etc
• Also it is possible to develop a basic report at the end to view which tools are fine or wrong
• If the tools creators are not able to follow this standard, the docker contributors could do it.

approach 2

Similar to the approach 1, but instead of help command, a set of commands with input and expected outputs using your "Great Dataset"

approach 3

Similar to the approach 2, but package as a shell tool, the docker contributor (not the tool creator) should package the tool as an Http Rest API.

Advantages of this approach are:

• the http protocol is easier to use vs shell executions.
• If we know that some laboratory has a rest api which offer some awesome tools and web have the permissions or is public, it is easy to consume that rest api from any part of the world.
• test the dockerized tool it is easier
• a good rest api has good documentation. So as a result you could have an online 24x7 catalog with all the tools and its operations, commands or features, well documented. Also each parameter should be documented. Examples:
  • https://spoonacular.com/food-api/docs
  • https://explore.postman.com/templates/7912/public-rest-apis

• open the possibility that juniors on Bioinformatics, following the documentation, could help with the test using some http client like Postman
• With some time, effort, docker-compose and a simple programing language, it is possible to have a web server ready to be hosted on any linux server in the world. This web server offer two main features:
  • the api docs
  • the api ready to used
• remote tool invocation from any client: iot, web, shell, android, ios, etc

Also this is related to https://github.com/StaPH-B/docker-builds/issues/272 but I couldn't answer because it's closed.

Sorry if this is off-topic or is not in your plans. I promise don't touch this topic again.

Regards

[erinyoung]

@jrichardsz , were you still interested in creating an updated trycycler docker container for us?

I imagine the dockerfile would be similar to the older version, but would need

• updated version (instead of 5.0.0)
• running the main installation portion as app followed by a test (We now use github actions to run the dockerfile to the test target of the dockerfile. As example : https://github.com/StaPH-B/docker-builds/blob/master/bbtools/38.96/Dockerfile
• then there are three additional files that need to added to the repo that shouldn't be too painful
  • a short readme specifically for this tool in its repo (it's going to dockerhub someday)
  • a test-trycycler.yml and deploy-trycycler.yml in the .github/workflows directory. These have templates you just have to replace the tool and version with what you're working on.