Zenodo: [Permintaan fitur] Opsi "Buka di Binder" untuk repo GitHub yang sesuai

Dibuat pada 6 Feb 2018  ·  21Komentar  ·  Sumber: zenodo/zenodo

Informasi latar belakang


Permintaan : Tambahkan tombol dalam catatan Zenodo yang relevan untuk membuka repo GitHub di Binder untuk buku catatan interaktif dll., untuk mendorong reproduktifitas dalam penelitian, menggunakan tautan GitHub Zenodo.

  1. Jika sumber repo GitHub README memilikiLaunch Binder lencana, tawarkan lencana serupa di Zenodo di bawah lencana "Tersedia di GitHub".
  2. Bekerja dengan tim Binder sehingga isi repo zip dapat diluncurkan di Binder langsung dari arsip Zenodo, jika repo GitHub asli hilang (pelestarian).

cc: @betatim dari Binder

Feature request Needs investigation Accepted GitHub

Komentar yang paling membantu

BinderHub dan repo2docker sekarang mendukung peluncuran dari Zenodo DOI: https://twitter.com/mybinderteam/status/1139136841792315392

Semua 21 komentar

Ini akan sangat keren secara umum.

Saya akan lebih tertarik pada (2) sehingga pengikat dapat menyelesaikan Zenodo DOI dan meluncurkan langsung dari yang bukan dari repositori git. Sebagian besar pekerjaan (di sisi pengikat) mungkin berada di repo2docker yang merupakan alat yang kami gunakan untuk benar-benar membuat wadah. Saat ini menggunakan git untuk mengambil konten atau menggunakan direktori lokal.

Di https://github.com/jupyterhub/binderhub/issues/216 kami membahas sedikit ide ini untuk diluncurkan dari OSF.io

Mendukung komentar Tim - beri tahu tim Binder jika ada yang bisa kami lakukan untuk membantu!

Saya pikir ini terkait dengan fitur WIP untuk melihat pratinjau .tar.gz dan format terkompresi lainnya: https://github.com/zenodo/zenodo/issues/557.

Setuju, itu akan menjadi fitur yang sangat keren. Secara teknis sepertinya Binder menggunakan Repo2Docker, yang sejauh yang saya tahu membutuhkan repositori git agar dapat berfungsi. Ini menurut saya kendala utama karena Zenodo hanya mengarsipkan Zip-ball dari rilis tertentu. Solusinya adalah dengan hanya menunjuk ke repositori GitHub (karena kami memiliki SHA dari rilis yang kami arsipkan), tetapi kemudian kami pada dasarnya hanya melewati Zenodo, dan tidak ada nilai tambah nyata selain memiliki lencana di repo GitHub .

Terima kasih telah menghubungi kami kembali tentang masalah ini, @lnielsen! Beberapa pemikiran:

Solusinya adalah dengan hanya menunjuk ke repositori GitHub (karena kami memiliki SHA dari rilis yang kami arsipkan) […]

Daripada menunjuk ke repositori GitHub secara langsung, masuk akal untuk memiliki lencana "Binder" di Zenodo yang menunjuk ke komit/tag tertentu yang diarsipkan di Zenodo (karena Binder dapat menangani cabang, tag, atau komit). Ini berarti Anda dapat langsung melompat ke versi kode/repo yang sama yang ditautkan dari DOI.

[…] maka pada dasarnya kami hanya melewati Zenodo, dan tidak ada nilai tambah yang nyata selain memiliki lencana di repo GitHub.

Nah, jika Anda menunjuk ke komit/tag tertentu, masih ada nilai, karena lencana di GitHub biasanya menunjuk ke komit terbaru di master . Namun, dari sudut "pemeliharaan" dan "ketekunan" yang seharusnya disediakan oleh DOI, masuk akal jika kita memang dapat melewati GitHub dan merender repo langsung dari Zenodo, sehingga konten tetap "interaktif" meskipun repo GitHub asli akan dihapus.


@choldgraf , @betatim : Apakah ada cara untuk "memalsukan" repo Git dari Zip-ball? Dengan menambahkan semacam git init yang pada dasarnya tidak bertujuan* dalam alur kerja repo2docker ? Jadi:

  • repo2docker membongkar Zip-ball → repo2docker berjalan git init → Binder menunjuk ke isi/notebook.

  • edit

@choldgraf , @betatim : Apakah ada cara untuk "memalsukan" repo Git dari Zip-ball? Dengan menambahkan semacam init pada dasarnya git dalam alur kerja repo2docker?

