Zenodo: [Solicitação de recurso] Opção "Abrir no fichário" para repositórios GitHub apropriados

Isso seria muito legal em geral.

Eu ficaria ainda mais interessado em (2) para que o binder possa resolver os DOIs do Zenodo e iniciar diretamente a partir deles, em vez dos repositórios git. A maior parte do trabalho (no lado do fichário) provavelmente seria em repo2docker que é a ferramenta que usamos para realmente construir os contêineres. No momento, ele usa git para buscar conteúdo ou usa um diretório local.

Em https://github.com/jupyterhub/binderhub/issues/216 , discutimos um pouco essa ideia para o lançamento do OSF.io

Apoiando o comentário de Tim - avise a equipe do Binder se houver algo que possamos fazer para ajudar!

Acho que isso está relacionado ao recurso WIP de visualização de .tar.gz e outros formatos compactados: https://github.com/zenodo/zenodo/issues/557.

Concordo, seria um recurso muito legal. Tecnicamente, parece que o Binder usa o Repo2Docker, que, pelo que sei, precisa de um repositório git para funcionar. Acho que este é o principal obstáculo, já que o Zenodo apenas arquiva uma bola Zip do lançamento específico. A solução alternativa seria simplesmente apontar para o repositório GitHub (porque temos o SHA da versão que arquivamos), mas basicamente simplesmente contornamos o Zenodo e não há valor agregado real em apenas ter o emblema no repositório GitHub .

Obrigado por nos contactar sobre este assunto, @lnielsen! Alguns pensamentos:

A solução alternativa seria simplesmente apontar para o repositório GitHub (porque temos o SHA da versão que arquivamos) [...]

Em vez de apontar para o repositório GitHub diretamente, faria sentido ter um emblema "Binder" no Zenodo apontando para o commit / tag específico que foi arquivado no Zenodo (já que o Binder pode lidar com branches, tags ou commits). Isso significa que você pode pular diretamente para a mesma versão do código / repo que está vinculado ao DOI.

[…] Então, essencialmente, simplesmente ignoramos o Zenodo, e não há valor agregado real em apenas ter o emblema no repositório do GitHub.

Bem, se você apontar para o commit / tag específico, ainda haverá valor, já que os emblemas no GitHub normalmente apontam para o commit mais recente em master . No entanto, do ponto de "preservação" e "persistência" que um DOI deve fornecer, faria sentido se pudéssemos ignorar o GitHub e renderizar o repo diretamente do Zenodo, de modo que o conteúdo ainda seja "interativo", mesmo que o repositório GitHub original é removido.

@choldgraf , @betatim : Existe uma maneira de "falsificar" um git init essencialmente sem propósito de algum tipo no fluxo de trabalho repo2docker ? Então:

• repo2docker descompacta Zip-ball → repo2docker executa git init → Binder aponta para conteúdo / caderno (s).

• editar

@choldgraf , @betatim : Existe uma maneira de "falsificar" um

essa é uma ótima pergunta - acho que isso seria viável, provavelmente como um buildpack para repo2docker (que poderia ser feito no r2d ou como uma "extensão" que vive em um repositório separado). Esse buildpack iria inserir as linhas em um dockerfile que faz a descompactação etc.

Acabei de abrir este problema para discutir no r2d: https://github.com/jupyter/repo2docker/issues/234

Isso seria incrível!

Acho que há duas partes para isso:

1. Adicionando capacidade de leitura de um arquivo ZIP em um determinado URL ao repo2docker
2. Adicionando capacidade de ler um identificador zonodo com versão ao arquivo zip apropriado + semântica de cache para binderhub.

Enquanto isso, acho que adicionar um link para a versão marcada no github é a coisa mais simples de fazer!

Ei, @yuvipanda. No momento, sim, procurar um emblema do Binder e vincular à versão apropriada no GitHub é uma solução provisória - dependendo de como @lnielsen e co. priorize isso, é claro! :)

Relativo:

2. Adicionando capacidade de ler um identificador zonodo [sic] com versão ao arquivo zip apropriado + semântica de cache para binderhub.

O Zenodo obtém repos apenas quando uma nova versão é lançada e eu acho que o emblema do GitHub na própria entrada do Zenodo aponta para o tree apropriado no GitHub. Isso ajuda em alguma coisa?

O emblema seria muito fácil de adicionar, se já soubéssemos que o repositório github oferece suporte ao fichário, mas não é fácil detectar se o fichário é compatível. O que poderíamos fazer é permitir a adição de links no campo "identificadores releatados", que renderizariam um logotipo como o github que permite que você o inicie no fichário.

@lnielsen alguns pensamentos que vêm à mente:

1. Verifique se um repositório tem um emblema de fichário em seu README
2. Verifique se um repositório tem algum tipo de tag (por exemplo, "fichário pronto", "fichário")
3. Verifique se um repo tem um ou mais dos arquivos de configuração e, em caso afirmativo, tente compilá-lo por meio da API de compilação do Binder ... se retornar com êxito, prossiga.

Apenas cuspindo aqui :-)

