Zenodo: [Solicitud de función] Opción "Abrir en Binder" para repositorios de GitHub adecuados

Esto sería genial en general.

Estaría aún más interesado en (2) para que Binder pueda resolver los DOI de Zenodo y lanzarse directamente desde esos en lugar de repositorios de git. La mayor parte del trabajo (en el lado de la carpeta) probablemente estaría en repo2docker que es la herramienta que usamos para construir los contenedores. Ahora mismo usa git para buscar contenido o usa un directorio local.

En https://github.com/jupyterhub/binderhub/issues/216 discutimos un poco esta idea para lanzarla desde OSF.io

Secundando el comentario de Tim: ¡informe al equipo de Binder si hay algo que podamos hacer para ayudar!

Creo que esto está relacionado con la función WIP de obtener una vista previa de .tar.gz y otros formatos comprimidos: https://github.com/zenodo/zenodo/issues/557.

De acuerdo, sería una característica muy interesante. Técnicamente, parece que Binder usa Repo2Docker, que, por lo que puedo decir, necesita un repositorio de git para funcionar. Este creo que es el principal obstáculo, ya que Zenodo solo archiva un Zip-ball de la versión específica. La solución sería simplemente apuntar al repositorio de GitHub (porque tenemos el SHA de la versión que archivamos), pero luego, básicamente, simplemente omitimos a Zenodo, y no hay un valor agregado real por tener la insignia en el repositorio de GitHub. .

¡Gracias por comunicarse con nosotros sobre este tema, @lnielsen! Algunos pensamientos:

La solución alternativa sería simplemente apuntar al repositorio de GitHub (porque tenemos el SHA de la versión que archivamos) […]

En lugar de apuntar directamente al repositorio de GitHub, tendría sentido tener una insignia "Binder" en Zenodo que apunte a la confirmación / etiqueta específica que se archivó en Zenodo (ya que Binder puede manejar ramas, etiquetas o confirmaciones). Esto significa que puede saltar directamente a la misma versión del código / repositorio que está vinculado desde el DOI.

[…] Entonces, esencialmente, simplemente pasamos por alto a Zenodo, y no hay un valor agregado real por tener la insignia en el repositorio de GitHub.

Bueno, si apunta a la confirmación / etiqueta específica, todavía hay valor, ya que las insignias en GitHub generalmente apuntan a la última confirmación en master . Sin embargo, desde el punto de "preservación" y "persistencia" que se supone que debe proporcionar un DOI, tendría sentido si pudiéramos omitir GitHub y renderizar el repositorio directamente desde Zenodo, de modo que el contenido siga siendo "interactivo" incluso si el repositorio de GitHub original se elimina.

@choldgraf , @betatim : ¿Hay alguna manera de "falsificar" un repositorio de Git desde Zip-ball? ¿Al agregar un * git init esencialmente sin propósito de algún tipo en el flujo repo2docker trabajo

• repo2docker desempaqueta Zip-ball → repo2docker ejecuta git init → Binder apunta al contenido / cuaderno (s).

• editar

@choldgraf , @betatim : ¿Hay alguna manera de "falsificar" un repositorio de Git desde Zip-ball? ¿Al agregar esencialmente un git init de algún tipo en el flujo de trabajo de repo2docker?

esa es una gran pregunta - creo que esto sería factible, probablemente como un paquete de compilación para repo2docker (que podría hacerse dentro de r2d, o como una "extensión" que vive en un repositorio separado). Ese paquete de compilación insertaría las líneas en un archivo docker que descomprime, etc.

Acabo de abrir este problema para discutirlo dentro de r2d: https://github.com/jupyter/repo2docker/issues/234

¡Esto sería genial!

Creo que hay dos partes para esto:

1. Añadiendo la capacidad de leer desde un archivo ZIP en una URL determinada a repo2docker
2. Añadiendo capacidad para leer un identificador de zonodo versionado al archivo zip apropiado + semántica de almacenamiento en caché en binderhub.

Mientras tanto, creo que agregar un enlace a la versión etiquetada en github es lo más simple que se puede hacer.

Hola, @yuvipanda. Por el momento, sí, buscar una insignia de Binder y luego vincularla a la versión apropiada en GitHub es una solución provisional, dependiendo de cómo @lnielsen y compañía. priorizar esto, por supuesto! :)

Sobre:

2. Añadiendo capacidad para leer un identificador de zonodo [sic] versionado al archivo zip apropiado + semántica de almacenamiento en caché en binderhub.

Zenodo toma repositorios solo cuando se emite una nueva versión y creo que la insignia de GitHub en la entrada de Zenodo apunta al tree apropiado en GitHub. ¿Esto ayuda en algo?

La insignia sería bastante fácil de agregar, si ya sabemos que el repositorio de github admite Binder, pero no es fácil para nosotros detectar si Binder es compatible. Lo que podríamos hacer es permitir agregar enlaces en el campo "identificadores releated", que luego generarían un logotipo como github que le permite lanzarlo en binder.

@lnielsen algunos pensamientos que me vienen a la mente:

1. Compruebe si un repositorio tiene una insignia de carpeta en su archivo README
2. Compruebe si un repositorio tiene una etiqueta de algún tipo (p. Ej., "Binder-ready", "binder")
3. Verifique si un repositorio tiene uno o más de los archivos de configuración y, si es así, intente compilarlo a través de la API de compilación de Binder ... si regresa como exitoso, entonces continúe.

Solo escupir aquí :-)