itu pertanyaan yang bagus - saya pikir ini akan layak, mungkin sebagai buildpack untuk repo2docker (yang bisa dilakukan dalam r2d, atau sebagai "ekstensi" yang tinggal di repositori terpisah). Buildpack itu akan memasukkan baris ke dalam file docker yang melakukan unzip dll.

Saya baru saja membuka masalah ini untuk didiskusikan dalam r2d: https://github.com/jupyter/repo2docker/issues/234

Ini akan luar biasa!

Saya pikir ada dua bagian untuk ini:

  1. Menambahkan kemampuan untuk membaca dari file ZIP pada URL yang diberikan ke repo2docker
  2. Menambahkan kemampuan untuk membaca pengidentifikasi zonodo berversi ke file zip yang sesuai + semantik caching ke binderhub.

Sementara itu, saya pikir menambahkan tautan ke versi yang diberi tag di github adalah hal yang paling sederhana untuk dilakukan!

Hai, @yuvipanda. Saat ini, ya, mencari lencana Binder dan kemudian menautkan ke versi yang sesuai di GitHub adalah solusi sementara -- tergantung bagaimana @lnielsen dan rekan. memprioritaskan ini, tentu saja! :)

Tentang:

  1. Menambahkan kemampuan untuk membaca pengenal zonodo [sic] berversi ke file zip yang sesuai + semantik caching ke binderhub.

Zenodo mengambil repo hanya ketika rilis baru dikeluarkan dan saya pikir lencana GitHub pada entri Zenodo itu sendiri menunjuk ke tree di GitHub. Apakah ini membantu sama sekali?

Lencana akan cukup mudah untuk ditambahkan, jika kita sudah tahu bahwa repo github mendukung pengikat, tetapi tidak mudah bagi kita untuk mendeteksi apakah pengikat didukung. Apa yang dapat kami lakukan adalah mengizinkan penambahan tautan di bidang "pengidentifikasi terkait", yang kemudian akan membuat logo seperti github yang memungkinkan Anda meluncurkannya di binder.

@lnielsen beberapa pemikiran yang muncul di benak:

  1. Periksa apakah repo memiliki lencana pengikat di README mereka
  2. Periksa apakah repo memiliki semacam tag (misalnya "binder-ready", "binder")
  3. Periksa apakah repo memiliki satu atau lebih file konfigurasi dan, jika demikian, coba dan bangun melalui Binder build API...jika berhasil, lanjutkan.

Hanya meludah di sini :-)

Saya pikir mengetahui apakah repo akan melakukan sesuatu yang berguna jika Anda meluncurkannya di BinderHub sangat sulit untuk komputer. banyak repositori akan dibangun dan diluncurkan tetapi sebagian besar tidak berfungsi :-( Jadi saya akan mencari lencana pengikat di README, tetapi itu juga merupakan heuristik kasar (bagaimana Anda menemukan (dalam skala) repositori yang memiliki pengikat lencana yang menunjuk ke contoh yang berbeda dari mybinder.org?) -> Membuat status 'siap-pengikat' keikutsertaan manusia mungkin adalah yang terbaik dan kemudian dapat dibaca mesin juga.

Apakah ada format/file yang dilihat zenodo untuk mengekstrak informasi tambahan untuk repositori? Mirip dengan .travis.yml atau semacamnya?

Saya mencoba menghindari keharusan mengurai file di repositori :-)

Saya akan mengatakan cara terbaik adalah melalui CodeMeta entah bagaimana - https://codemeta.github.io karena kami berencana untuk mengaktifkan membaca metadata dari file codemeta.

BinderHub dan repo2docker sekarang mendukung peluncuran dari Zenodo DOI: https://twitter.com/mybinderteam/status/1139136841792315392

Seperti yang disebutkan dalam https://github.com/zenodo/zenodo/issues/1416#issuecomment -398732740 , saya pikir solusi yang masuk akal adalah menampilkan logo Binder dengan tautan mybinder yang tepat (mirip dengan yang GitHub), ketika ada adalah tautan ke https://mybinder.org di "pengidentifikasi terkait" (contoh catatan: https://zenodo.org/record/3402938)

Satu-satunya kekhawatiran saya, dan mungkin tim Binder (cc @betatim , @yuvipanda , @choldgraf), menciptakan eksposur yang jauh lebih besar dari layanan MyBinder, dan melakukan DoS, yang pada akhirnya akan membuat pengguna mengikuti tautan ke "broken " halaman. Bayangkan bahwa pengguna yang berakhir pada catatan perangkat lunak Zenodo yang memiliki logo Binder, mungkin hanya mengkliknya karena penasaran.

