 Salut tout le monde, Maxim ici. Aujourd'hui, c'est mon grand plaisir à avoir Archeel qui explique tout le nouveau Et, Arshil, au revoir à vous. C'est génial. Merci d'avoir vu ça. OK, c'est bien depuis que j'ai fait un de ces. J'ai essayé de le faire plus tôt. J'ai une bonne réputation pour le faire. Je n'ai jamais pu le faire. Donc, ce que j'ai fait ici, c'est de vous donner une idée d'une des raisonnements et des pratiques d'enlever la direction de vie dans l'update de la température. Apologies si vous n'avez pas eu le temps pour ça. Vous avez vu ces complexes massives dans vos updates de la température de la température de pipeline après les tools de la version la plus lente. C'est une des choses que nous avons décidées relativement à la fin de l'année dernière à la cour de la cour en Suède. La principale motivation, je pense, c'est d'enlever la direction de vie de la température de pipeline, c'est qu'on veut essayer de faire chaque component dans un pipeline, c'est-à-dire des modules, des sub-workflows et des workflows, comme celles-ci, comme possible. Le fait qu'on a maintenant, ou qu'on a eu cette direction de vie qui s'étendait au-delà des compagnons, c'est qu'on a besoin d'un module, un sub-workflow, un workflow où l'on veut. Un exemple classique de ça est dans ce script principal, qui est directement importé dans ce workflow, le script principal de la direction de vie pour utiliser cette fonction particulière. Si nous voulons faire des compagnons celles qui s'étendent, nous avons besoin d'une direction de vie parce qu'on doit maintenant maintenir les fonctions, les classes et tout ce qu'on fait dans la direction de vie séparatement. Si je voulais partager un component avec vous pour faire un workflow final, vous n'avez pas besoin d'installer ce sub-workflow et le workflow, mais aussi d'installer et de copier tout dans la direction de vie, ce qui est difficile à maintenir. Je pense que c'est un thème général où nous allons avec le template pipeline, c'est que nous voulons essayer d'utiliser les compagnons celles celles qui s'étendent au-delà des compagnons celles, donc le module va venir avec son script principal, il va venir avec ses tests, l'NF test. C'est quelque chose que nous avons travaillé dans le Fetch and GS pipeline et plusieurs autres pipelines qui ont déjà commencé à utiliser l'NF test. C'est un sujet séparat pour ce qu'il s'agit de ces vitres et peut-être qu'on va avoir un autre sur les choses que nous avons faits sur l'NF test pour essayer de standardiser ce qu'il ressemble à. Donc pour chaque component, vous pouvez imaginer que ça va venir avec le script principal qui fait un processus, un sub-workflow ou un workflow. Et puis ce component va aussi arriver avec son configuration, l'objectif d'utiliser, et plusieurs autres choses. Encore une fois, ça fait que c'est beaucoup plus facile de partager un sub-workflow avec un autre pipeline si tout est déjà bundlé là-bas. Vous pouvez le changer au-delà, si vous voulez. Mais c'est plus facile de le faire. À un moment, nous avons un problème similaire avec le module.config où nous avons un grand config monolithique avec tous les différents processus nécessaires dans le pipeline. Alors, plutôt que d'avoir un grand file, ça fait plus de sens d'avoir une merde avec ces components. Nous avons parlé de ce que l'on l'a lente sur le Barcelona hackathon et plusieurs choses qui ont été passées depuis. Ce qui va nous permettre d'essentier de faire ça un peu plus facile en termes de components. Mais il y a des autres choses aussi potentiellement dans le pipeline template dans le futur qui pourrait être plus faible que le splitting-out. Comme le schéma parameter. À un moment, c'est un grand file monolithique. Si vous voulez partager les components, vous devez installer les components et aussi maintenir un schéma séparé avec tous les paramètres que vous pourriez utiliser dans ces components. Et ça devient plus d'un problème sur le niveau de travail où vous utilisez des paramètres dans le contexte de travail. C'est quelque chose qu'on a parlé dans la prochaine vidéo en termes de construire et d'avoir cette philosophie idéale. Ce qu'il y a dans le futur potentiellement est qu'on pourrait avoir une option dans le package de tools qui est un module install et un sub-workflow install ainsi que le workflow install. La seule façon que l'on peut faire un install c'est d'avoir tout ce qu'il y a dans la direction que l'on peut installer. Si quelqu'un veut installer Fetch and GS dans un particulier pipeline, plus détaché, nous gardons tous ces différents components sur la structure principale la plus facile c'est de poursuivre. C'est la principale motivation pour ceci. Il y aura beaucoup d'advantages pour ceci mais il y a aussi d'advantages que si nous avons maintenant retiré la direction de travail et que nous avons des sub-workflow comme je vous l'ai dit très rapidement dans la seconde ce sera aussi possible que nous pouvons commencer à bouger dans un template pipeline qui est un peu plus grand en termes des components que l'on peut installer avec le template pipeline. Donc, maintenant, il y a quelques options où vous pouvez configurer si vous voulez un config hygiénique ou un CICD et d'autres choses dans le template pipeline. Mais, idéalement, ce sera bien de faire le template pipeline aussi flexible que possible pour les choses d'hygiene. Vous ne pourrez pas utiliser les genomes dans un pipeline astronomy ou un autre pipeline. Donc, ce que l'on peut faire avec la direction de travail c'est de nous permettre de maintenant faire le template pipeline plus flexible pour les utilisateurs où ils peuvent dire qu'ils n'ont pas de genomes ou qu'ils n'ont pas de CICD et qu'on peut vraiment commencer à les nommer. Ce qui a été difficile dans le passé, c'est que nous avons utilisé les replacements de coquille sur le template pipeline et cela devient un détail pour maintenir le test en tant que sub-workflows isolés qui le font beaucoup plus facile. Et aussi, le fait qu'il y a un sub-workflows tout ce qui était dans la direction de travail a été mis à la place de l'enf4 module dans le sub-workflow. Donc, nous pouvons maintenant aussi commencer à maintenir les sub-workflows par l'enf4 module et à l'installer en plus redoutable plutôt que de faire une release de l'enf4 tool avec un bunch de changements et des conflits de merging et ce genre de choses. Donc, en général, il y a un nombre de advantages pour le faire. Je comprends que ça peut être un peu un peu tricky pour faire le transition mais essentiellement, tout ce qui était dans le lit nous avons maintenant dans les sub-workflows et l'idée c'est d'installer les sub-workflows et puis, lentement, retirer la direction de travail et dans le bloc que Maxime a posté dans la chaîne de bi-size, il y a un box de tip qui peut-être être un meilleur moyen de le faire plutôt que de rassembler avec des updates de template donc quelques gens qui sont venus avec des réponses disant que c'est difficile de le mentionner et donc, j'ai écrit un livre sur ce qui m'a aidé afin de faire cela plus facile et essentiellement, si vous follow l'advice et installez-le ou installez les sub-workflows sur le bloc de la chaîne de bi-size, vous pouvez ensuite retirer la direction de travail en un peu plus agressif plutôt que de rassembler les conflits de travail où vous ne savez pas ce qu'il faut inclure et cela devient un problème. Donc, vous devez définir un peu de ça. Ok, donc, ce que j'ai fait ici dans la chaîne de bi-size dont vous devriez voir est que j'ai créé deux versions de la template pipeline donc l'un de la gauche est avec la direction de travail donc cela a été créé avec l'AF4 tools 2.12.1 où nous avons encore la direction de travail l'un de la droite est où nous avons retiré ça en 2.13 et donc, c'est juste pour vous donner un overview de ce que nous avons fait donc nous avons des files sur la direction de travail qui ont eu des fonctions comme ceci sur les quantités quantes versions, emails et plusieurs autres choses nous avons un main qui était essentiellement initialisé dans la pipeline et ensuite nous avons une pipeline spécifique qui était en train de faire un peu d'autres choses qui ont peut-être validé des paramètres ou des genons et ce genre de choses Tout ceci a essentiellement été transporté dans les sub-workflows et nous avons trois sub-workflows primaires donc l'un des des choses qui sont plus génériques c'est l'un des versions de print et des paramètres qui ont été checkés sur les canadiens et donc je l'ai expliqué dans un separate workflow donc que ceux qui n'ont pas utilisé des pipelines peuvent aussi encore utiliser ce workflow pour utiliser cette fonctionnalité modulaire il y a aussi un un de la validation donc ceci n'est pas nécessairement une chose spécifique et donc ici vous pouvez commencer à interagir avec l'un de la validation et d'appliquer et de valider les paramètres et d'ailleurs, ceci est quelque chose de très généric il y a aussi un un de la pipeline spécifique donc pour ceux qui veulent utiliser la functionalité on peut juste ajouter ce sub-workflow sur le top et donc, comme je vous l'ai dit il y a des des fonctions ici par check & config donc vous pouvez voir que cette fonction a été portée dans un sub-workflow maintenant et il y a beaucoup de choses comme ça donc vous pouvez aller dans ce que l'on vit et dans ces sub-workflows et commentez-vous et l'appliquer jusqu'à ce que vous êtes heureux avec l'intégration citations, versions il y a aussi l'obligation d'utiliser Nextflow c'est impliqué d'avoir les versions de collection de Nextflow et d'utiliser MultiQC si vous utilisez ça dans votre pipeline pour ensuite rapporter ces versions de software on n'a pas besoin d'avoir un procédé custom de la version de software n'importe quoi tout ça c'est de la saison avec Groovy et puis si vous voulez MultiQC c'est de la même la file de collection et donc dans la main-script vous verrez pour le workflow vous verrez qu'on est c'est-à-dire incluant ça pour mettre ça à la fin du workflow mais tout autre c'est plutôt ici maintenant dans ces séparats scripts il y a aussi un local sub-workflow maintenant ce qui est quelque chose qui est plus spécifique pour votre pipeline donc n'importe quoi qui a précédemment été dans la direction de vie spécifique pour votre RNA-seq workflow ou d'autres pipeline workflow vous pouvez les apporter dans ce file et ce qu'il fait c'est qu'il contient plusieurs workflows dans ici et l'idée derrière c'est que ce qui nous permet c'est d'attacher le pipeline à l'end logique qui est plus ou moins plus négé de cette particular pipeline ça nous permet d'attacher de l'application d'aujourd'hui et d'avoir ça comme un sub-workflow qui est plus pipeline spécifique et donc ce sub-workflow ici c'est très spécifique il vous permet d'initialiser le pipeline et aussi quand le pipeline finit il vous permet d'appliquer ces emails et donc avant vous verrez ce sort de logique qui aurait été à l'end de la workflow mais ce n'a pas été déclaré parce qu'il nous permet d'être plus flexible en termes de partager ces workflows aussi donc le workflow est essentiellement maintenant en prenant une sorte d'computation basé sur ce que nous voulons faire en termes de procédure les avant et les après-mêmes sont maintenant faits au niveau pipeline et donc dans le futur potentiellement si vous voulez commencer maintenant à installer autres workflows d'autres sources comme Petch, NGS ou d'autres mais avant et après la logique est toujours constrainée pour quelque chose qu'il pourrait faire dans le pipeline et puis vous pour simplement installer ces workflows directement et utilise-les dans votre main-script ok so that's an overview of these different sub-workflows what it essentially means is that when we when we look at these these different main-scripts now we can see that we've stripped out a lot now this is just a pipeline template if you look at a more realistic comparison between before and after for RNA-Seat you'll see there's a lot of boilerplate stuff in the main-script that the main-script in the root of the directory as well as the main-script for the main RNA-Seat workflow that has all been stripped out now and we're able to delete a lot of that stuff to keep that workflow as clean as possible in terms of what it's doing as a workflow itself and so a lot of that has been stripped out now you can see where including these sub-workflows I mentioned and this invoking those same functions is up to you what you include in these local sub-workflows for your pipeline so that keeps it relatively flexible ok so that's sort of an overview of removing removing the lib directory and what that's allowed us to do there's a couple of other things that have allowed and we've also included in this tools release like removing the the check sample sheet script that we're using to check the sample sheet we're now using NF validation for all of this and that's actually been performed in this initialisation sub-workflow this is something specific to the pipeline which is why it's been added to this pipeline initialisation sub-workflow and so it's up to you how you configure this there's a good question on Slack the other day about not being able to emit channels that have branching in them and that's just an expo specific feature so as long as you're not doing a branch operation in this particular section to have different versions it makes sense to potentially do this NF validation loading of your sample sheet here and then you just pass your inputs to your workflow as a channel if you can't do that then you could just copy this block in the main script of your workflow either or I'm having a little R and A seek if you need some guidance on the dev branch alright so that's pretty much it really in terms of what this means it basically means that all of this stuff now that was in the old template is now being simplified and added into these individual sub-workflows so let's try and find that one actually for this so this is where we're putting the citation and the main text I think that's in the end of Core 5.21 and so yeah so here you can see in the we've got this the logo and everything is now being shipped into this separate sub-workflow and we can import that via a sub-workflow standard next one imported to use elsewhere okay finally there are some other things coming up that haven't been included as part of this tools release so just as a heads up there are things that we've done in FetchMGS and in other pipelines like here we've now also starting to standardise how we're having to NF test inclusion in these pipelines each component is now in its own separate folder that hasn't been done as part of the latest version this is something that will come later on there's also a view to make the config more granular as I mentioned by removing the module.config to make these components more shareable and in general there have been a number of improvements in the way that we're using NF test so if you want some references to have a look at how it's done have a look at FetchMGS on the dev price there should be a release coming up very soon and the RNA seek pipeline on the dev branch we're still tackling away a lot of the NF test stuff by RNA seek but the core sort of porting and removal of the lib directory and module.config and software versions and all of that sort of stuff has already been stripped out in RNA seek and if you're having questions then please feel free to ping us some questions and we'll be happy to help but I think that's it from me and I'll ask you any questions Thank you very much Arshil that was very enlightening let me just... OK, I'll spotlight this and back yes, so now I will open the floor to see if everyone has any question yes, for me I had a play like with the completed date and I participated like a bit into that and I really like the whole idea but being able to uncouple some of the logic from the sub workflow like outside of the sub workflow and I really like that it makes really everything like more portable and more sharable and I'm really looking forward for like how that will be able like to come out of that yes, Jonas just pasted like some référence, if you're using like branching the sample sheet into different channels for the EPITOP prediction pipeline Marike said she had like no question but she was like very happy with the explanation anyone else has any question? Not a question, just a comment I remember when I was getting into using NFCore templating the lib directory was one of the things that was most confusing for me and trying to understand where should I put stuff does it belong in the lib directory or does it belong like in a sub workflow so just from a accessibility perspective and making this more accessible to a broader range of developers I'm really excited about this change Awesome, thank you I mean this is ongoing work if there are things that don't quite work for you or could it be improved I mean this has been an accumulation of stuff that we've pushed to Fetch.NGS as well as RNaseek and in a more real world context just to make sure that it works because there's slightly different pipelines in functionality for example when Fetch.NGS doesn't use any genomes whereas RNaseek does and so once I added this to RNaseek I really sort of figured I had a good layer of the land in terms of what we'd need to do to add this to the pipeline template but I completely agree with you the lib directory has often been a big sense of confusion but especially for people that don't know a groovy and want to step into using a template and so I'm not having that here as part of the corpac pipeline template I think it's going to be massively powerful because we would then be using components that people are more familiar with like sub-workflows and modules which isn't necessarily very different to what Nix offers already and so yeah, in the future there might be even more options to really create a very minimal version of the pipeline template but those that don't want to have to maintain their own templates and just want a very tiny prototype next to a repo to start with rather than having all the bells and whistles that we currently share for the port template and so over time the plan is to, as I mentioned to make each of these components as standalone as possible come with the main script, the tests the configuration, ideally the parameters and the output definitions and that way anyone can come in and just do an install command and get pretty much everything they need to reuse that component rather than having to look in 15 different places and where parameters are initialized and where configuration is set and where custom functions are being used in so that's the long-term plan for this. Yeah, Adam Talbot and I have had some good discussions about creating minimal Nix flow templates and his removal of the lib directory and the version, the NF STEM version that he has on his GitHub was one of the improvements that I thought, oh, this is a great addition to sort of making it more simple. I have a question. Yeah. It's actually just to verify those things for the... it will become more configurable what parameters to have and etc. Like the genomes and so those are only for the future, right? So there's nothing... What I need to do still today with my file of place pipeline that doesn't use many of the default parameters and it doesn't even use FastQC I still have to weed out all these things with the template update, right? Yes, yes, I completely agree. It's a pain that the thing is we need to test something when we create this pipeline template, right? So at the moment it's only been FastQC and MultiQC as part of that template but now we've got these sub workflows and various other things in the pipeline template that installing FastQC and MultiQC it's just a NFCore modules command to install either FastQC or MultiQC, right? If those components... And again, this is where the power of having standalone components comes in if those components come with their own configuration that isn't in a modules.config now when we install that module it already comes with all the publishing logic and everything it needs and so when we have the logic in the pipeline template as part of NFCore Create we can just say or have an option on command line that just says exclude FastQC, exclude MultiQC and it shouldn't have any massive impact on the version of the pipeline template that you've created and that's also partly why we're going about this whole someone dance to remove the lib directory because we're moving to components that can be controlled by the tooling rather than having lots of different cookie-cutter things in the template that says if you're using pygenomes, if you don't want pygenomes and cut this portion out of the template and it becomes a mess to test them out there. But that's the plan. Yes, no, I think for me what I like a lot about this new update and this new feature is that now the lib folder or what was the lib folder is not part of the template anymore but part of the module repo of the sub-workflow so it's much easier just to update because we can update that just with tools and for me, that's what makes the world stuff worthwhile. Do we have any other question? I feel we are good, wonderful. So thank you again, Arshil. I think that was quite enlightening. Yes, definitely, I think we can say that if people still have issues, they should not hesitate to ask questions. We have the help channel, we have tools, we have LinkedIn, we have every possible channel. And remember, there are no stupid questions. We have a strike channel for that. Also, ReberDuck is also a good channel if you want to just ramble and try to figure out stuff by yourself but still want people to listen to you. So yes, just go on and figure things out. So thank you very much. Arshil, one last thing to say. Yeah, sort of echoing that to some extent. I mean, as I said, this is all very new. We've only really added this in the tools released now. There's a tonne of stuff potentially that may or may not be working. We've tested it to the best of our ability by email functionality in the pipeline template, which is horrendous to test because you need to set up servers and that sort of stuff. And that's a different problem. But if you see anything that looks suspicious or you have any questions or improvements or fixes, please feel free to maybe comment and tools if it's an issue with the template itself or the tooling or feature requests. Or for any sort of other general conversation, I guess we can take it elsewhere and slap work the appropriate challenges. But yeah, thank you for joining. And as I said, apologies for any inconvenience this has caused in terms of the transition. But hopefully once you're there, it will make things a lot easier. I don't think we're going to be significantly changing this for a while now. So yeah, thank you.