¡sourmash tiene una interfaz de complemento!

Durante las vacaciones, asumí un proyecto de “limpieza de paleta”, algo técnicamente genial, que no era de importancia crítica para nada ni nadie, pero que podría ser útil. Decidí implementar complementos para sourmash.

Sourmash es un software científico de código abierto para una exploración rápida y liviana de la comparación de conjuntos de datos de secuenciación, con un enfoque en la metagenómica. Es en gran parte un programa de línea de comandos escrito en Python sobre una biblioteca de Rust. Lo mantiene un pequeño grupo de desarrolladores, la mayoría de los cuales están (o estuvieron) afiliados de alguna manera a mi laboratorio académico en UC Davis.

Python tiene (lo que parece ser) un soporte sólido para complementos de terceros, donde un proyecto puede proporcionar ganchos para otra gente para personalizar la funcionalidad.

Entonces, la pregunta era, ¿podemos agregar compatibilidad con el complemento de Python a sourmash?

Primero, ¿por qué centrarse en los complementos?

Los complementos cumplen muchos propósitos para un proyecto, pero creo que la justificación más interesante para apoyarlos provino de Tim Head, quien canalizó sus observaciones de Simon Willison conjunto de datos proyecto en una declaración que los complementos son una forma alternativa de dirigir proyectos de código abierto. (Puedes leer todo el hilo de Twitter aquí.)

El tl; dr de Tim fue este:

“complementos de primera clase” es mi mejor respuesta actual a “necesitamos una hoja de ruta del proyecto”

¿Pero qué significa eso?

La idea central es que cuanto más extensible haga un proyecto con complementos, más fácil será para todos “jugar” con el proyecto, seguir sus propias direcciones y descubrir qué hacer a continuación.

O, para reformular: si enfoca sus esfuerzos de planificación y gobierno en definir cómo otros pueden ampliar la funcionalidad central de su software, entonces libera a otros para que lo hagan sin permiso o compromiso cercano. ¡Esto puede permitir mucha experimentación y creatividad!

Esa fue una gran parte de mi motivación sociotécnica al buscar complementos, pero había varias razones más:

• Mantener un proyecto de código abierto es bastante trabajo, y tengo mucho interés en mantener pequeña la “superficie de funciones” de sourmash para que haya menos que mantener. Eso lucha con el deseo de agregar más funcionalidad para satisfacer las necesidades de investigación y de los usuarios. Los complementos ofrecen una forma de segregar esfuerzos a ambos lados de una interfaz bien definida: ya sea un esfuerzo “central” (¡mucha coordinación y trabajo!) o un esfuerzo “externo” (quizás menos trabajo, ciertamente menos coordinación), y nosotros podemos asignar nuestra atención apropiadamente.

• Con un núcleo robusto, los complementos se pueden combinar para expandir la superficie de características de sourmash combinatoriamente. Esa es una forma elegante de decir que si hay un complemento de visualización nuevo y ordenado escrito por Tina, y un mecanismo de carga de colección remota nuevo y ordenado escrito por Steve, la gente puede usar estos complementos en combinación para aplicar la visualización a colecciones remotas.

• En este momento, es bastante difícil agregar funciones específicas de la plataforma a sourmash; en particular, hay algunos paquetes de software que nos gustaría usar que no se compilan en las computadoras portátiles Mac OS ARM. Los complementos serían una forma de admitir esas funciones en plataformas específicas.

• ¡Refactorizar componentes internos para admitir complementos puede limpiar el código interno! Los complementos de carga y guardado se implementan exactamente de la misma manera que nuestro código interno, y creo que el esfuerzo por modularizar la carga y el guardado a lo largo del tiempo ha terminado con un código razonablemente simple y decente internamente. Los complementos refuerzan eso al estandarizar la API.

¿Y cómo va eso, Dra. Brown?

Lo que puedo decir después de dedicar una docena de horas de trabajo en el marco del complemento es que ha sido muy liberador, es solo mucho más fácil para probar nuevas ideas y distinguirlas claramente de las contribuciones de código central “serias” que necesitan más cuidado y reflexión.

Así que… ¡va bien!

¿Qué tipos de complementos admite sourmash?

A partir de esta mañana, la rama principal de Sourmash admite load_from y save_to complementos Como sugieren los nombres, estos complementos brindan formas alternativas de cargar y guardar bocetos sourmash.

Usando estos, he construido un Complemento para guardar/cargar formato Avro así como un Complemento load-sketches-from-URI basado en fsspec.

Soy actualmente trabajando sobre la adición de soporte para nuevos subcomandos de línea de comandos. La idea es que pueda agregar nuevos comandos en sourmash scripts (un nombre provisional).

¿Cómo implementamos el soporte de complementos?

