Zenodo: [機能リクエスト]適切なGitHubリポジトリの「バインダーで開く」オプション

これは一般的に非常にクールです。

バインダーがZenodoDOIを解決し、gitリポジトリの代わりにそれらから直接起動できるように（2）にさらに興味があります。 （バインダー側の）ほとんどの作業は、おそらく実際にコンテナーを構築するために使用するツールであるrepo2dockerで行われます。 現在、 gitを使用してコンテンツをフェッチするか、ローカルディレクトリを使用しています。

https://github.com/jupyterhub/binderhub/issues/216で、OSF.ioから起動するためのこのアイデアについて少し説明しました。

ティムのコメントを支持する-私たちが助けるために何かできることがあるかどうかバインダーチームに知らせてください！

これは、 .tar.gzやその他の圧縮形式をプレビューするWIP機能に関連していると思います： https ：

同意しました、それは非常にクールな機能でしょう。 技術的には、BinderがRepo2Dockerを使用しているように見えます。これは、私が知る限り、機能するためにgitリポジトリが必要です。 Zenodoは特定のリリースのZipボールしかアーカイブしないため、これが主な障害だと思います。 回避策は、GitHubリポジトリをポイントすることです（アーカイブしたリリースのSHAがあるため）が、基本的にZenodoをバイパスするだけであり、GitHubリポジトリにバッジを付けるだけで実際の付加価値はありません。 。

この問題についてご連絡いただきありがとうございます、@ lnielsen！ いくつかの考え：

回避策は、GitHubリポジトリをポイントすることです（アーカイブしたリリースのSHAがあるため）[…]

GitHubリポジトリを直接指すのではなく、Zenodoにアーカイブされた特定のコミット/タグを指す「Binder」バッジをZenodoに付ける方が理にかなっています（Binderはブランチ、タグ、またはコミットを処理できるため）。 これは、DOIからリンクされているのと同じバージョンのコード/リポジトリに直接ジャンプできることを意味します。

[…]基本的にZenodoをバイパスするだけで、GitHubリポジトリにバッジを付けるだけで真の付加価値はありません。

GitHubのバッジは通常、 masterの最新のコミットを指しているため、特定のコミット/タグを指す場合でも、価値はあります。 ただし、DOIが提供するはずの「保存」と「永続性」の観点から、GitHubをバイパスして、Zenodoから直接リポジトリをレンダリングできれば、コンテンツは「インタラクティブ」であり続けます。元のGitHubリポジトリが削除されます。

@ choldgraf 、 @ betatim ：ZipボールからGitリポジトリを「偽造」する方法はありますか？ repo2dockerワークフローにある種の本質的に無意味な* git initを追加することによって？ そう：

• repo2docker Zip-ballを解凍します→ repo2dockerはgit init →バインダーはコンテンツ/ノートブックを指します。

• 編集

@ choldgraf 、 @ betatim ：ZipボールからGitリポジトリを「偽造」する方法はありますか？ repo2dockerワークフローにある種の本質的にgitinitを追加することによって？

これは素晴らしい質問です。おそらく、repo2dockerのビルドパックとして（r2d内で実行することも、別のリポジトリにある「拡張機能」として実行することもできます）、これは実現可能だと思います。 そのビルドパックは、解凍などを行うdockerfileに行を挿入します。

この問題を開いてr2d内で議論しました： https ：

これは素晴らしいでしょう！

これには2つの部分があると思います。

1. 指定されたURLのZIPファイルから読み取る機能をrepo2dockerに追加します
2. バージョン管理されたzonodo識別子を適切なzipファイルに読み取る機能を追加します+バインダーハブにセマンティクスをキャッシュします。

それまでの間、githubでタグ付けされたバージョンへのリンクを追加するのが最も簡単なことだと思います！

ねえ、@ yuvipanda。 現時点では、ええ、バインダーバッジを探してから、GitHubで適切なバージョンにリンクすることは、 @ lnielsenと共同の方法に応じて暫定的な解決策です。 もちろん、これを優先してください！ :)

