Zenodo: [Запрос функции] Параметр «Открыть в Binder» для соответствующих репозиториев GitHub

Это было бы вообще очень круто.

Я был бы еще больше заинтересован в (2), чтобы связыватель мог разрешать Zenodo DOI и запускать непосредственно из них, а не из репозиториев git. Большая часть работы (на стороне связующего), вероятно, будет выполняться в repo2docker который является инструментом, который мы используем для фактического создания контейнеров. Прямо сейчас он использует git для извлечения содержимого или использует локальный каталог.

В https://github.com/jupyterhub/binderhub/issues/216 мы немного обсудили эту идею для запуска из OSF.io

Второй комментарий Тима - сообщите команде Binder, если мы можем чем-то помочь!

Я думаю, это связано с функцией предварительного просмотра .tar.gz и других сжатых форматов WIP: https://github.com/zenodo/zenodo/issues/557.

Согласен, это была бы очень крутая функция. Технически похоже, что Binder использует Repo2Docker, которому, насколько я могу судить, для работы нужен репозиторий git. Я думаю, что это главное препятствие, поскольку Zenodo архивирует только Zip-мяч конкретного выпуска. Обходным решением было бы просто указать на репозиторий GitHub (потому что у нас есть SHA релиза, который мы заархивировали), но тогда мы по существу просто обходим Zenodo, и нет никакой реальной дополнительной ценности, чем просто наличие значка в репозитории GitHub .

Спасибо, что ответили на этот вопрос, @lnielsen! Некоторые мысли:

Чтобы решить эту проблему, просто укажите на репозиторий GitHub (потому что у нас есть SHA заархивированного выпуска) […]

Вместо того, чтобы напрямую указывать на репозиторий GitHub, имеет смысл иметь значок «Binder» на Zenodo, указывающий на конкретный коммит / тег, который был заархивирован в Zenodo (поскольку Binder может обрабатывать ветки, теги или коммиты). Это означает, что вы можете напрямую перейти к той же версии кода / репо, которая связана с DOI.

[…] Тогда мы, по сути, просто обходим Zenodo, и нет никакой реальной пользы от наличия значка в репозитории GitHub.

Что ж, если вы укажете на конкретную фиксацию / тег, значение все равно будет, поскольку значки в GitHub обычно указывают на последнюю фиксацию в master . Однако с точки зрения «сохранения» и «постоянства», которые должен обеспечивать DOI, было бы разумно, если бы мы действительно могли обойти GitHub и визуализировать репозиторий непосредственно из Zenodo, чтобы контент оставался «интерактивным», даже если исходное репозиторий GitHub будет удалено.

@choldgraf , @betatim : Есть ли способ "подделать" git init в рабочий процесс repo2docker ? Так:

• repo2docker распаковывает Zip-ball → repo2docker запускает git init → Binder указывает на содержимое / блокноты.

• редактировать

@choldgraf , @betatim : Есть ли способ "подделать"

это отличный вопрос - я думаю, что это было бы возможно, вероятно, в качестве пакета сборки для repo2docker (это можно было бы сделать либо в r2d, либо в качестве «расширения», которое находится в отдельном репозитории). Этот пакет сборки будет вставлять строки в файл докеров, который выполняет разархивирование и т. Д.

Я только что открыл эту проблему для обсуждения в r2d: https://github.com/jupyter/repo2docker/issues/234

Это было бы здорово!

Я думаю, что для этого есть две части:

1. Добавление возможности чтения из ZIP-файла по заданному URL-адресу в repo2docker
2. Добавление возможности чтения идентификатора zonodo с версией в соответствующий zip-файл + семантика кеширования в binderhub.

А пока, думаю, проще всего добавить ссылку на версию с тегами на github!

Привет, @yuvipanda. На данный момент да, поиск значка Binder и последующая ссылка на соответствующую версию на GitHub - это временное решение - в зависимости от того, как @lnielsen and co. конечно, сделайте это в первую очередь! :)

Что касается:

2. Добавление возможности чтения версионного идентификатора zonodo [sic] в соответствующий zip-файл + семантика кэширования в binderhub.

Zenodo получает репозитории только тогда, когда выпускается новый выпуск, и я думаю, что значок GitHub на самой записи Zenodo указывает на соответствующий tree на GitHub. Это вообще помогает?

Значок было бы довольно легко добавить, если бы мы уже знали, что репозиторий github поддерживает привязку, но нам нелегко определить, поддерживается ли привязка. Что мы могли бы сделать, так это разрешить добавление ссылок в поле «выпущенные идентификаторы», которые затем отображали бы логотип, такой как github, который позволяет вам запускать его в связке.

@lnielsen, несколько мыслей, которые приходят в голову:

1. Проверьте, есть ли у репо значок связующего в README
2. Проверьте, есть ли в репо какой-либо тег (например, «готово для переплета», «связыватель»).
3. Проверьте, есть ли в репо один или несколько файлов конфигурации, и, если да, попробуйте создать его через API сборки Binder ... если он вернется как успешный, продолжайте.

Просто тут плевать :-)