Creo que saber si un repositorio hará algo útil si lo inicia en un BinderHub es muy difícil para una computadora. muchos repositorios se construirán y lanzarán, pero la mayoría de ellos no funcionan :-( Entonces buscaría la insignia de carpeta en el README, pero eso también es una heurística cruda (¿cómo encontrarías repositorios (a escala) que tienen una carpeta ¿Insignia que apunta a una instancia diferente a mybinder.org?) -> Hacer el opt-in humano del estado 'binder-ready' es probablemente lo mejor y luego también puede ser legible por máquina.

¿Existe un formato / archivo que zenodo busca para extraer información adicional para un repositorio? ¿Similar a .travis.yml o algo así?

Estaba tratando de evitar tener que analizar los archivos en el repositorio :-)

Yo diría que la mejor manera sería a través de CodeMeta de alguna manera: https://codemeta.github.io ya que estamos planeando habilitar la lectura de metadatos del archivo codemeta.

BinderHub y repo2docker ahora admiten el lanzamiento desde DOI de Zenodo: https://twitter.com/mybinderteam/status/1139136841792315392

Como se menciona en https://github.com/zenodo/zenodo/issues/1416#issuecomment -398732740, creo que una solución sensata sería mostrar un logotipo de Binder con el enlace de mybinder adecuado (similar al de GitHub), cuando haya es un enlace a https://mybinder.org en los "identificadores relacionados" (registro de ejemplo: https://zenodo.org/record/3402938)

Mi única preocupación, y probablemente la del equipo de Binder (cc @betatim , @yuvipanda , @choldgraf), es crear una exposición mucho mayor del servicio MyBinder y DoS-ing, lo que terminaría haciendo que los usuarios sigan un enlace a un " " página. Imagine que los usuarios que terminan en un registro de software de Zenodo que tiene un logotipo de Binder, podrían simplemente hacer clic en él por curiosidad.

He leído los documentos de confiabilidad y los mecanismos de limitación de velocidad que están en su lugar se ven bien, así que supongo que es solo una pregunta si los mantenedores del servicio MyBinder están de acuerdo con eso :)

Como regla general, los picos de tráfico no deberían ser un gran problema siempre que no sean picos gigantes . ¿Qué tipo de tráfico se imaginan enviar? :-)

Como referencia, puede obtener una idea de la carga y el "pico" de los repositorios para la implementación pública de binderhub (el de mybinder.org) aquí:

https://grafana.mybinder.org/d/fZWsQmnmz/pod-activity?refresh=1m&orgId=1&var-cluster=default
Hemos tenido gente que lanzó ~ 100-200 binder a la vez cuando lo estaban usando para impartir cursos y tal, a veces el lanzamiento lleva más tiempo si necesitamos escalar a un nuevo nodo, pero en general debería estar bien.

El límite estricto es de 100 sesiones simultáneas para un solo repositorio.

... cuando hay un enlace a https://mybinder.org en los "identificadores relacionados" (registro de ejemplo: https://zenodo.org/record/3402938)

Como problema relacionado, ¿sería posible tener metadatos más específicos en los "identificadores relacionados" para este caso de uso? Los valores de metadatos asociados con esa URL en la sección "identificadores relacionados / alternativos" son bastante poco informativos ("Material complementario" y "Otro"). ¿Sería posible agregar nuevos valores de metadatos como "Ejecuta esta carga" y "Entorno informático en vivo" para dejar en claro que el enlace permite al lector ejecutar el software? Creo que este se convertirá en un caso de uso relativamente común. Gracias

: +1: para el tipo de relación. Mi sugerencia sería "Entorno interactivo (informático)", ya que los Binders son para uso humano, y no una ejecución única (que podría significar "Ejecuta esta carga").

El vocabulario de tipo de relación disponible para los identificadores relacionados se basa en el esquema de DataCite v4.1 , por lo que evitaría agregar un nuevo tipo de relación "personalizado".

En mi humilde opinión, el tipo de relación más adecuado sería isSourceOf (es decir, "tiene esta carga como su fuente" en el formulario de carga), en el sentido de que el registro de Zenodo es la fuente que Binder usa para ejecutarlo:

Si tenemos un consenso general sobre eso, creo que podemos enviarlo en la próxima versión :)

PD (@choldgraf): La pregunta tonta de hoy: en cuanto a los derechos de autor, ¿está bien que usemos el logotipo de Binder de su repositorio ?

@slint sí, puedes usar el logo. Sin hacer nada extra que tiene licencia como éste . Lo que probablemente no sea ideal para obras de arte.

Si va a hacer un "botón" para que la gente presione, también hay https://static.mybinder.org/badge_logo.svg que recomendamos como el "botón para lanzar una carpeta".

@slint No me había dado cuenta de que el tipo de relación para los identificadores relacionados / alternativos se tomó del esquema DataCite v4.1. Quizás eso podría indicarse en el texto de cabecera de la sección, después del texto indicando el rango de identificadores que se aceptan.

Estoy de acuerdo en que de los tipos de relación disponibles, isSourceOf es el más apropiado y he actualizado mi registro de Zenodo que se está utilizando como ejemplo.

¿El campo de tipo de recurso se basa en resourceTypeGeneral en DataCite 4.1 (Tabla 7)? Si es así, el interactiveResource ("Un recurso que requiere la interacción del usuario para ser entendido, ejecutado o experimentado") me parece el valor más apropiado. Desafortunadamente, esto no está disponible en la lista desplegable, así que opté por "Otro".