について：

2. バージョン管理されたzonodo [sic]識別子を適切なzipファイルに読み取る機能を追加し、バインダハブにセマンティクスをキャッシュします。

Zenodoは、新しいリリースが発行されたときにのみリポジトリを取得します。Zenodoエントリ自体のGitHubバッジは、GitHubの適切なtreeを指していると思います。 これはまったく役に立ちますか？

githubリポジトリがバインダーをサポートしていることがすでにわかっている場合、バッジを追加するのは非常に簡単ですが、バインダーがサポートされているかどうかを検出するのは簡単ではありません。 私たちにできることは、「関連する識別子」フィールドにリンクを追加できるようにすることです。これにより、バインダーで起動できるgithubのようなロゴがレンダリングされます。

@lnielsen頭に浮かぶいくつかの考え：

1. リポジトリのREADMEにバインダーバッジがあるかどうかを確認します
2. リポジトリに何らかのタグがあるかどうかを確認します（例：「バインダー対応」、「バインダー」）
3. リポジトリに1つ以上の構成ファイルがあるかどうかを確認し、ある場合は、BinderビルドAPIを介してビルドしてみてください...成功した場合は続行してください。

ここで唾を吐くだけです:-)

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で述べたように、適切なmybinderリンク（GitHubのものと同様）を使用してBinderロゴを表示するのが賢明な解決策だと思います。 「関連識別子」内のhttps://mybinder.orgへのリンクです（レコード例：https：//zenodo.org/record/3402938）

私の唯一の懸念、そしておそらくバインダーチーム（cc @ betatim 、 @ yuvipanda 、@ choldgraf）は、MyBinderサービスのはるかに大きな露出を作成し、それをDoS攻撃することです。これにより、ユーザーは「壊れた」へのリンクをたどることになります。 "ページ。 バインダーのロゴが付いたZenodoソフトウェアレコードにたどり着いたユーザーが、好奇心からクリックするだけかもしれないと想像してみてください。

信頼性のドキュメントを読みましたが、インプレースの律速メカニズムは良さそうなので、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：リレーションタイプの場合。 私の提案は「インタラクティブ（コンピューティング）環境」です。バインダーは人間が使用するためのものであり、1回限りの実行ではありません（「このアップロードを実行する」という意味です）。

関連する識別子に使用できるリレーションタイプの語彙は、 DataCite v4.1スキーマに基づいているため、新しい「カスタム」リレーションタイプを追加することは避けます。

IMHO、最も適切な関係タイプはisSourceOf （つまり、アップロードフォームで「このアップロードをソースとして持つ」）です。これは、ZenodoレコードがBinderが実行に使用するソースであるという意味です。

それについて一般的なコンセンサスがあれば、次のリリースでこれを出荷できると思います:)

PS（@choldgraf）：今日のばかげた質問：著作権に関して、あなたのリポジトリからバインダーのロゴを使用しても大丈夫ですか？

@slintはい、ロゴを使用できます。 私たちが特別なことをしなくても、このようにライセンスされます。 これはおそらくアートワークには理想的ではありません。

人々が押すための「ボタン」を作成する場合は、 https：//static.mybinder.org/badge_logo.svgもあり

@slint関連する/代替の識別子の関係タイプがDataCitev4.1スキーマから取得されていることに気づいていませんでした。 おそらくそれは、受け入れられる識別子の範囲を示すテキストの後に、セクションの先頭のテキストで述べることができます。

利用可能なリレーションタイプの中で、 isSourceOfが最も適切であり、例として使用されているZenodoレコードを更新したことに同意します。

リソースタイプフィールドは、DataCite 4.1のresourceTypeGeneralに基づいていますか（表7）？ もしそうなら、 interactiveResource （「ユーザーからの対話を理解、実行、または経験する必要があるリソース」）が最も適切な値であるように思われます。 残念ながら、これはドロップダウンリストに表示されないため、「その他」を選択しました。