Acho que saber se um repo fará algo útil se você iniciá-lo em um BinderHub é muito difícil para um computador. muitos repositórios serão construídos e iniciados, mas a maioria deles não funciona :-( Então, eu procuraria o emblema do fichário no README, mas isso também é uma heurística crua (como você encontraria (em escala) repositórios que têm um fichário badge que aponta para uma instância diferente de mybinder.org?) -> Tornar o status 'pronto para fichário' opt-in humano é provavelmente o melhor e pode ser legível por máquina também.

Existe um formato / arquivo que o zenodo analisa para extrair informações extras para um repositório? Semelhante a um .travis.yml ou algo assim?

Eu estava tentando evitar ter que analisar arquivos no repositório :-)

Eu diria que a melhor maneira seria através do CodeMeta de alguma forma - https://codemeta.github.io já que estamos planejando habilitar a leitura de metadados do arquivo codemeta.

O BinderHub e o repo2docker agora são compatíveis com a inicialização do Zenodo DOIs: https://twitter.com/mybinderteam/status/1139136841792315392

Conforme mencionado em https://github.com/zenodo/zenodo/issues/1416#issuecomment -398732740, acho que uma solução sensata seria exibir um logotipo do Binder com o link mybinder adequado (semelhante ao do GitHub), quando houver é um link para https://mybinder.org nos "identificadores relacionados" (registro de exemplo: https://zenodo.org/record/3402938)

Minha única preocupação, e provavelmente da equipe do Binder (cc @betatim , @yuvipanda , @choldgraf), é criar uma exposição muito maior do serviço MyBinder e fazer o DoS-ing, o que acabaria fazendo os usuários seguirem um link para um " " página. Imagine que os usuários que acabam em um registro de software Zenodo que tem um logotipo Binder, possam clicar nele por curiosidade.

Eu li os documentos de confiabilidade e os mecanismos de limitação de taxa que estão no local parecem bons, então eu acho que é apenas uma questão se os mantenedores do serviço MyBinder estão ok com isso :)

Como regra geral, os picos de tráfego não devem ser um grande problema, desde que não sejam picos gigantescos . Que tipo de tráfego vocês imaginam enviar? :-)

Como referência, você pode ter uma ideia da carga e "aumento" dos repositórios para a implantação do binderhub público (aquele em mybinder.org) aqui:

https://grafana.mybinder.org/d/fZWsQmnmz/pod-activity?refresh=1m&orgId=1&var-cluster=default
Algumas pessoas lançaram o fichário ~ 100-200 de uma vez quando o estavam usando para ministrar cursos e tal, às vezes o lançamento leva mais tempo se precisarmos escalar para um novo nó, mas em geral deve estar OK.

O limite rígido é de 100 sessões simultâneas para um único repositório.

... quando houver um link para https://mybinder.org nos "identificadores relacionados" (registro de exemplo: https://zenodo.org/record/3402938)

Como um problema relacionado, seria possível ter metadados mais específicos nos "identificadores relacionados" para este caso de uso? Os valores de metadados associados a esse URL na seção "identificadores relacionados / alternativos" são muito pouco informativos ("Material complementar" e "Outro"). Seria possível adicionar novos valores de metadados como "Executa este upload" e "Ambiente de computação ao vivo" para deixar claro que o link permite ao leitor executar o software? Acho que este se tornará um caso de uso relativamente comum. Obrigado

: +1: para o tipo de relação. Minha sugestão seria "Ambiente interativo (de computação)", já que os Binders são para uso humano, e não uma execução única (o que poderia significar "Executa este upload").

O vocabulário de tipo de relação disponível para os identificadores relacionados é baseado no esquema DataCite v4.1 , então eu evitaria adicionar um novo tipo de relação "customizado".

IMHO, o tipo de relação mais adequado seria isSourceOf (ou seja, "tem este upload como sua fonte" no formulário de upload), no sentido de que o registro Zenodo é a fonte que o Binder usa para executá-lo:

Se tivermos um consenso geral sobre isso, acredito que podemos enviar no próximo lançamento :)

PS (@choldgraf): A pergunta boba de hoje: em termos de direitos autorais, podemos usar o logotipo do Binder do seu repo ?

@slint sim, você pode usar o logotipo. Sem que façamos nada extra, é licenciado assim . O que provavelmente não é ideal para obras de arte.

Se você vai fazer um "botão" para as pessoas pressionarem, há também https://static.mybinder.org/badge_logo.svg, que recomendamos como o "botão para iniciar um fichário"

@slint Eu não tinha percebido que o tipo de relação para identificadores relacionados / alternativos foi tirado do esquema DataCite v4.1. Talvez isso pudesse ser afirmado no texto do cabeçalho da seção, após o texto informando a gama de identificadores que são aceitos.

Eu concordo que dos tipos de relação disponíveis, isSourceOf é o mais apropriado e eu atualizei meu registro Zenodo que está sendo usado como exemplo.

O campo de tipo de recurso é baseado em resourceTypeGeneral no DataCite 4.1 (Tabela 7)? Nesse caso, interactiveResource ("Um recurso que requer interação do usuário para ser compreendido, executado ou experimentado") parece-me o valor mais apropriado. Infelizmente, isso não está disponível na lista suspensa, então optei por "Outro".