Puedes ver el primer complemento PR aquí, en sourmash#2428pero el tl; dr es: usamos importlib.metadata para admitir complementos a través de puntos de entrada.

El código para admitir complementos es bastante mínimo y actualmente reside en complementos.sourmash. Se parece a esto:

# load entry points.
_plugin_load_from = entry_points(group='sourmash.load_from')


def get_load_from_functions():
    "Load the 'load_from' plugins and yield tuples (priority, name, fn)."

    # Load each plugin,
    for plugin in _plugin_load_from:
        loader_fn = plugin.load()

        # get 'priority' if it is available
        priority = getattr(loader_fn, 'priority', DEFAULT_LOAD_FROM_PRIORITY)

        # retrieve name (which is specified by plugin?)
        name = plugin.name

        yield priority, name, loader_fn

Entonces, en el pyproject.toml de un paquete de Python, cualquiera puede afirmar que hay un complemento sourmash disponible así:

[project.entry-points."sourmash.load_from"]
a_reader = "module_name:load_sketches"

[project.entry-points."sourmash.save_to"]
a_writer = "module_name:SaveSignatures_WriteFile"

y sourmash lo cargará y utilizará automáticamente.

¿Cómo encajan los complementos en el ecosistema sourmash?

Tenemos un interesante ecosistema centrado en el laboratorio/adyacente al laboratorio que se está desarrollando en torno a sourmash.

sourmash en sí mismo proporciona una API Python y Rust razonablemente rica, para las personas que desean hacer cosas inteligentes con él. por ejemplo, el software de agua de rama es un script bastante pequeño para realizar búsquedas paralelas de muchos genomas, construido sobre la biblioteca Rust.

Hay flujos de trabajo que utilizan sourmash para hacer cosas geniales, como caracterizar metagenomas (genoma-molienda) y descontaminación de bases de datos (carbón). Estos (y otros) flujos de trabajo envuelven sourmash en un flujo de trabajo más grande (snakemake, nextflow, CWL, …?) para hacer varias cosas.

También hay un naciente R biblioteca, sourmashconsumr está siendo construido por Taylor Reiter (y otros) en Arcadia Science, para tomar la producción de sourmash y hacer cosas buenas con ella.

Taylor también está desarrollando código para cargar sourmash compare y gather salida en MultiQC (ver asunto). Esto está en efecto usando sourmash como un complemento para otro software.

Y ahora, los complementos de sourmash agregan un buen conjunto de oportunidades para diversificar la funcionalidad interna de sourmash a este ecosistema. ¡Será interesante ver lo que sucede a medida que construimos esta funcionalidad!

¿Cómo apoyamos a los desarrolladores de complementos?

Un aspecto importante de los complementos es admitir a los desarrolladores de complementos, por lo tanto, tenemos algo de documentación incipienteasí como un repositorio de plantillas de introducción para eliminar una gran cantidad de la repetición.

No estoy 100% seguro de qué agregar más allá de esto, pero creo que la prueba interna es un buen enfoque: cada vez que trabajo en un complemento, lijo un poco más las esquinas más afiladas de nuestra documentación.

¿Dónde sigue?

Por ahora, los complementos siguen siendo experimentales y no están sujetos a consideraciones de versiones semánticas. No estoy seguro de cuándo cambiará eso, ¡pero quiero escribir algunos complementos más antes de comprometerme con las interfaces actuales!

Creo que probablemente tengamos espacio para muchos más. tipos de complementos. Estamos pensando en cómo habilitar diferentes funciones de carga de taxonomía, por ejemplo; y tengo una necesidad específica de una mejor manipulación del manifiesto/lista de selección que creo que se puede convertir en un complemento. (El problema del diseño del complemento es agridulce#1353 si te interesa.)

También estoy empezando a pensar más en la experiencia del usuario. ¿Cómo encuentran, instalan, usan, depuran y eliminan complementos los usuarios? Todo esto es relativamente fácil si eres un desarrollador de Python que está familiarizado con pip y importlib.metadata, pero esa no es nuestra base de usuarios ;). Por ahora, comencé agregando informes de complementos a sourmash info -v¡lo que al menos nos da la oportunidad de descubrir qué complementos podrían existir!

Tampoco estoy muy seguro de cómo administrar lo que espero que sea una avalancha de pequeños complementos desde mi laboratorio. ¿Querremos tener un conjunto de complementos recomendados que evolucionen y maduren con el tiempo? ¿Y cómo evitamos aumentar masivamente nuestra superficie de mantenimiento? (Simon Willison tiene algunos sabio consejo para el acaparador de proyectos en serie que se aplica aquí.)

También tengo la inquietante sensación de que debería leer la interfaz del complemento de datasette para ver qué puedo aprender de todo el arduo trabajo y la experiencia de Simon…

–tito