 The first thing you should do, if you haven't done so already, is clone a fork of the Bioconda Recipes GitHub repository. This will make it much easier in the future to commit and create pull requests. This process takes a bit of time, so I will be skipping that part of the video. Once this process is finished, we can change into that directory, so that Git can find our changes and so on. Then we want to create a new branch. In this case, we're calling it the Balerifon Bioconda because the software we are creating a recipe for is named Balerifon. We also want to create a condo environment with the same name so that we can easily find it later with some simple dependencies such as condo build and pip and Python. This is another process that takes a while, so if you're following along with the video, now would be a good time to pause and wait for condo to install all its dependencies, maybe refresh your drink or what have you, and if that is the case, I will see you when you get back. Welcome back. Now we activate the environment we just created. That way, no other dependencies or software is messing with us. Now we also know that we're going to need the SourceTurbles checksum or hash, which we get by downloading it using WGet from GitHub. Usually you find these at the end of a GitHub repository's URL, followed by the word archive and the version of the package or release, and then the compression for that archive. Then we pass that tarble, which we saved locally, through a program to generate the checksum. It is not a very large file, so it's not going to take long, so we select that 60 character hexadecimal string, then we create a directory for the meta.yaml file, and with our favorite editor, we edit the meta.yaml file. This will also create the file. Now for starters, we're going to want some template variables like the name and version and so on. This is going to make it possible for the bioconda automated process to whenever a new version is released. Automatically update the bioconda recipe, so the recipe maintainer often need not do anything. In this line here we paste the hash that we just copied from the WGet command, and then we're ready to define the metadata for the contorecipe itself. We start with the package directive, we give it the name and plug in the variable we defined above, passing it through lowercase because in some github URLs this may be a various case. Then we plug in the version variable, and we define the source section. Here we give it a URL with some template variables plugged in so that, again, the automated process can create recipes for new versions without any difficulty. In this one we do not pass it through lowercase because github URLs are case sensitive, and the version, of course, is numeric in this case, so it does not need lower casing. Then we plug in the hash that we defined above. This also automatically gets updated whenever new versions are released. Once we've done that, we define the build section. First of all, we know this is a Python package, so we don't need to build it for separate architectures. It's a new recipe, so build number zero. And then condo build has certain also template variables defined that we can use to build Python packages. We also want to include some flags that tell condo build that it does not need to build dependencies, and it does not need to check for installed packages. Now we need to define the dependencies. In the host section are the dependencies for actually creating the condo package. In this case, it's only Python and PIP because Balerifon is a Python package. Then in the run section, we define the dependencies needed to actually execute the tool, which is also PySAM. Furthermore, it's always good to define a test section in your condo recipes. For Balerifon, it's sufficient to just put in the dash dash version flag. And finally, we define the about section of this recipe. We put in the home page as the GitHub URL to Balerifon, which is under my GitHub account. We specify the license under which this code is licensed, which for Balerifon is MIT. The license file directive mentions the path to the file where the text of the license is found. And finally, we write a quick summary of what the tool does. In this case, Balerifon filters BAM files for reads where there is high-quality mapping on either side of a splice junction and retains the five-prime side of those reads. It then merges those reads into a single paired-end BAM file. Once we are done editing our recipe, we tell condo to build this. This is a process that again takes quite a bit of time. So if you're following along with the recipe, now would be another good time to pause the video and take a break, stretch your legs, or refresh your drink. And I will again see you when you're back. Welcome back. Now that our recipe is successfully built, we check our git status to make sure that no stray files are there. We're good. So we add recipe slash Balerifon. Check the status again. And yes, that's all we added. Now we check the diff to make absolutely sure that we committed everything correctly, which we did. So now we exit and acute the actual commit command, which is add recipe for Balerifon version 1.0. It's always useful to make the commit message something meaningful. Now that we've done that, we push to our fork, making sure to track the Balerifon BioConda branch. The output of git will give you a URL that you can simply click on to pull up the pull request. Here are some of the tips for contributors, and we select that text and write in a brief description again of what the tool does. So we basically just repeat what we said in the condo recipes about section. And once the description is written, I like to make one final check of the diff to make sure that I actually committed and pushed everything I meant to commit and push. Because there have been times when I didn't. Everything looks good, so I can just click the create pull request button. And so the pull request has been created. Each pull request to BioConda recipes is always passed through a series of continuous integration testings, and some review and code editing after which your recipe will be merged. And after a few minutes, usually 15 to 20, the recipe will be available on anaconda.org, which we double check by going to anaconda.org, typing in Balerifon in the search bar. And sure enough, there it is. We can then click on the name of the package. We'll see some details here, such as license, and the files we see the no arch. And we have successfully created a BioConda package. I will now pass you over to my colleague Alex Ostrowski, who will go into creating the Galaxy XML for the tool wrapper.