Saya telah membaca Reliability docs , dan mekanisme pembatasan kecepatan yang ada terlihat bagus, jadi saya kira itu hanya pertanyaan apakah pengelola layanan MyBinder setuju dengan itu :)

Sebagai aturan umum, lonjakan lalu lintas seharusnya tidak menjadi masalah besar selama itu bukan lonjakan besar . Lalu lintas seperti apa yang Anda bayangkan dikirim? :-)

Sebagai referensi, Anda bisa mendapatkan ide untuk memuat dan "spikiness" repositori untuk penerapan binderhub publik (yang ada di mybinder.org) di sini:

https://grafana.mybinder.org/d/fZWsQmnmz/pod-activity?refresh=1m&orgId=1&var-cluster=default
Kami memiliki orang-orang yang meluncurkan ~100-200 binder sekaligus ketika mereka menggunakannya untuk mengajar kursus dan semacamnya, terkadang peluncuran membutuhkan waktu lebih lama jika kami perlu meningkatkan ke node baru, tetapi secara umum seharusnya tidak masalah.

Batas kerasnya adalah 100 sesi simultan untuk satu repositori.

... ketika ada tautan ke https://mybinder.org di "pengidentifikasi terkait" (contoh catatan: https://zenodo.org/record/3402938)

Sebagai masalah terkait, apakah mungkin untuk memiliki metadata yang lebih spesifik di "pengidentifikasi terkait" untuk kasus penggunaan ini? Nilai metadata yang terkait dengan URL tersebut di bagian "pengidentifikasi terkait/alternatif" cukup tidak informatif ("Materi tambahan" & "Lainnya"). Apakah mungkin untuk menambahkan nilai metadata baru seperti "Jalankan unggahan ini" dan "Lingkungan komputasi langsung" untuk memperjelas bahwa tautan tersebut memungkinkan pembaca untuk menjalankan perangkat lunak? Saya pikir ini akan menjadi kasus penggunaan yang relatif umum. Terima kasih

:+1: untuk tipe relasi. Saran saya adalah "Lingkungan interaktif (komputasi)", karena Binder adalah untuk digunakan manusia, dan bukan eksekusi satu kali (yang bisa berarti "Mengeksekusi unggahan ini").

Kosakata tipe relasi yang tersedia untuk pengidentifikasi terkait didasarkan pada skema DataCite v4.1 , jadi saya akan menghindari menambahkan tipe relasi "kustom" baru.

IMHO, jenis relasi yang paling cocok adalah isSourceOf (yaitu "memiliki unggahan ini sebagai sumbernya" dalam formulir unggahan), dalam arti bahwa catatan Zenodo adalah sumber yang digunakan Binder untuk menjalankannya:

image

Jika kami memiliki konsensus umum tentang itu, saya yakin kami dapat mengirimkan ini di rilis berikutnya :)

PS (@choldgraf): Pertanyaan konyol hari ini: dari segi hak cipta, bolehkah kami menggunakan logo Binder dari repo Anda ?

@slint ya Anda bisa menggunakan logo. Tanpa kita melakukan sesuatu yang ekstra itu dilisensikan seperti ini . Yang mungkin tidak ideal untuk karya seni.

Jika Anda akan membuat "tombol" untuk ditekan orang, ada juga https://static.mybinder.org/badge_logo.svg yang kami sarankan sebagai "tombol untuk meluncurkan pengikat"

@slint Saya tidak menyadari jenis relasi untuk pengidentifikasi terkait/alternatif diambil dari skema DataCite v4.1. Mungkin itu bisa dinyatakan dalam teks kepala bagian, setelah teks yang menyatakan kisaran pengenal yang diterima.

Saya setuju bahwa dari jenis relasi yang tersedia, isSourceOf adalah yang paling sesuai dan saya telah memperbarui catatan Zenodo saya yang digunakan sebagai contoh.

Apakah bidang tipe sumber daya berdasarkan resourceTypeGeneral di DataCite 4.1 (Tabel 7)? Jika demikian, interactiveResource ("Sumber daya yang membutuhkan interaksi dari pengguna untuk dipahami, dijalankan, atau dialami") menurut saya adalah nilai yang paling tepat. Sayangnya, ini tidak tersedia di daftar drop-down, jadi saya memilih "Lainnya".

Apakah halaman ini membantu?
0 / 5 - 0 peringkat