Zenodo: [기능 요청] 적절한 GitHub 저장소에 대한 "바인더에서 열기" 옵션

이것은 일반적으로 매우 멋질 것입니다.

바인더가 Zenodo DOI를 해결하고 git 저장소 대신 직접 실행할 수 있도록 (2)에 훨씬 더 관심이 있습니다. 대부분의 작업(바인더 측)은 실제로 컨테이너를 빌드하는 데 사용하는 도구인 repo2docker 에 있을 것입니다. 지금은 git 를 사용하여 내용을 가져오거나 로컬 디렉토리를 사용합니다.

https://github.com/jupyterhub/binderhub/issues/216에서 우리는 OSF.io에서 시작하기 위해 이 아이디어에 대해 약간 논의했습니다.

Tim의 의견을 참고하십시오 - 우리가 도울 수 있는 일이 있으면 바인더 팀에 알려주십시오!

이것은 .tar.gz 및 기타 압축 형식 미리보기의 WIP 기능과 관련이 있다고 생각합니다: https://github.com/zenodo/zenodo/issues/557.

동의합니다. 매우 멋진 기능이 될 것입니다. 기술적으로 Binder가 Repo2Docker를 사용하는 것처럼 보입니다. 내가 말할 수 있는 한 작동하려면 git 저장소가 필요합니다. Zenodo는 특정 릴리스의 Zip-ball만 보관하므로 이것이 주요 장애물이라고 생각합니다. 해결 방법은 단순히 GitHub 리포지토리를 가리키는 것이지만(아카이브한 릴리스의 SHA가 있기 때문에) 기본적으로 Zenodo를 우회하고 GitHub 리포지토리에 배지가 있는 것보다 실질적인 부가 가치는 없습니다. .

@lnielsen, 이 문제에 대해 다시 알려주셔서 감사합니다! 몇 가지 생각:

해결 방법은 단순히 GitHub 리포지토리를 가리키는 것입니다(아카이브한 릴리스의 SHA가 있기 때문에) […]

GitHub 리포지토리를 직접 가리키는 대신 Zenodo에 보관된 특정 커밋/태그를 가리키는 "Binder" 배지를 Zenodo에 두는 것이 좋습니다(Binder는 분기, 태그 또는 커밋을 처리할 수 있기 때문에). 이는 DOI에서 링크된 동일한 버전의 코드/리포지토리로 직접 이동할 수 있음을 의미합니다.

[...] 그러면 본질적으로 Zenodo를 우회하고 GitHub 저장소에 배지를 갖는 것보다 실질적인 부가 가치는 없습니다.

특정 커밋/태그를 가리키면 GitHub의 배지가 일반적으로 master 의 최신 커밋을 가리키기 때문에 여전히 가치가 있습니다. 그러나 DOI가 제공해야 하는 "보존"과 "지속성"의 관점에서, GitHub를 우회하고 Zenodo에서 직접 repo를 렌더링할 수 있다면 의미가 있을 것입니다. 원래 GitHub 리포지토리가 삭제됩니다.

@choldgraf , @betatim : Zip-ball에서 Git 저장소를 "위조"하는 방법이 있습니까? repo2docker 워크플로에 본질적으로 목적이 없는* git init 를 추가하면? 그래서:

• repo2docker Zip-ball 압축 풀기 → repo2docker 실행 git init → 바인더가 콘텐츠/노트북을 가리킵니다.

• 편집하다

@choldgraf , @betatim : Zip-ball에서 Git 저장소를 "위조"하는 방법이 있습니까? repo2docker 워크플로에 어떤 종류의 본질적으로 git init를 추가하여?

좋은 질문입니다. 아마도 repo2docker용 빌드팩(r2d 내에서 수행하거나 별도의 저장소에 있는 "확장"으로 수행할 수 있음)으로 이것이 가능하다고 생각합니다. 해당 빌드팩은 압축 해제 등을 수행하는 dockerfile에 라인을 삽입합니다.

방금 이 문제를 열어 r2d 내에서 논의했습니다. https://github.com/jupyter/repo2docker/issues/234

이것은 굉장할 것입니다!

여기에는 두 부분이 있다고 생각합니다.

1. repo2docker에 지정된 URL의 ZIP 파일에서 읽는 기능 추가
2. 버전이 지정된 zonodo 식별자를 적절한 zip 파일에 읽고 의미 체계를 바인더 허브에 캐싱하는 기능 추가.

그동안 github에 태그된 버전에 대한 링크를 추가하는 것이 가장 간단한 작업이라고 생각합니다!

안녕하세요 @yuvipanda입니다. 현재로서는 Binder 배지를 찾은 다음 GitHub에서 적절한 버전에 연결하는 것이 임시 솔루션입니다. @lnielsen 및 co. 물론 이것을 우선시하십시오! :)

에 관하여:

