 Hola, otra vez bienvenidos a la sesión 2 de este community training en español. Ayer estuvimos viendo la sesión 1 donde vimos una introducción a NextLow y luego usamos al NACI como prueba de concepto para ver cómo era una pipeline, cómo programar una pipeline en NextLow. Hoy nos toca la sesión 2, empezaremos con una introducción a NFCore, luego veremos cómo usar NFCore, cómo nos puede ayudar si somos usuarios, luego si somos desarrolladores y finalmente veremos qué son o veremos más profundamente, módulos y sap workflows. Luego en las siguientes sesiones 3 y 4 profundizaremos más en dependencias, canales, procesos y operadores. También veremos un poco de groovy y modularización y finalmente en la sesión 4 hablaremos de configuración, implementación, resumen que ya vimos también durante la sesión 1 y resolución de problemas y tower. Quiero recordaros que si tenéis preguntas podéis acceder a estos canales de Slack, aquí tenéis el link para uniros Slack en caso de que aún no os hayáis unido y los diferentes canales para los diferentes idiomas que vamos a estar respondiendo las dudas sobre este training. Vamos a empezar entonces, vamos a empezar hallando esta página, la página de NFCore. Voy a cambiar la página de compartir. Aquí tenemos la página web de NFCore, durante la sesión de hoy no vamos a estar siguiendo el tutorial, sino que vamos a estar usando documentación y empezamos para revisar y explicar un poco qué es la página de NFCore. Cuando entreis en la página tenéis aquí varios, de hecho ahora aparece la notificación del siguiente evento, que es este training. Luego tenemos un enlace directo para ver las diferentes pipelines que forman parte de NFCore, también podemos buscar, pero vamos a ver lo más importante, que son las características de las pipelines de NFCore. En primer lugar tienen todas, todas las pipelines tienen una documentación bastante extensa, entonces podéis encontrar siempre en cada una de ellas cómo funcionan, cómo usarlas. Luego también tienen tests de integración, es decir que cada vez que hay modificaciones en las pipelines y sale una nueva versión, se corren tests para asegurar que todo sigue funcionando correctamente. También dispone de releases, es decir, de versiones estables y también podéis acceder a versiones anteriores. Luego como ya hemos comentado varias veces, todo el software que necesitemos está empaquetado en containers y se pueden usar gestores cómodos o que es Singularity o Konda o otros. También todas las pipelines son portables y reproducibles en cualquier sistema e incluso también son escalables para computación en la Nougat. Para desarrolladores, tenemos estas tres secciones que nos gustaría destacar en NFCore, primero es que podéis desarrollar con la comunidad, es decir, que podéis acceder sobre todo a través de Slack, podéis acceder a la comunidad y desarrollar en grupo, obtener ayuda, preguntas que tengáis, también feedback, porque hay tantos desarrolladores como usuarios, entonces la comunicación es muy abierta y podéis obtener feedback sobre el análisis en el que estáis trabajando. Por ejemplo, que es lo que necesitan los usuarios. Luego también todas las pipelines de NFCore tienen una plantilla, una template, empiezan desde la misma plantilla. Esto lo que hace es que todas funcionen de la misma manera. Es fácil adaptarse de una a otra y además también a la hora de desarrollar la estructura está ya planificada y es como fácil de seguir. Lo que también nos proporciona esta plantilla es que cuando hay alguna mejora en Nexlo, por ejemplo, que se tiene que aplicar a las pipelines o alguna mejora en las guías que sigue NFCore, se puede hacer la mejora en la pipeline directamente usando esta plantilla y por tanto es mucho más fácil aplicar las actualizaciones. Y finalmente colaborar, no duplicar, que es el concepto este de que no hace falta hacer desde cero una pipeline que ya existe, sino que podemos colaborar y mejorar o añadir nuevas funcionalidades a las pipelines que ya están existiendo si es que hacen el mismo tipo de análisis. Luego en esta sección tenéis más tutoriales enlaces a otros vídeos de tutoriales y de bite size talks, que también veremos que son, pero es básicamente si queréis tener más información sobre algún tema específico que tenéis algunos enlaces directos. También tenéis la sección para empezar rápidamente, otros enlaces directos y gente que está ahora mismo usando ya NFCore y la sección con más información. Entonces vamos a ver desde la barra de menú del inicio. Lo primero que nos encontramos, ahora estamos en home en la página de inicio, tenemos la página de pipelines que también sería la misma de ahora mismo veis que hay 76 pipelines disponibles en el momento en que se está grabando este training. Aquí tenéis una lista de todas las pipelines disponibles en NFCore. Veis que todas tienen una breve descripción de para qué podemos usar esta página, cuando ha sido publicada por última vez la versión actual y si tiene una release, una versión estable o aún está en desarrollo, si vamos más abajo veremos que algunas de ellas están en desarrollo aún o archivadas en el caso de que hay así hay que considerar que se tenía que archivar. Entonces vamos a acceder a una, por ejemplo, vamos a buscar RMAsick. Esta es la página común, todas las pipelines tienen la misma estructura y primero tenéis, también tenéis un enlace directo a el código, en GitHub, veis la introducción que es básicamente una descripción de lo que hace la pipeline, podéis seguramente la mayoría tendrán incluidos esquemas para poder ver los análisis que se están llevando a cabo, las herramientas y software que se usan, cómo usar la pipeline y luego también a todos los contribuidores que al ser una comunidad pues hay bastante gente que contribuye a mejorar este código y cómo citar la pipeline en el caso de usarla. Luego también siempre tenemos una partida de resultados, como hemos dicho, cada vez que sale una nueva versión se hacen tests, estos tests se ejecutan automáticamente al hacer una release y siempre son usando datos de tamaño real y se ejecutan en Amazon. Entonces aquí siempre podemos ver los resultados de la última versión o también podemos cambiar a otras versiones en el caso de que queremos usar una versión antigua o ver la documentación de una versión antigua, lo podemos cambiar por aquí y esto tenemos aquí los resultados que podríamos inspeccionar de esta versión, cómo han sido los tests. Luego tenemos documentos de uso que nos van a estar explicando pues el input que tenemos que proporcionar, qué estructura debe tener, las diferentes opciones que podemos también proporcionar para customizar un poco cómo queremos que se ejecute la pipeline. Bueno información sobre Genomes, aquí cada pipeline pues tendrá su documentación específica para su uso. Luego tenemos los parámetros que ya estuvimos viendo ayer cómo dar parámetros a las pipelines con los tus guiones, entonces aquí hay una descripción de todos los parámetros disponibles para esta pipeline. Por ejemplo tenemos input, output, podemos especificar un email y podemos ver pues la información de este parámetro, el tipo y también obtener mensajes de ayuda. Por ejemplo en este caso pues tiene que ser un fichero que termine por CSV, si es obligatorio dar este parámetro y bueno todos los parámetros disponibles de la pipeline podemos obtener más documentación aquí en esta sección. Luego tenemos la sección de output que nos explica lo que vamos a obtener si corremos esta pipeline, todos los ficheros de resultado o las carpetas como se organizan y que contiene cada uno. Por ejemplo, fácil sí para analizar la calidad, tendremos los ficheros disponibles, algunos gráficos también, toda la documentación de todos los resultados que vamos a obtener en el caso de correr esta pipeline. Y finalmente tenemos estadísticas sobre la pipeline de las diferentes versiones, podemos ver su uso, cuántas veces quién ha contribuido, cuántas veces ha sido alguien la marcado como favorita, diferentes estadísticas de la pipeline. Entonces también tenemos la sección de módulos, los módulos son básicamente procesos, estuvimos viendo ayer que es un proceso, entonces se pueden empaquetar digamos en un módulo, lo que llamamos un módulo, esto es un script NextLow ya que contiene el proceso que va a correr la tarea específica para un programa específico. Y estas son toda la lista de módulos disponibles en NFCore que están programados por la comunidad y los podéis usar en vuestras pipelines, fácilmente si pueden instalar directamente y luego importarlos en vuestras pipelines para usarlos sin necesidad también de volver a programar un proceso que haga lo mismo. Ahora mismo como veis hay 800 módulos disponibles y si entrais en cualquiera de ellos, veréis que hay descripción, algunas etiquetas, también describe el input y output que va a necesitar este módulo, los diferentes inputs que tiene, outputs que tiene y la herramienta que ejecuta. Y aquí veis el comando que se puede usar para instalarlo en el caso de que lo queráis usar en vuestra pipeline y el enlace para encontrar el código en GitHub. Eso también lo veremos ya más en detalle cuando hablemos específicamente de módulos. Lo que tenemos es la sección de tools o herramientas. NFCore es una herramienta aparte de Next Locker que nos ayuda a escribir estas backlines con Next Low. Entonces tiene diferentes funciones, lo vamos a estar viendo durante la sesión de hoy. Cada una de ellas tiene diferentes comandos. Esto es un paquete de una herramienta de Python y podemos usar los diferentes comandos para hacer varias cosas y ayudarnos con nuestras backlines. Aquí podéis encontrar toda la documentación pero durante la sesión de hoy vamos a entrar más en detalle en algunos de estos comandos. Luego tenemos documentación. Aquí tenéis documentación sobre cómo usar las diferentes backlines. Tenéis también tutoriales, tutoriales de cómo contribuir a NFCore, cómo añadir una nueva pipeline, cómo usar GitHub, también el código que conducto y las guías que se usan en NFCore, sobre cómo contribuir las mejores prácticas y más tutoriales también. Entonces tenemos la página de eventos. Hay bastantes eventos en NFCore, es una comunidad bastante activa. Entonces hay varios tipos de eventos, por ejemplo los Bitesite Stalks, gracias a las fecas del Chan Zuckerberg que financian estas charlas. Son charlas cortas normalmente de unos 15 minutos, suele haber una cada semana y es un buen recurso en el caso de que queráis encontrar más información específica o una introducción de alguna pipeline en concreto o de alguna herramienta de NFCore Tools en concreto. Podéis ver buscar a ver si hay una Bitesite, una charla de Bitesite de ese tema. Luego también están chisinos de training, como ahí estamos haciendo ahora, que es este que parece aquí. Y la hackathon que ahora pasará dentro de unas semanas. Normalmente hay un par durante el año y pues es un momento en que la comunidad se une para desarrollar y trabajar en los proyectos de NFCore. Y finalmente tenemos la página de about sobre NFCore, información sobre NFCore, sobre la comunidad, algunas estadísticas también sobre NFCore, las publicaciones, el mentorship, las sesiones estas de mentorship, que están pasando también son financiadas por Chan Zuckerberg y es una oportunidad bastante interesante para aprender. Se trata de parejas de mentores y mentorados donde trabajan durante un tiempo en algún proyecto y aprenden a usar o desarrollar pipelines. Luego hay también el código de conducta y cómo unirse a NFCore, que voy a repasar otra vez, anima a los que usan Isla, que en el caso de que no estéis aún, también tenéis acceso al Githam, también tiene Twitter más todo. Para noticias y YouTube, que es donde se quedan grabadas normalmente las sesiones de las charlas de Bitesite o las sesiones de training. Este sería todo para web. Entonces vamos a usar la documentación de cómo crear una pipeline, crear una pipeline con NFCore. Y aquí veis que también podemos usar Github, igual que estuvimos usando ayer. Entonces mientras se carga Github, voy a enseñar también que en el caso de que queráis usar NFCore en local, NFCore es una herramienta de Python en donde se puede instalar con pip, pip install NFCore, lo podéis instalar en local. Y o en el caso de que queráis usar conda, también se puede instalar. Está el paquete de bioconda, lo podéis instalar con conda y usarlo también en local desde aquí. Hoy ya tenemos nuestra tip pot preparado, que es lo que vamos a estar usando. Esto igual que ayer se fue de cerrar. Está ahora instalando todo lo necesario para NFCore. Entonces lo primero que vamos a hacer ahora estamos en la carpeta dentro de tools, que es la que contiene todo el código de NFCore. Lo que voy a querer es salir de esta carpeta y crear una carpeta de training que es en la que vamos a estar trabajando hoy. Para poder verla aquí en el explorador de ficheros, ahora vemos tools. Podemos ir aquí a estas tres líneas de arriba a la izquierda y vamos a ir a las tres líneas, finds y open folder para abrir nuestra carpeta que hemos creado, training. Vale, ahora vemos que aquí en el explorador ya vemos que estamos dentro de la carpeta de training, que es la donde vamos a estar trabajando. Exacto, ahora estamos movido dentro de la carpeta de training. Que es lo que vemos aquí, ahora no hay ningún fichero ni tenemos nada aún. Dentro de kitfor, tenemos todo lo que vamos a necesitar, tenemos nextflow disponible en la versión en este caso 22.10.1 y NFCore disponible en la versión a 2.7.2. Ahora. Vale, tenemos la versión 2.7.2 que se da con las guiones y version o con guión V como bien hecho. Entonces, si correis NFCore solo o NFCore help, vais a obtener este mensaje de ayuda que lista todas las opciones, todas las opciones de NFCore y los comandos que se pueden usar y luego separados por comandos para usuarios y comandos para desarrolladores. Entonces, vamos a empezar por los comandos por usuarios en la sección de cómo usar NFCore para usuarios. Y vamos a ver el primero que es NFCore list y nos hará una lista de todas las pipelines disponibles en NFCore. Entonces aquí veis todas las pipelines disponibles con su información. El nombre de la pipeline, las veces que ha sido marcada como favorita, la versión actual. Cuando ha sido, cuando ha habido una release de esta última versión, ya veis que es bastante activo. Por ejemplo, tres horas antes Mac ha tenido la nueva versión 2.3.0. Luego tenemos cuando usamos o cuando nos descargamos una pipeline de NFCore se va a guardar en nuestro tenedor para que no tengamos que acceder a descargarla cada vez. Entonces aquí tendremos también un registro de cuándo es la última vez que hemos hecho un pull y si tenemos la última versión o no. Tenen en cuenta que en el caso de que haya una nueva versión tendremos que volver a hacer un pull para actualizar y usar esta nueva versión. Entonces vamos a probar con next loop pull para obtener, para descargarnos una pipeline de NFCore. Es una pipeline de NFCore que vamos a coger de GitHub. Entonces podemos el nombre de la organización y vamos a usar, por ejemplo, Mac que está primero que hemos visto aquí. Si ha descargado desde GitHub, como veis, desde este enlace y si volvemos a usar list, veremos que nos ha aparecido la información. La última vez que se ha hecho un pull es ahora. Tenemos la última versión que es la 2.3.0. También podemos, igual que vimos en la sesión 1, que podemos acceder a diferentes ejecutar diferentes versiones. Una pipeline con una revision, con yr. Podemos hacer lo mismo aquí y, por ejemplo, la versión anterior, una versión 2.0.0. Volvemos a hacer list y vemos aquí que ahora no estamos usando la última versión, sino que tenemos la 2.0.0. La última vez que hemos hecho un pull es hace 55 segurtos. Para volver atrás y tener la última versión, podemos usar Master, ya que este es el nombre de la rama de la branch en GitHub. Y veremos ahora que hemos vuelto atrás y tenemos efectivamente la última versión 2.3.0. Para ejecutar una pipeline, no es necesario hacer un pull primero, sino que podemos directamente ejecutarla y esto va a hacer el pull automáticamente y guardar esta versión en nuestro retainador. Entonces, vamos a probar esto. Luego entrarán para ejecutar la pipeline. Vamos a usar otra, por ejemplo, RNA-seq de nascor. Y la voy a intentar ejecutar con profile. Y le tengo que dar una parqueta de output. Esto no pasa en todas las pipelines, pero en el caso de RNA-seq sí que es obligatoria de darle el nombre de la carpeta de output. Entonces, esto va a empezar a ejecutarse. Como veis, está haciendo el pull de nascor RNA-seq. De hecho, si intentamos ver mientras está pasando esto y intentamos hacer list, ahora cuando haya acabado de descargar, aquí hemos tenido un error, ya que profile es un argumento de nextLum, entonces va con un solo guión. Pero aquí deberíamos encontrar a RNA-seq que la hagamos sin necesidad de hacer nosotros el pull solo contra. Y ya tenemos la versión 3.10.0. Ahora sí que se ha empezado a ejecutar la pipeline. Siempre que ejecutamos una pipeline de nascor, tendremos aquí el logo con la versión que estamos ejecutando ahora mismo. También imprime los principales parámetros de esta pipeline. Por ejemplo, cuál es el input. Ahora vamos a ver de esto. Cual es el auto que hemos proporcionado los results a diferentes ficheros que están tan bien, si han sido proporcionados. Y luego, como vimos en la sesión 1-1, lista todos los procesos de esta pipeline y se van ejecutando. Mientras esto va a tardar un poco, mientras tanto vamos a ver qué es profil que hemos proporcionado aquí muchos procesos. Bueno, y nos acordamos del comando. Lo que estamos haciendo aquí, este es el comando que habíamos ejecutado en esta otra terminal. Lo que estamos haciendo aquí es definir un perfil que veremos también más profundamente cómo podemos definir un perfil. Aquí le estamos diciendo que vamos a usar docker. Está ya instalado nuestro kitpot, es decir, que todo el software que necesitemos para la pipeline va a usar containers de docker. Y luego le estamos dando un otro perfil. Se pueden proporcionar más de un perfil separados por comas. En este caso, estamos usando test. Todas las pipelines vienen con un perfil de test, que es unos datos pequeños para poder probar que la pipeline funcione. Entonces, ya automáticamente esto le da todos los input necesarios para ejecutar este test. Lo que vamos a hacer ahora... Bueno, esto también podríamos usar igual que antes, no también una revision para correr una versión diferente, una versión más antigua, en el caso de que queramos. No vamos a ejecutar nada más. Ahora vamos a esperar a ver si termina nuestra pipeline. Mientras tanto, lo que vamos a ver, vamos a ir a la página web de NFCOL. Vamos a buscar rnsc. Y podemos ver su código. Vale, como veis, esta es la estructura general de una pipeline, todos los documentos que tiene. Tiene una carpeta de configuración que es donde guardamos todos los ficheles de configuración que podemos proporcionarle a la pipeline por defecto. Entonces, voy a ir, tengo aquí la documentación de nexlo. Nexlo.io para docs. Entonces, voy a ir a configuración. Como estuvimos viendo, podemos proporcionarle a la pipeline diferentes parámetros para definir pues como se llama la carpeta de output o el input que le vamos a dar o otras opciones para configurar cómo se ejecuta esta pipeline. Eso es importante porque en el caso de que queremos tunear un poco o ejecutar la pipeline para hacer un tipo de análisis un poco diferente, no hace falta que tengamos otra pipeline diferente o que vayamos a modificar el código, sino que con los parámetros que hay disponibles, que los desarrolladores han habilitado, podemos configurar a nuestra manera cómo queremos que se ejecute esta pipeline. Entonces, para proporcionar estos parámetros existe una jerarquía. En primer lugar, los que tienen menos prioridad son los parámetros que están definidos en un script. Luego tendremos ficheles de configuración, los que pasamos a través de el comando de ejecución de nextload run con guión C, los otros que podemos proporcionar a través de un fichero de parámetros y finalmente los que proporcionamos en el comando nextload run con dos guiones y el nombre de nuestro parámetro. Estos son los que van a sobrescribir todos los demás y tienen prioridad. Entonces, estos ficheles de configuración que tenemos aquí, primero tenemos base config, que es como una configuración básica. Aquí tenemos siempre por defecto la memoria, las TPUs que va a usar nuestra pipeline. También tenemos aquí cada proceso puede tener una etiqueta. En este caso hay por defecto definidos estas process single, process low, process medium, high y algunas más que definen los recursos que son asignados a cada uno de estos procesos con estas etiquetas. Y bueno, como veis, hay bastantes bastantes, dependiendo de las necesidades de cada proceso, pues habrá unas condiciones diferentes. Luego también tenemos iGNOMS. NFCore tiene también disponible iGNOMS que, usando iGNOMS para gestionar las referencias. Entonces, todos estos que nomas están disponibles para usar como referencias están almacenados en la Lube de Amazon. Entonces, están directamente disponibles para los pipelines de NFCore y se pueden usar pasando los parámetros. Por ejemplo, tenemos algunos genomos humanos, diferentes ficheles que podemos necesitar como FASTA, index de alineamiento. Hay bastantes ficheles que se pueden usar como referencias. Luego tenemos MODULS config. En este caso veis aquí que tenemos withname y un nombre. Estos son los parámetros definidos para cada módulo, para cada proceso. Con este withname estamos definiendo que el proceso que tiene el nombre sample check y le estamos pasando, en este caso, pues la carpeta donde se van a almacenar los resultados del publishdir, le estamos especificando aquí algunos otros módulos si nos buscamos. Por ejemplo, aquí tiene también definidos argumentos extra que le estamos pasando a la reminta de este módulo. Por ejemplo, este módulo que se llama GGF-READ tiene argumentos extra. Esto dependiendo de la reminta del software que esté ejecutando este módulo. Y luego finalmente tenemos TEST config y TESTful. Bueno, vamos a empezar con TESTconfig. En este caso, lo que vemos es que tenemos definido por parámetros. Los parámetros, digamos que se pueden definir con la palabra clave PARAMS, seguido de un punto y el nombre o en el caso de querer definir muchos, vamos a utilizar los clodators para incluir dentro de esta sección todos los parámetros que queremos definir. Entonces, cuando estamos usando el perfil que hemos usado antes, NextLore and ProfileTest, lo que le estamos diciendo es que utilice este fichero de documentación test.config. Y aquí tienes definido todos los parámetros necesarios para ejecutar los tests. Por ejemplo, tiene definido las CPU, las memorias. También tiene un fichero de input que está almacenado en GitHub. Lo podemos ver aquí. En este caso nos especifica el nombre de la muestra, los ficheros que va a analizar. Luego, también tenemos las referencias que son también ficheros almacenados en GitHub y otros ficheros, otros parámetros que necesita la pipeline para poder ejecutarse y para poder correr estos tests. Del mismo modo, tenemos TestFull. Esto, si os acordáis cuando hemos visto la página web que tenemos aquí resultados y he dicho que son, nos enseñan los resultados cada vez que hay una nueva versión, se ejecutan unos tests con tamaño real de datos. Aquí vemos los resultados y aquí vemos el fichero de configuración, que es el que se ejecuta con el perfil TestFull que corre estos tests en tamaño real. Pues también tiene su input, digamos, un genoma y en este caso pues el tipo de programa que vamos a usar para el alineamiento. Ha dicho esto. Bueno, ha habido un error. No es tan poco demasiado importante para este caso, simplemente vemos pues que muchos procesos sí que se han ejecutado, la pipeline se ha ido ejecutando, finalmente ha fallado por un tipo de error. ¿Qué vamos a obviar por el momento? Ya que no se influyen lo que queremos explicar aquí. Bien, el siguiente comando que vamos a ver es NFCoreLunch que nos ayuda con una interfície gráfica o a través de también de la terminal lo podemos hacer a modificar o crear un un fichero de configuración para correr la pipeline con los parámetros que nosotros queremos usar. Entonces vamos a usarlo. Por ejemplo, seguimos usando el Macy. Queremos usar. Voy a usar ahora otra versión, por ejemplo, de 2.10 y podemos decir que vamos a usar comandline o vamos a abrir una interfície gráfica en web. Desde aquí, desde Gitpod no se abre directamente, es porque estamos dentro de la entorno de Gitpod. Pero lo que sí que podemos hacer es abrir este enlace en que nos aparece aquí y vemos la página que se hubiera abierto directamente si estuvieramos en una terminal normal del local. Se abre la página de Launch Pipeline. Nos dice la pipeline que estamos. Ahora vamos a modificar una ID que le ha asignado la versión que hemos seleccionado antes y vemos aquí todos los posibles opciones, parámetros que podemos proporcionar a la a la pipeline que estamos corriendo. Esto nos ayuda a crear un fichero con parámetros que luego podemos usar para ejecutar esta pipeline y además para que sea también reproducible y diferentes usuarios no hayan de introducir a mano cada uno de los parámetros, sino que con este fichero sabremos cómo hemos hecho este análisis en concreto y podremos repetirlo otra vez dando este mismo fichero. Por ejemplo, aquí podemos usar igual que Amplest, profile, perfil, test docker. Véis que tenéis siempre una explicación del tipo de parámetro, el parámetro que tenemos que dar, el input que normalmente lo daríamos, pero como hemos usado test y hemos visto esto y es automático, a que le hemos dicho cuidar resultados también tenéis más información para ver un poco de información más extendida sobre algunos de los parámetros y por ejemplo voy a dar, voy a marcar algunas de estas opciones solo para el ejemplo para el que cambia un poco. Bueno, aquí podríamos ir especificando diferentes, también están separados por grupo. Una vez hayamos modificado todos nuestros, las opciones que queramos, como veis por defecto las opciones suelen estar siempre, digamos, apagadas o en false para que nosotros seamos... el análisis básico es siempre sin opciones extras y nosotros podemos activarlas pasando el parámetro a través de el comando o bien con ficheros de configuración. Una vez hemos terminado vamos a hacer click a launch este botón de aquí y si tuviéramos aquí aún abierto el comando nos aparecería pero como no es el caso porque estamos en gilpot zoom aquí que no me deja clicar. Una opción sería copiar esto, esto de lo que como veis hemos marcado algunos parámetros en true y nos aparecen aquí que los hemos cambiado del por defecto. Podríamos copiar esto y guardarlo en un fichero nfparams.json o el nombre que quisiamos y proporcionar este fichero a través de guion params file es así nos vamos otra vez a la documentación de nextflow. Vemos que es aquí esa opción de aquí. Menos prioritaria que pasar los parámetros a través de command line de nuestro comando de ejecución pero más prioritario va a sobre escribir todos los otros métodos. Entonces otra opción también que tenemos es usar copiar este comando de aquí con el id que es el que habíamos visto que le ha asignado a la sesión que hemos hecho y probar de ejecutar. Queremos ejecutar este comando si ese es el comando que se va a ejecutar. Nextflow run nfcorrnac con la versión 3.desk con el perfil test docker y params file nfguion params.json que como veis se ha creado aquí. Vamos a decir que sí y como veis aquí tenemos algunos de los parámetros que han cambiado. Podemos también ver ahora que ya se está ejecutando que se ha creado este fichero aquí entonces este es el fichero que podríamos guardar para así en el caso de que queramos repetir el análisis de la misma forma que lo hemos hecho esta vez. Y otra vez pues está ejecutando la pipeline. Vale, vamos a seguir. Vamos a ir a nfcorrn, en este caso a GitHub. Una cosa que podéis hacer en nfcorr es tener ficheros de configuración. Por ejemplo, en el caso de que forméis parte de una institución que uséis un cluster común con varios usuarios podéis definir unos ficheros de configuración para para definir los parámetros que necesitéis para ejecutar esta pipeline en vuestro cluster y siempre hacerlo de la misma forma. Por ejemplo, definiendo el máximo de memoria que podéis usar o el máximo de CPUs que podéis usar. Entonces todos los usuarios de este mismo sistema pueden usar este mismo fichero de configuración y corregir las pipelines de la misma forma. Podéis contribuir si vais a nfcorr, este es el GitHub general de nfcorr con varios repositorios para cada pipeline. Ahora estábamos en rnsc, ahora estoy buscando configs que es donde tenemos estos ficheros. Aquí tenéis la documentación, podéis echarle un vistazo más en detalle en el caso de que, si hay vuestro caso y lo queráis usar, podéis contribuir la comunidad a aceptar, a revisar vuestro fichero de configuración, aceptarlo y añadirlo aquí, entonces todos los usuarios pueden usarlo de forma automática. Bueno, vamos a abordar esto porque tampoco nos interesa ver los resultados. Podríamos ejecutar. Por ejemplo, con un perfil disponible aquí, que es cri, que es un instituto que tiene su perfil aquí puesto, vamos a usar de ejemplo. Esta hora va a fallar porque no hemos dado ni input ni nada, solo es para comprobar que le pudimos pasar otro perfil. Debemos usar la misma versión que estamos usando antes o especificar la nueva versión. Eso es porque no es la última versión disponible. Entonces estamos usando el fichero de configuración de este instituto y deberíamos ver algunos de los parámetros. Aquí como veis, por ejemplo, pues hay una definición de la institución de los parámetros que ellos han proporcionado y sus especificaciones, diferente información que pueden necesitar. Otra opción, estos irían ficheros con un perfil. Otras opciones son crear ficheros como nexlo.config, pero configurables y entonces pasarlos a través de guión C. Todas estas opciones las podéis revisar. También es la mejor importante definir que si vamos aquí a scopes teníamos, por ejemplo, vamos a ver profil, proces, perdón. Dentro del scope, un scope está definido por los cloudators. Usamos la palabra clave y tenemos, pues, por ejemplo, el ejecutor, la cola donde vamos a querer que los diferentes jobs o tareas de trabajos se lanten y se questionen. Aquí otra vez podemos definir CPUs, memoria. Como veis, también tenemos lo que hemos visto antes, el scope params que habíamos definido parámetros con params, punto y el nombre, o también en scope entre cloudators con el nombre del parámetro. Y así podemos solucionar más de uno dentro de este mismo scope. Como veis, hay muchos. Esto es devenido de lo que necesitéis. Puede revisar la documentación y ver las opciones que hay disponibles. Otro cosa que podemos hacer, vamos a ver otra vez el help. En el caso de estar ejecutando nuestras pipelines o nuestros análisis en, por ejemplo, un cluster que no tiene acceso a internet, esto a veces puede suceder. Todas las pipelines de netcore pueden ejecutarse offline. Lo que tendremos que hacer es descargarla con nfcomdownload. Esto sí que va a necesitar acceso a internet, pero una vez tengamos esta, esta, esta descarga, ya no necesitaremos conexión para hacer nuestros análisis. Entonces, como veis, esto va a descargar la pipeline, los ficheros de configuración y también las imágenes, en este caso en singularity. Las imágenes necesarias para todo el software y todas las dependencias que necesitemos para esta pipeline. Vamos a probarlo en nfcomdownload. Podemos escoger la pipeline que queremos descargar, la versión que queremos descargar y, como veis, nos pregunta, queremos descargar los containers de software, podemos decir que no, o descargarlos en singularity y luego nos permite definir una carpeta en singularity catchable que es donde se van a guardar estas imágenes. Si las guardamos aquí, vamos a decirle que sí. Diferentes usuarios que usen este mismo cluster podrán tener acceso a esta carpeta y entonces no hace falta descargar las imágenes de singularity cada vez para cada usuario, sino que todos pueden usarla, la misma, las mismas. Vamos a decir que se descarguen aquí en training, en la misma carpeta donde estamos, esto en singular puse a definir la carpeta donde conseguiréis que se den descargar. Y luego se puede añadir al bashrc donde podemos guardar para que no tengamos que definir esta variable siempre, sino que ya la tendremos exportada. Y luego, pues, dependiendo de la preferencia, se puede descargar, comprimir, sin comprimir o comprimir en diferentes formatos. Aquí nos dice, pues, la pipeline que está descargando y, como veis, pues va descargando todas las imágenes que ahora, pues, ya se van creando. Aquí todas las imágenes de singularity que vamos a necesitar. Como no vamos a correr esto ahora, vamos a abortar también otra vez. Vale, pues, esto sería todo por la parte de usuarios, de NFCore como usuario. Ahora vamos, hacemos una pequeña pausa y vamos a continuar con NFCore para desarrolladores. Y vamos a ver los diferentes comandos de NFCore para desarrolladores que nos ayudan a programar nuestras platforms. Vamos a empezar, pues, con los comandos de NFCore para desarrolladores. Lo que he hecho antes de empezar es crear, igual que había creado una carpeta de training, crear una carpeta nueva training-goos para tener el espacio más libre. Entonces, vamos a usar por el primer comando create, que es el que nos va a ayudar a crear una nueva pipeline desde cero usando una template, una planta. Entonces, lo que voy a hacer es cortar este comando. Lo primero que nos indica es que le demos un nombre a nuestra nueva workflow, que vamos a llamar demo, que añadamos una descripción, puede ser una descripción de lo que hace la pipeline. La pipeline y el autor, pues, que somos los dos. Aquí nos dice si queremos customizar qué partes de la plantilla queremos usar, vamos a decirle que no, aunque sepáis que se puede customizar algunas partes se pueden eliminar. En este caso vamos a usar la plantilla estándar. Y aquí veis que se ha creado una nueva pipeline. La vemos aquí. El nombre de la carpeta es NFCore demo. Siempre se va a crear con el prefico NFCore y el nombre que le hemos dado. Y aquí tenemos información de unirnos a la comunidad. Directamente, gracias a la template y el comando que crea esta nueva pipeline, también tenemos integrada un control de versiones con Git. Entonces podríamos hacer Git status. Ahora mismo, bueno, nos dice que estamos en la branch en Rama Master y que como no hemos modificado nada, pues no hay nada que subir, pero que sepáis que directamente ya tenemos este Git implementado aquí. Lo que vamos a hacer es ver las diferentes branch que tenemos. Siempre tendremos disponible Master y Dep. Dep sería la rama de desarrollo y Master es donde vamos a hacer la release para sacar las versiones, las nuevas versiones de la pipeline. Luego también tenemos esta rama template que esta es la que nosotros no vamos a tener que modificar nunca, pero es la que recibe las actualizaciones de la plantilla. Como ya dije, cuando hay nuevas funcionalidades de Nexlo o cuando NFCore decide pues que hay algún cambio que va mejor, alguna actualización. Normalmente, es decir, va en consonancia con la versión de NFCore Tools, tendremos los cambios, los podremos aplicar directamente gracias a esta rama template y nos permite pues fácilmente aplicar estos cambios en nuestra pipeline. También para que veáis que nada que tengamos una nueva pipeline en un repositorio de GitHub, podemos ejecutarla si la tenemos aquí. Es decir, ahora vamos a ver. Nexlo Run es salido de la carpeta de la pipeline, es decir, está aquí mi pipeline. Por ejemplo, test, rocker igual que haciemos, maudir, le vamos a llamar de Souls otra vez. Como veis, esta pipeline se está ejecutando, aunque no esté subida a GitHub, pues Nexlo lo que hace primero es ver si hay, si tenemos una pipeline con este nombre en local. Entonces se va a ejecutar en local. Y veis, ya nos dice aquí. Projectir la carpeta del proyecto es esta. Estamos usando test. Vale. Mientras tanto, pues si vais aquí, veis aquí para navegar dentro de nuestra carpeta de la pipeline. Estos son todos los ficheros que ya se han creado con la template. Gracias a la template, por ejemplo, veis a configuración. Tienen los mismos que estuvimos viendo, que tenía R&C. También tenéis, bueno, iremos viendo ahora también más profundamente los diferentes documentos que se crean. Por ejemplo, hemos usado profil test. Si miramos, pues vemos que tenemos también directamente implementado los datos básicos para correr un test, es decir, que esa primera pipeline que se crea a través de la plantilla ya es ejecutable y ya se puede empezar a se puede probar. Y para así poder ir probando todos los cambios, todos los modificaciones que vayamos haciendo. Lo que también tenemos las carpetas de módulos como veis aquí. Ahora también vamos a explicar un poco más en detalle y sobre todo durante la sesión tres veremos más sobre módulos y subplot flows. Pero que veáis que la pipeline tiene ya integrados módulos, por ejemplo. Los módulos pueden estar divididos en local, si es que los hemos creado nosotros para nuestra pipeline o en esta carpeta NFCore, si es que los hemos cogido del repositorio común de NFCore. Y luego todos los módulos tienen, como veis, es un proceso, un módulo, es un proceso y tienen el código que va a ejecutar la tarea. En este caso va a ejecutar el programa FastQC. Perfecto, pues ya terminado. Ahora nuestra pipeline de test ya se ha ejecutado. Y lo que decía, que simplemente con la plantilla básica sin necesidad de necesidad de que hayamos modificado nada, tendremos ya una pipeline que se puede ejecutar. Entonces la parte de los módulos y las subplot flows que serían los componentes de nuestra workflow. Vamos dentro de la carpeta de workflows y tenemos aquí nuestro fichero principal de Nexlo, el fichero de la workflow que recibe el nombre que le hemos dado a nuestro workflow, demo en este caso. Y como veis, ya tiene bastante código que no vamos a ir ahora en detalle, pero tiene las líneas que incluyen los módulos que estamos usando. Con Include en Nexlo podemos incluir los módulos desde este path. En este caso FastQC es el que estábamos viendo ahora, es decir, desde fuera de workflows en modules NFCore, FastQC main.nf está incluyendo el módulo FastQC y luego dentro de nuestra workflow que habíamos dicho que es la conjunción de procesos unidos por canales, vamos usando los módulos que hemos importado. Por ejemplo, en este caso FastQC lo usamos y aquí tendríamos, este es la workflow básica de esta pipeline. También ahora que ha terminado de correr, igual que pasaba antes, sino que aquí ha creado una carpeta Work que contiene las carpetas para cada tarea que sea ejecutado. Y luego también ha creado una carpeta de resultados divididos en este caso en función del módulo, cada módulo tiene los hechillos de resultado y aquí podríamos ver todos los resultados de esta pipeline y información que también forma parte de los resultados. Vamos a ver los siguientes, los siguientes comandos que podemos utilizar. Tenemos aquí lint. Lint hace linting. Linting es una palabra ingresa que usamos para, es decir, linting es todo lo que hace, revisa que estemos siguiendo el código de conducta o las guías de programación de NFCore y también pues que nuestro código sea entendible, que sea fácil de leer y que siga estas guías para que cualquier persona que quiera contribuir les sea más fácil poder entender el código y poder contribuir. Es decir, que lo hace todo bastante estándar, que el código siga estos standards. Vamos a ver este comando. Tenemos que ir dentro de nuestra pipeline y ejecutamos NFCore lint. Cuando ejecutamos este comando NFCore lint que hace el linting de la pipeline, siempre tenemos esta tabla de resumen de los resultados. Como veis, pues miramos varias cosas y hay varios test. Aquí pues han pasado 180. Tenemos 22 warnings, 22 avistos y ninguno ha fallado. Por ejemplo, tenemos primero los warnings. Aquí tenemos la mayoría, ya veis que son que tenemos strings de todo. Eso es porque en la template, en la plantilla, hay algunas frases, algunas líneas, comentarios de todos, de cosas por hacer cosas que debemos cambiar para recordarnos y hacernos más fácil y guiarnos más en el proceso de programación de nuestra pipeline. Entonces, podemos ir haciendo todas las tarías que nos indican estos dos. Como como un apunte podéis ir a este árbol de aquí que sale en Visual Studio Code, que se llama ToDoos. Y aquí os va a aparecer dentro de la carpeta los ficheros que tienen ToDoos y os puede llevar directamente a la línea que contiene un ToDoo. Entonces, es más fácil poder seguir y ir viendo todas las cosas que deberíais de modificar. Y luego también tenemos otro warning que nos dice que nuestro módulo multiQC no está actualizado. Es decir, tenemos una versión más antigua y existe una versión nueva. Otra cosa que están mirando estos stats que ahora mismo están pasando porque no hemos modificado la pipeline es que los ficheros más importantes y para ver los ficheros de nuestra pipeline, los ficheros más importantes no se hayan cambiado. Entonces, para ver la documentación del LinkedIn, podemos ir a la página web de NFCore dentro de tools. Encontraremos, si bajamos un poco, toolspytonsapidocs de la última versión de tools. Y aquí veis que tenemos lintest para pipelines para módulos y documentación de la pipeline. Entonces, vamos a ver el de los test de la pipeline. Y como he dicho, estamos mirando. Bueno, estos son todos los test del LinkedIn que se van ejecutando. Tenemos este de ficheros que no han cambiado. Todos estos ficheros son los que vienen con la template y que son importantes mantener en el mismo formato que la template y que no cambien. Por ejemplo, pues el código de conducta. Vamos a ir aquí, vamos a buscar el código de conducta que ahora mismo tiene las instrucciones de cómo comproterse en el ficher. Imaginamos que queremos cambiar aquí. Si quisiéramos cambiar este fichero y volvemos a ejecutar LinkedIn, vamos a ver que ahora tenemos un test que ha fallado. Bueno, aquí nos dice, código de conducta.md no es igual a la template que indica pues que no puede no puede ser cambiado. También como apunte, aquí tenéis los enlaces que en principio clicando control o comand no deberían de llevar a la documentación esta que hemos visto. Para sí tenemos este tipo de errores que sepamos que podamos ver la documentación de cómo podemos solucionar este error. Y como veis también nos sugiere algún comando que para poder arreglar algunos de los errores. No todos son solucionables automáticamente, pero hay algunos que sí. Bueno, claro, porque no lo voy a probar ahora porque como no hemos guardado, no hemos hecho un commit, no hemos añadido estos cambios a kit o el punto de versiones. No se pueden modificar. Pero que voy a hacer es ir atrás para que sea no modificado y no nos salga este error más. Aunque no es recomendable porque todos los ficheros que no queremos que sean cambiados deberían no ser cambiados, es posible eliminar alguno de estos checks, alguna de estas comprobaciones. Eso lo podemos hacer en el fichero llamado punto enlaces, punto llamas. Este fichero por defecto tiene, siempre tendrá el tipo de repusitorio, si es una pipeline, siempre tendrá esta línea. Entonces aquí podemos añadir, voy a cubrir el código para ir un poco más rápido. Como habéis añadido aquí las líneas lint, hemos puesto que todos los pipeline to dos a false, es decir que no me los enseñe en el cuando haga el linty y que los ficheros que no han cambiado también vamos a evitar comprobar el code of conduct. Lo voy a modificar otra vez porque lo había vuelto a cambiar y esto perdón es una lista. Entonces voy a volver a ejecutar el linty de nuestra pipeline. Sí, como veis tenían indentación extra. Entonces ahora ya no nos aparecen todos los to dos, los warnings de los to dos y tampoco que el fichero no debería ser cambiado, pero nos avisa de que algunos test han sido ignorados, como por ejemplo el de los dos que han cambiado que los to dos y el fichero que estamos ignorando y también nos aparece aquí a la tabla que dos test han sido ignorados. Otra cosa que usamos relacionada con linting es usar pretier. Pretier es un software que se usa para comprobar la calidad y la lectura del código. Comprueba el formato del código, es decir que con nfcore lint miramos más la estructura de cómo debe ser la pipeline o de que siga los estantes de nfcore. Con pretier miramos la calidad del código. Podemos usar pretier se que es de check y en toda la carpeta, esto donde estamos, que es la carpeta de la pipeline. Y como veis pues hace una comprobación de que todos los ficheros siguen en los estilos de código correctos. Eso cuando hagáis modificaciones al hacer PRs, pull requests en GitHub, en el GitHub de nfcore, directamente también se corren todos estos test de linting y también se usa pretier para comprobar que todo está siguiendo los estandares necesarios. Es decir que aunque no hagáis las comprobaciones aquí se harán igualmente en GitHub, entonces está bien pues probarlo primero en local para comprobar que todo está funcionando. Vamos a intentar hacer que pretier falle. Por ejemplo voy a abrir el fichero de ritmi que es el que tiene toda la, perdón, el change look, que es donde revisamos los cambios que vamos implementando en nuestra pipeline. Entonces lo que voy a hacer es eliminar este salto de línea entre los títulos y el texto y voy a volver a correr pretier otra vez. Como veis nos dice el fichero change look tiene algunos problemas de estilo de código. Lo que podemos hacer, dice obvio, has olvidado de correr pretier, si es el caso. Lo que podemos hacer es ejecutar pretier en lugar de con la ct check para comprobar con la wd write para escribir y modificar y arreglar nuestro código. Como veis la mirando todos los ficheros y cuando es necesario pues ha hecho el cambio que necesitaba y que hacía fallar este test. Otra herramienta que usamos también para comprobar la calidad del código de Python es por ejemplo black. Nos dice que había dos ficheros de Python que los ha encontrado y que están bien, que siguen los los standards. Funciona un poco igual, bastante igual que pretier. Es decir, si encontrará ficheros que no están bien nos avisaría para que podíamos arreglarlos. Vale, ahora lo que vamos a ver, ya podemos ir cerrando este código, es nuestro fichero nextloschema.json. Este documento de JSON contiene todos los parámetros de nuestra pipeline. Se usa para validar que cuando un usuario que ejecuta la pipeline introduce un nuevo parámetro, por ejemplo, aquí tenemos Outdoor que siempre lo estamos proporcionando cuando ejecutamos una pipeline, para asegurar que tiene el formato correcto. Es decir, por ejemplo, aquí nos dice que Outdoor debe ser un Stree, también nos da información, descripción. Nos dice que es un pad de una carpeta. También podríamos tener, por ejemplo, este otro tiene un patrón que es una expresión regular para asegurar que sigue el patrón que necesita para asegurar que es correcto el parámetro. Además, también se usa para la documentación que vimos en la página web que nos explicaba todos los parámetros de una pipeline. Entonces cada vez que añadamos a nuestra pipeline un nuevo parámetro que los usuarios pueden usar, debemos añadirlo aquí en el nextloschema. Como veis, este fichero es bastante grande y bastante complicado de modificar a mano. Entonces, en FCOR lo que tiene es herramientas que nos facilitan modificar este fichero automáticamente. Entonces, lo que vamos a hacer es añadir aquí en este fichero nuevos parámetros de nuestra pipeline en el fichero nextlos.config, que es el fichero de configuración. Como veis, todos los parámetros que ya vienen en la template están aquí como input, tendríamos Outdoor, todos los parámetros necesarios. Entonces, vamos a añadir dos nuevos parámetros. Voy a añadir par que es un Stree, y vamos a añadir el foo, que va a ser un número para ver más variedad. Entonces, lo que podemos hacer es usar el comando en FCOR schema. Y vais a ver que hay diferentes comandos que nos pueden ayudar. El que vamos a estar viendo ahora es el build, que es el que nos ayuda a construir este nextloschema. Primero está comprobando que los parámetros son correctos. Funciona bien. Y ahora dice, hemos encontrado nuevos parámetros que no están en el esquema. ¿Cómo paramos.var? Queremos añadirlo, sí, y paramos.foo también. Entonces, tenemos la opción de abrir un web en el browser para que nos ayude a editar el fichero con una superficie más agradable. Vamos a decir que sí. Otra vez dentro de GitPot no va a funcionar. Pero lo que podemos hacer es acceder a este enlace que nos aparece aquí. Abrimos el enlace. Y esta es la página que se nos abre. Lo que contiene esta página, que es para editar este esquema, veis que hay todos los parámetros que nos aparecen aquí y además están incluidos dentro de grupos para poder diferenciarlos. Por ejemplo, opciones de input y output, opciones referentes al genoma de referencia. Podemos añadir nuevos parámetros. Podemos también añadir grupos, modificar los grupos existentes. Y en cada parámetro tiene el ID, el nombre del parámetro. Le podemos poner un icono. Tiene también la descripción. Tiene, puede tener o no, mensajes de ayuda que expanden un poco más la descripción o ayuda de este parámetro. El tipo, el parámetro por defecto, si es necesario, obligatorio o no. Y si lo queríamos esconder al ver la documentación con help de la pipeline o no. Entonces vamos hacia abajo y vemos que aquí nos aparecen los nuevos dos, los nuevos dos parámetros que hemos añadido. En donde podríamos añadir una descripción. Aquí podríamos añadir más ayuda, y al haber añadido unos valores por defecto en nuestro documento, pues si nos añade dividido aquí también. Directamente ha visto que esto era un string, esto era un integer y nos ha añadido el valor por defecto. Pero esto lo podemos cambiar si es el caso. Entonces además también tenemos opciones extras en esta rueda. Por ejemplo, en el caso de string pueden tener, puede ser que opciones disponibles. Queremos tener hola o valio. Si estos van a ser los dos valores permitidos, también podemos darle una expresión regular para que siga este patrón. O finalmente al ser un string, pues si es un fichero o una o una carpeta, por ejemplo. Y lo mismo pues con otros tipos de variables al ser un integer, pues también podemos enumerar diferentes valores, poner mínimos y máximos. Y como he dicho, pues cambiar los iconos para que nos ayuden un poco más a saber qué es cada parámetro y añadirlo fácilmente podemos arrastrar, añadir los grupos. O si, por ejemplo, queremos crear un nuevo grupo, este nuevo grupo y añadir nuestros dos parámetros dentro de este grupo. Una vez hemos terminado, vamos aquí arriba a la derecha donde pone finish y decimos, vale, ya he terminado de editar los parámetros y nos dice, vale, si tenemos este comando ejecutándose se habrá creado, como es el caso, subjetándose en background, se habrá modificado automáticamente nuestro fichero nextflowschema.js. Si vamos bajando, aquí vemos que se ha creado nuestro nuevo grupo con el parámetro foo y el parámetro var con las opciones que leemos. Bueno, los acentos son un problema. Las opciones que habíamos modificado aquí, que queríamos solo odios, todas las modificaciones han quedado registradas. En el caso de que no te huyeremos el comando ejecutándose y no se cambia automáticamente, siempre podemos copiar el esquema y siempre podemos volver atrás para volver a editar y aquí también tenemos el esquema para copiarlo y pegarlo. Fichero en el caso de que no se haya abierto automáticamente y no se ha guardado. Vale, entonces, esos comandos para desarrolladores, hemos visto, perdón aquí, hemos visto cómo crear una pipeline, hemos visto cómo, como comprobar la calidad del código de la pipeline y de momento esto es todo, también hemos visto cómo crear el esquema, perdón, de momento esto es todo lo que vamos a ver sobre pipelines y lo que vamos a pasar a ver ahora son módulos y support flows, cómo crear módulos y cómo crear support flows. Hablaremos también más en detalle de algunas cosas que vais a necesitar para entender cómo funciona un módulo o una support flow, pero se lo veremos en la sesión 3. Entonces de momento solo vamos a ver algunos de los comandos. Entonces, vamos a empezar con los módulos y ejecutamos nfcore modules y vemos que tenemos varios comandos también respecto a los módulos. Por ejemplo, igual que vimos, igual que vimos en una lista de las diferentes pipelines, pues con nfcore modules list podemos ver una lista de los módulos. Aquí nos diferencia entre módulos que tenemos en local, es decir que los tenemos instalados en nuestra pipeline dentro de esta carpeta, modules o en remoto que vienen del repositorio de github de nfcore. Vamos a ver primero los que tenemos en local y nos aparece pues en nombre de los módulos que tenemos, que como vemos aquí dentro. Los que tenemos instalados son este custom dance of all version, fast use and multicruise. También vemos del repositorio desde donde se ha instalado, la versión y algunos menores mensajes y la fecha de la última edición. Y entonces también tenemos los módulos en remoto, que son todos los que tendríamos disponibles para instalar desde github de nfcore. Como veis, hay alrededor de 800 módulos ahora mismo disponibles, es decir que hay muchísimos software, muchos programas y tareas que ya están disponibles para usar directamente en vuestra pipeline sin necesidad de que tengáis que programar vuestro propio módulo. Vamos a ver uno de estos módulos, por ejemplo. Vamos a ver los comandos. Vale, si también podemos ver información de estos módulos. Nos pregunta, ¿es el módulo que está instalado localmente? Pues igual que hemos hecho antes y queremos ver los nuestros, le vamos a decir que sí y seleccionamos uno de nuestros módulos, por ejemplo, fast use y vemos la información que es la misma que teníamos en la página web, la herramienta que hemos descartado, sus inputs y sus outputs. Esto será más importante cuando queráis añadir este módulo y usarlo, saber cuáles son los inputs y cuáles son los outputs. Luego también podemos ver un módulo que no tengamos instalado, le decimos que no está instalado local y vamos a seleccionar un módulo, por ejemplo, fast use y como vemos no está instalado, pero nos dice dónde está disponible también sus inputs y sus outputs. Y nos añade también directamente el comando que podemos usar para instalarlo. También como otro apunte, como veis todos los módulos que hemos instalado desde NFCore se guardan en esta carpeta NFCore y aquí los tenemos todos, pero también dentro de módulos tenemos la carpeta local que serían módulos que hemos hecho que no están disponibles en el dipositorio, sino que los hemos creado sólo para esta pipeline y los hemos creado manualmente aquí, los diferenciamos en la carpeta local, pero como veis también es un proceso que funciona muy similar, bueno, tenía la misma estructura básicamente que un módulo de NFCore. Voy a abrir un momento nuestra pipeline, como ya os he dicho, pues los módulos una vez los instalamos los podemos incluir. Vamos a instalar este módulo, por ejemplo, que hemos visto con el comando de instalar, podríamos también darle ejecutar este comando sin darle el nombre y entonces nos lo pediría por pantalla o podemos también proporcionársela directamente. Entonces el módulo se ha instalado. Si vamos a ver la carpeta aquí de NFCore vemos que aparece nuestro nuevo módulo y siempre se va a copiar este fichero main.nf que es el que contiene la estructura del proceso con sus inputs, sus outputs y también se nos guarda el meta.yaml que contiene la documentación, esta es la información que nos aparece cuando usamos NFCore Models Info, es esta información y también la que vimos en la página web, se usa este fichero para construir la documentación, la información de este módulo. Entonces cuando hemos instalado el módulo también nos aparece la línea que necesitamos para incluirlo en nuestra pipeline, nuestra workflow. Aquí donde hay estos pues podemos directamente copiarlo y añadirlo. Include nuestro nuevo módulo FASQC desde su path modules NFCore FASQC main que teníamos aquí. Entonces qué más comandos tenemos para módulos. Vale, en el caso de que estéis creando módulos o incluso si si los tenéis aquí en vuestra pipeline, también tenemos el comando lint igual que teníamos NFCore lint para una pipeline. Tenemos NFCore Modules lint para un módulo. Podemos aplicar el linting en un módulo específico o todos los módulos. Ahora vamos a hacerlo todos porque no tenemos demasiados tampoco. Y como veis va pasando también unos test de calidad de código en los diferentes módulos que tenemos. Otra vez tenemos la misma tabla resumen. Tenemos 83 test que han pasado ninguno ha fallado y cinco warnings que básicamente nos dirán. Exacto, que por ejemplo en multi qc tenemos una nueva versión de la tool multi qc disponible en bioconda y nos indica que podríamos querer actualizarlo. Bueno, y aquí tenemos otras multi qc también nos dice que tiene una nueva versión en el repositorio de NFCore y otros warnings que no vamos a entrar en detalle, pero como veis pues hace diferentes checks en los módulos. Una cosa también importante para ver es este fichero que se llama modules.json. Este fichero nunca si tiene que modificar manualmente, sino que se va modificando automáticamente con los diferentes comandos de NFCore que lo necesitan y es el que lleva un registro de todos los módulos que tenemos instalados en nuestra pipeline de dónde provienen, de dónde se han instalado. Aquí veis que nos ha aparecido también el nuevo que acabamos de instalar ahora y su versión también tenemos aquí para controlar pues esto sí tenemos instalada la última versión que hay disponible en el repositorio o no. Entonces aquí pues como información de que esto es un registro de nuestros módulos de nuestra pipeline, aunque no necesitaremos nunca modificarlo manualmente. Vale, vamos a ver ahora ya que nos aparece este error de que multi qc tiene una versión más nueva. En el repositorio vamos a ver el comando de NFCore Modules Update. Este comando lo que va a hacer es actualizar nuestros módulos. También podemos darle uno en concreto o todos. Vamos a ver ahora qué pasa si los actualizamos todos y también tenéis diferentes opciones de solo ver las diferencias por ejemplo en el terminal o es guardar las diferencias en un fichero o directamente hacer un update de todo. Y como veis aquí pues ha ido mirando cada uno de nuestros módulos si ya estaban en la última versión y aquí multi qc ha encontrado que no lo estaba y por tanto lo ha lo actualizado y aquí ha cambiado la versión y luego nos dice que ya tenemos todo todo en orden. Si volvemos a utilizar NFCore Modules Link deberíamos ver que el último warning ha desaparecido. Efectivamente ahora todos los warnings que teníamos de multi qc ya no nos aparecen han sido solucionados con esta nueva versión. Más comandos que podemos usar sobre módulos en nuestra pipeline ahora que vamos a ver update tenemos remove en el caso de que haya un módulo que ya no queramos usar podemos eliminar. Por ejemplo vamos a borrar el último módulo que hemos instalado. Una cosa vez importante que nos ha pasado aquí es que antes habíamos añadido el include y nos está avisando estás a punto de eliminar este módulo pero tú lo tienes incluido. Igualmente lo quieres eliminar vamos a decir que sí y como veis pues ya ha desaparecido de nuestra carpeta de módulos también teóricamente ha desaparecido de nuestro fichero de control de módulos y pues manualmente deberíamos ir a abordar nuestro include statement porque ya no estamos usando este módulo. Otro comando muy bastante interesante que tenemos y el último es patch. Este comando lo que hace es que ahora estamos instalando módulos de este repositorio. Puede pasar que necesitemos hacer una pequeña modificación para adaptar este módulo que queremos usar el mismo con la misma herramienta pero hacerle una pequeña modificación para adaptarlo a cómo queremos usarlo en nuestra pipeline. Entonces en lugar de tener que volver a programar el mismo módulo lo que podemos hacer es hacer pequeños cambios y usar este comando patch. Lo que voy a hacer es abrir cualquier módulo y hacerlo un pequeño cambio por ejemplo añadirle un nuevo canal de que en este caso no tiene mucho sentido para esta herramienta pero vamos a imaginar que queremos añadirle pasarle un nuevo fichero que sea una referencia. Lo necesitamos para nuestra pipeline. Entonces hecho esta modificación si ahora si hacemos nfcore lint para ver un lint de nuestra pipeline vamos a ver un error. Aquí tenemos un test que falla y nos dice Faskey si la copia local que tenemos instalada no coincide con la copia del repositorio remoto y esto pues no se recomienda porque pierde al no saber los cambios que han pasado pues pierde un poco la trazabilidad del código. Lo que podemos hacer es usar como he dicho este comando para guardar estas diferencias. Y herramienta vamos a hacer el patch hemos dicho de Faskey si vale y lo que veis que ha pasado aquí es que nos ha enseñado las diferencias por ejemplo aquí pues le hemos añadido un nuevo canal de input pasando la referencia el hemos modificado fichero main.nf pero no meta.yaml y se ha creado este documento en dentro de la carpeta del módulo que nos ha aparecido aquí que contiene estas diferencias del fichero main.nf se ha añadido una nueva línea. Entonces una vez hemos ejecutado este patch tenemos un tracking un seguimiento de los cambios que han habido en el código si volvemos a hacer linting de la pipeline esto ya se detecta y efectivamente no tenemos ya el test que fallaba entonces como veis un comando bastante útil para poder aprovechar y reutilizar el código de los demás y tener este registro de cambios. Entonces hemos visto todos los comandos que podíamos usar para nuestra pipeline entonces como desarrolladores de módulos hay también otros comandos que podéis usar hemos visto ya linting para ver que estamos siguiendo los los estándares de código de nfcore y otra posibilidad que vamos a ver ahora es nfcore modules create. Entonces cuando está está ya desarrollando módulos normalmente vais a trabajar en una fork del repositorio de nfcore para querer añadir los módulos a nfcore dentro de una pipeline no podemos usar todos estos comandos estos los veremos más adelante en otras sesiones pero ahora lo que vamos a ver es que podemos también crear módulos dentro de una pipeline nuestro nuevo módulo se va a llamar foo y automáticamente va a buscar la herramienta el programa en este caso foo a ver si encuentra un contáiner de conta para poder ya introducir los contáineres directamente en este caso pues foo no existe queremos usar otro nombre diferente le voy a decir que si por ejemplo vamos a decirle que estamos usando samtools dentro de nuestro módulo foo vale como veis pues ha ido ha buscado los enlaces y el nombre de este contáiner de samtools y ha obtenido de diaconda este contáiner de docker esta dirección y de singularity esta otra dirección entonces ahora veremos donde están el módulo también nos pide nuestro usuario nuestro usuario de github para registrarnos como autores y finalmente que le pongamos un label una etiqueta le estuvimos viendo un poco en la sesión anterior hay diferentes etiquetas pues seleccionamos según la herramienta que estemos implementando pues el la memoria y los tpus que vamos a necesitar finalmente nos dice si queríamos un metamap esto no vamos a hablar de ello le voy a decir que si y de momento no nos vamos a parar a ver qué es entonces lo que hace cuando usamos create en una pipeline es crear un nuevo módulo dentro de la carpeta local no viene de enf core sino que lo hemos creado nosotros y está aquí en local y sólo crea este fichero full punto en f como veis hay mucho estudios para guiarnos también en como editar el módulo lo que no vamos a entrar ahora pero tiene pues su proceso con el nombre la etiqueta que le hemos dado y aquí es donde cuando usamos cuando usamos es next-low run profile y le indicamos conda docker singularity o algún otro gestor de containers pues va a usar estos containers de aquí que tenemos definidos en el módulo para conda y para docker singularity luego tiene los inputs los outputs y luego el script con algunas un poco más de código de gruvi y finalmente también nos crea por defecto un comando básico usando samtools que podéis modificar y aquí usar la herramienta que sea que queráis implementar vale perfecto entonces ahora no vamos a ver más de estos porque estamos centrados ahora dentro de una pipeline pero hay pues otros comandos como por ejemplo create es yaml que nos ayuda a crear test para nuestro módulo también para testear es decir para ejecutar los test si otros comandos que nos ayudan en la creación de módulos a parte de nf core modules aquí a parte de la ayuda para crear módulos también tenemos sub workflows en el core software las sub workflows son con funciones de diferentes módulos con sus canales pero más pequeñas que una workflow es decir también realizan una tarea específica lo que combinan varios módulos entonces les llamamos sub workflows y más o menos funcionan bastante igual que los módulos como veis también tenemos info por ejemplo o list vamos a empezar con list pues para ver primero si tenemos alguna sub workflow instalada en nuestra pipeline en este caso no tenemos ninguna de la sub workflows van en la carpeta igual tenemos módulos tenemos sub workflows de nf core no tenemos ninguna pero podemos ver las que hay disponibles las sub workflows se han añadido a nf core recientemente en el año anterior entonces hace menos de un año que están disponibles por eso hay menos que módulos pero como veis y hay algunas que se pueden se pueden usar lo que podemos hacer es ver también intuos por ejemplo bomb stat samtools voy a usar esta para ver su información y aquí pues muy similar a los módulos nos dice cuáles son los inputs cuáles son los outputs y el comando para instalarlo vamos a probar de instalar una sub workflow que hemos visto la información y como veis ahora nos ha instalado la sub workflow aquí dentro de nf core vemos bomb stat samtools con su main y su meta y amal igual que los módulos y la línea que deberíamos incluir para usarla funciona pues muy parecido nf core mod sub workflows pues aquí añadiríamos otra otra sección en nuestra pipeline para añadir nuestras sub workflows y luego usarlas en la página una cosa que quería enseñar es que esta sub workflow vamos a inspeccionarlas rápidamente como veis tiene el mismo formato que una workflow que realmente es es una workflow no lo que pasa es que es pequeña para realizar una tarea en específico también tiene include de diferentes módulos que va a estar usando esta sub workflow y no vamos tampoco a entrar muy en detalle en la estructura de este código pero como veis pues también usa tiene un input que se define en este caso con tech no vamos a entrar en detalle pero tiene un input usa sus módulos y luego emit que es para definir el output como veis pues usa en este caso tres módulos de samtools estos módulos no los teníamos instalados antes pero al instalar la sub workflow lo que ha basado es que automáticamente como veis nos han instalado aquí los tres módulos que esta sub workflow necesita eso pues si han instalado si automáticamente sin que tengamos que ir nosotros a ver cuáles son los necesarios entonces todas las dependencias ya las tenemos también instaladas automáticamente y podemos directamente a usar esta esa sub workflow en nuestra página como veis pues también tiene el meta punto ya mal que incluye los módulos y por lo mismo exactamente que los módulos con información sobre input que es lo que vemos en la documentación tanto en info como en la página web entonces pues de la misma forma tenemos info list instalamos visto también podríamos usar update para actualizar la sub workflow ahora pues como acabamos de instalar no instalarla no tenemos ninguna que no está actualizada y también tenemos remove para eliminarlas y lo que voy a hacer es eliminar esto porque no estamos usando y probar que se pueden a eliminar como veis pues se eliminaría la carpeta los módulos que estaban incluidos y nos dice todos los hicheros que que se han eliminado de la misma forma también tenemos un comando para crear sub workflows y para crear sus test y para ejecutar los test que tampoco lo vamos a ver aquí porque esto nuevamente lo querremos hacer en una fork del repositorio de nf core para contribuir con los workflows a nf core entonces llegamos al final de esta sesión dos sólo como resumen lo que hemos estado viendo es que nf core nos ayuda a crear nuestras pipelines tenemos a ejecutar también nuestras pipelines para ejecutar pipelines podemos listar todas las disponibles podemos crear hicheros de de configuración descargar una pipeline también y como creadores podemos crear pipelines hacer comprobaciones de de los del código y finalmente todos los módulos que hemos visto de todos los comandos perdón que hemos visto para instalar actualizar módulos y sub workflows y para poderlos usar en nuestra pipeline entonces esto sería todo gracias por ver la sesión dos seguiremos con la con la sesión tres mañana vamos a estar otra vez utilizando el tutorial de nexplow que utilizamos en la sesión uno y veremos conceptos como canales operadores y más sobre procesos vamos a ver estos conceptos de nexplow muchas gracias otra vez y hasta mañana