Я думаю, что знать, будет ли репо делать что-то полезное, если вы запустите его на BinderHub, очень сложно для компьютера. многие репозитории будут созданы и запущены, но большинство из них не работают :-( Так что я бы поискал значок привязки в README, но это также грубая эвристика (как бы вы могли найти (в масштабе) репозитории, у которых есть привязка значок, указывающий на другой экземпляр, нежели mybinder.org?) -> Возможно, лучше всего будет сделать статус «готово для переплета», и тогда он также будет машиночитаемым.

Есть ли формат / файл, который zenodo просматривает для извлечения дополнительной информации для репозитория? Похоже на .travis.yml или что-то подобное?

Я пытался избежать синтаксического анализа файлов в репозитории :-)

Я бы сказал, что лучше всего было бы каким-то образом через CodeMeta - https://codemeta.github.io, поскольку мы планируем включить чтение метаданных из файла codemeta.

BinderHub и repo2docker теперь поддерживают запуск из Zenodo DOI: https://twitter.com/mybinderteam/status/1139136841792315392

Как упоминалось в https://github.com/zenodo/zenodo/issues/1416#issuecomment -398732740, я думаю, что разумным решением было бы отобразить логотип Binder с правильной ссылкой mybinder (аналогично ссылке GitHub), когда есть ссылка на https://mybinder.org в «связанных идентификаторах» (пример записи: https://zenodo.org/record/3402938)

Единственное, что меня беспокоит, и, вероятно, команда Binder (cc @betatim , @yuvipanda , @choldgraf), - это сделать сервис MyBinder более заметным и сделать его DoS-атакой, что в конечном итоге заставит пользователей перейти по ссылке на "неработающий" " страница. Представьте, что пользователи, которые попадают в запись программного обеспечения Zenodo с логотипом Binder, могут просто щелкнуть по ней из любопытства.

Я прочитал документацию по

Как правило, скачки трафика не должны иметь большого значения, если они не являются гигантскими . Какой трафик вы все себе представляете? :-)

В качестве справки вы можете получить представление о загрузке и "пикантности" репозиториев для общедоступного развертывания binderhub (на mybinder.org) здесь:

https://grafana.mybinder.org/d/fZWsQmnmz/pod-activity?refresh=1m&orgId=1&var-cluster=default
У нас были люди, запускающие ~ 100-200 связующих одновременно, когда они использовали его для преподавания курсов и тому подобного, иногда запуск занимает больше времени, если нам нужно масштабировать до нового узла, но в целом все должно быть в порядке.

Жесткое ограничение - 100 одновременных сеансов для одного репозитория.

... когда есть ссылка на https://mybinder.org в «связанных идентификаторах» (пример записи: https://zenodo.org/record/3402938)

В качестве связанной проблемы, можно ли иметь более конкретные метаданные в «связанных идентификаторах» для этого варианта использования? Значения метаданных, связанных с этим URL в разделе «связанных / альтернативных идентификаторов», довольно неинформативны («Дополнительные материалы» и «Другое»). Можно ли добавить новые значения метаданных, такие как «Выполняет эту загрузку» и «Живая вычислительная среда», чтобы было ясно, что ссылка позволяет читателю запускать программное обеспечение? Я думаю, что это станет относительно распространенным вариантом использования. Спасибо

: +1: для типа отношения. Мое предложение было бы «Интерактивная (вычислительная) среда», поскольку Биндеры предназначены для использования людьми, а не одноразовое выполнение (что может означать «Выполняет эту загрузку»).

Доступный словарь типов отношений для связанных идентификаторов основан на схеме DataCite v4.1 , поэтому я бы не стал добавлять новый «настраиваемый» тип отношения.

ИМХО, наиболее подходящим типом отношения будет isSourceOf (т.е. «имеет эту загрузку в качестве источника» в форме загрузки) в том смысле, что запись Zenodo является источником, который Binder использует для ее выполнения:

Если у нас будет общий консенсус по этому поводу, я думаю, мы сможем выпустить это в следующем выпуске :)

PS (@choldgraf): Сегодняшний глупый вопрос: с точки зрения авторских прав, можно ли нам использовать логотип Binder из вашего репо ?

@slint да, вы можете использовать логотип. Без каких-либо дополнительных действий он лицензируется вот так . Что, вероятно, не идеально подходит для художественных работ.

Если вы собираетесь сделать «кнопку», которую люди будут нажимать, есть также https://static.mybinder.org/badge_logo.svg, который мы рекомендуем в качестве «кнопки для запуска связующего».

@slint Я не понял, что тип отношения для связанных / альтернативных идентификаторов был взят из схемы DataCite v4.1. Возможно, это можно было бы указать в заголовке раздела после текста, в котором указывается диапазон допустимых идентификаторов.

Я согласен с тем, что из доступных типов отношений isSourceOf является наиболее подходящим, и я обновил свою запись Zenodo, которая используется в качестве примера.

Основано ли поле типа ресурса на resourceTypeGeneral в DataCite 4.1 (таблица 7)? Если это так, то interactiveResource («Ресурс, требующий взаимодействия со стороны пользователя для понимания, выполнения или опыта») мне кажется наиболее подходящим значением. К сожалению, этого нет в раскрывающемся списке, поэтому я выбрал «Другое».