2. 버전이 지정된 zonodo [sic] 식별자를 적절한 zip 파일에 읽을 수 있는 기능과 바인더허브에 의미 체계를 캐싱하는 기능 추가.

Zenodo는 새 릴리스가 발행 될 때만 저장소를 가져오고 Zenodo 항목 자체의 GitHub 배지는 GitHub의 적절한 tree 를 가리킵니다. 이것이 전혀 도움이 되나요?

github repo가 ​​바인더를 지원한다는 것을 이미 알고 있다면 배지를 추가하는 것은 매우 쉬울 것이지만 바인더가 지원되는지 여부를 감지하는 것은 쉽지 않습니다. 우리가 할 수 있는 일은 "관련 식별자" 필드에 링크를 추가하는 것입니다. 그러면 바인더에서 실행할 수 있는 github와 같은 로고가 렌더링됩니다.

@lnielsen 마음에 떠오르는 몇 가지 생각:

1. repo의 README에 바인더 배지가 있는지 확인하십시오.
2. repo에 어떤 종류의 태그가 있는지 확인합니다(예: "binder-ready", "binder").
3. 리포지토리에 하나 이상의 구성 파일이 있는지 확인하고, 그렇다면 바인더 빌드 API를 통해 빌드를 시도하고...성공적으로 반환되면 계속 진행합니다.

여기에서 그냥 침을 뱉습니다 :-)

BinderHub에서 실행하면 repo가 ​​유용한 작업을 수행할 수 있는지 아는 것은 컴퓨터에서 매우 어렵다고 생각합니다. 많은 리포지토리가 구축 및 실행되지만 대부분은 작동하지 않습니다. -(따라서 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에서 언급했듯이 합리적인 해결책은 적절한 mybinder 링크(GitHub과 유사)와 함께 바인더 로고를 표시하는 것입니다. "관련 식별자"에서 https://mybinder.org 에 대한 링크입니다(예제 레코드: https://zenodo.org/record/3402938).

내 유일한 관심사이자 아마도 바인더 팀(cc @betatim , @yuvipanda , @choldgraf)은 MyBinder 서비스와 DoS-ing을 훨씬 더 많이 노출시키고 사용자가 "깨진 " 페이지. Binder 로고가 있는 Zenodo 소프트웨어 레코드를 보게 된 사용자가 호기심에 클릭할 수 있다고 상상해 보십시오.

나는 Reliability 문서를 읽었고 제자리에 있는 속도 제한 메커니즘이 좋아 보이기 때문에 MyBinder 서비스 유지 관리자가 그것에 대해 괜찮은지 질문일 뿐입니다. :)

일반적으로 트래픽 스파이크는 엄청난 스파이크가 아닌 한 큰 문제가 되어서는 안 됩니다. 어떤 종류의 트래픽을 보내는 것을 상상하십니까? :-)

참고로, 여기에서 공용 바인더허브 배포(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 스키마를 기반으로 하므로 새로운 "맞춤형" 관계 유형을 추가하는 것은 피하겠습니다.

IMHO에서 가장 적합한 관계 유형은 isSourceOf (즉, 업로드 양식에서 "이 업로드를 소스로 사용"). Zenodo 레코드가 Binder가 이를 실행하는 데 사용하는 소스라는 의미에서:

이에 대한 일반적인 합의가 있다면 다음 릴리스에서 이를 제공할 수 있을 것입니다. :)

PS (@choldgraf): 오늘의 어리석은 질문입니다. 저작권 문제가 있습니다. 귀하의 리포지토리에 있는 바인더 로고를 사용해도 될까요?

@slint 네 로고를 사용할 수 있습니다. 우리가 추가 작업을 수행하지 않으면 다음 과 같이 라이센스가 부여됩니다. 예술 작품에는 적합하지 않을 수 있습니다.

사람들이 누를 수 있는 "버튼"을 만들려는 경우 "바인더 실행 버튼"으로 권장하는 https://static.mybinder.org/badge_logo.svg 도

@slint 관련/대체 식별자에 대한 관계 유형이 DataCite v4.1 스키마에서 가져온 것임을 깨닫지 못했습니다. 아마도 그것은 허용되는 식별자의 범위를 설명하는 텍스트 다음에 절제의 헤드 텍스트에 명시될 수 있습니다.

사용 가능한 관계 유형 중 isSourceOf 가 가장 적절하다는 데 동의하고 예로 사용 중인 Zenodo 레코드를 업데이트했습니다.

리소스 유형 필드는 DataCite 4.1(표 7)의 resourceTypeGeneral을 기반으로 합니까? 그렇다면 interactiveResource ("이해하거나 실행하거나 경험하기 위해 사용자의 상호 작용이 필요한 리소스")가 가장 적절한 값인 것 같습니다. 불행히도, 이것은 드롭다운 목록에서 사용할 수 없으므로 "기타"를 선택했습니다.