Zenodo: [طلب الميزة] خيار "فتح في Binder" لمستودعات GitHub المناسبة

تم إنشاؤها على ٦ فبراير ٢٠١٨  ·  21تعليقات  ·  مصدر: zenodo/zenodo

معلومات أساسية


الطلب : أضف زرًا في سجلات Zenodo ذات الصلة لفتح GitHub repo في Binder لأجهزة الكمبيوتر المحمولة التفاعلية وما إلى ذلك ، لتشجيع إعادة الإنتاج في البحث ، باستخدام رابط GitHub ↔ Zenodo.

  1. إذا كان المصدر GitHub repo README لديهLaunch Binder ، اعرض شارة مماثلة على Zenodo أسفل شارة "متوفر في GitHub".
  2. اعمل مع فريق Binder بحيث يمكن إطلاق محتويات الريبو المضغوط في Binder مباشرة من أرشيف Zenodo ، إذا اختفى GitHub repo الأصلي (الحفظ).

نسخة إلى :

Feature request Needs investigation Accepted GitHub

التعليق الأكثر فائدة

يدعم BinderHub و repo2docker الآن الإطلاق من Zenodo DOIs: https://twitter.com/mybinderteam/status/1139136841792315392

ال 21 كومينتر

سيكون هذا رائعًا جدًا بشكل عام.

سأكون أكثر اهتمامًا بـ (2) حتى يتمكن الموثق من حل Zenodo DOIs والبدء مباشرة من تلك بدلاً من مستودعات git. من المحتمل أن يكون معظم العمل (على جانب الموثق) في repo2docker وهي الأداة التي نستخدمها لبناء الحاويات بالفعل. يستخدم حاليًا git لجلب المحتويات أو استخدام دليل محلي.

في https://github.com/jupyterhub/binderhub/issues/216 ناقشنا هذه الفكرة قليلاً للإطلاق من OSF.io

تعليق تعليق تيم - أخبر فريق Binder إذا كان هناك أي شيء يمكننا القيام به للمساعدة!

أعتقد أن هذا مرتبط بميزة ويب لمعاينة .tar.gz وغيرها من التنسيقات المضغوطة: https://github.com/zenodo/zenodo/issues/557.

متفق عليه ، ستكون ميزة رائعة جدًا. من الناحية الفنية ، يبدو أن Binder يستخدم Repo2Docker ، والذي يحتاج بقدر ما أستطيع إلى مستودع git من أجل العمل. أعتقد أن هذا هو العقبة الرئيسية لأن Zenodo يقوم فقط بأرشفة كرة مضغوطة من الإصدار المحدد. سيكون الحل البديل هو الإشارة ببساطة إلى مستودع GitHub (لأن لدينا SHA للإصدار الذي قمنا بأرشفته) ، ولكن بعد ذلك نتجاوز بشكل أساسي Zenodo ، ولا توجد قيمة مضافة حقيقية لمجرد الحصول على الشارة على GitHub repo .

شكرًا على تواصلك معنا بخصوص هذه المشكلة ، @ lnielsen! بعض الأفكار:

سيكون الحل البديل هو ببساطة الإشارة إلى مستودع GitHub (لأن لدينا SHA للإصدار الذي قمنا بأرشفته) [...]

بدلاً من الإشارة إلى مستودع GitHub مباشرةً ، سيكون من المنطقي أن يكون لديك شارة "Binder" على Zenodo تشير إلى الالتزام / العلامة المحددة التي تم أرشفتها في Zenodo (نظرًا لأن Binder يمكنه التعامل مع الفروع أو العلامات أو الالتزامات). هذا يعني أنك قادر على القفز مباشرة إلى نفس الإصدار من الكود / الريبو المرتبط من DOI.

[...] ثم نحن في الأساس نتجاوز Zenodo ، ولا توجد قيمة مضافة حقيقية لمجرد الحصول على الشارة على GitHub repo.

حسنًا ، إذا أشرت إلى الالتزام / العلامة المحددة ، فلا تزال هناك قيمة ، نظرًا لأن الشارات في GitHub تشير عادةً إلى آخر التزام في master . ومع ذلك ، من وجهة نظر "الحفظ" و "المثابرة" التي من المفترض أن توفرها معرّف DOI ، سيكون من المنطقي إذا تمكنا بالفعل من تجاوز GitHub وتقديم الريبو مباشرة من Zenodo ، بحيث يظل المحتوى "تفاعليًا" حتى لو يتم حذف مستودع GitHub الأصلي.


choldgraf ، betatim : هل هناك طريقة "لتزييف" Git repo من Zip-ball؟ عن طريق إضافة * git init من نوع ما بلا هدف في سير العمل repo2docker ؟ وبالتالي:

  • repo2docker يفرغ Zip-ball → repo2docker يدير git init → يشير Binder إلى المحتويات / المفكرة.

  • تعديل

choldgraf ، betatim : هل هناك طريقة "لتزييف" Git repo من Zip-ball؟ عن طريق إضافة init الأساسية من نوع ما في سير عمل repo2docker؟

هذا سؤال رائع - أعتقد أن هذا سيكون ممكنًا ، ربما كحزمة buildpack لـ repo2docker (يمكن أن يتم ذلك إما داخل r2d ، أو كـ "امتداد" يعيش في مستودع منفصل). ستدرج حزمة buildpack الأسطر في ملف dockerfile الذي يقوم بفك الضغط وما إلى ذلك.

لقد فتحت للتو هذه المشكلة للمناقشة خلال r2d: https://github.com/jupyter/repo2docker/issues/234

سيكون هذا رائعا!

أعتقد أن هناك جزأين لهذا:

  1. إضافة القدرة على القراءة من ملف مضغوط على عنوان URL معين إلى repo2docker
  2. إضافة القدرة على قراءة معرف zonodo الذي تم إصداره إلى ملف zip المناسب + تخزين دلالات التخزين المؤقت في Binderhub.

في غضون ذلك ، أعتقد أن إضافة رابط إلى الإصدار الموسوم على جيثب هو أبسط شيء يمكن القيام به!

مرحبًا ،yuvipanda. في الوقت الحالي ، نعم ، يعد البحث عن شارة Binder ثم الارتباط بالإصدار المناسب على GitHub حلاً مؤقتًا - اعتمادًا على كيفية استخدام lnielsen and co. إعطاء الأولوية لهذا ، بالطبع! :)

بخصوص:

  1. إضافة القدرة على قراءة معرف zonodo الذي تم إصداره [كذا] إلى الملف المضغوط المناسب + دلالات التخزين المؤقت إلى Binderhub.

ينتزع Zenodo المستودعات فقط عند إصدار إصدار جديد وأعتقد أن شارة GitHub على إدخال Zenodo نفسه تشير إلى tree المناسب على GitHub. هل يساعد هذا على الإطلاق؟

سيكون من السهل إضافة الشارة ، إذا كنا نعلم بالفعل أن github repo يدعم Binder ، لكن ليس من السهل علينا اكتشاف ما إذا كان Binder مدعومًا أم لا. ما يمكننا القيام به هو السماح بإضافة روابط في حقل "المعرفات المعاد تحميلها" ، والتي من شأنها أن تعرض شعارًا مثل github الذي يسمح لك بتشغيله في Binder.

lnielsen بعض الأفكار التي تتبادر إلى الذهن:

  1. تحقق مما إذا كان الريبو يحتوي على شارة رابط في ملف README
  2. تحقق مما إذا كان لدى الريبو علامة من نوع ما (على سبيل المثال ، "Binder-ready" ، "Binder")
  3. تحقق مما إذا كان الريبو يحتوي على ملف أو أكثر من ملفات التكوين ، وإذا كان الأمر كذلك ، فحاول إنشاءه عبر Binder build API ... إذا عاد بنجاح ، فتابع.

مجرد البصق هنا :-)

أعتقد أن معرفة ما إذا كان الريبو سيفعل شيئًا مفيدًا إذا قمت بتشغيله على BinderHub أمر صعب للغاية بالنسبة لجهاز الكمبيوتر. سيتم إنشاء العديد من المستودعات وإطلاقها ولكن معظمها لا يعمل: - (لذلك سأبحث عن شارة Binder في README ، ولكن هذا أيضًا هو دليل تجريبي خام (كيف تجد (على نطاق واسع) المستودعات التي تحتوي على رابط) الشارة التي تشير إلى حالة مختلفة عن mybinder.org؟) -> من المحتمل أن يكون الخيار البشري هو الأفضل ومن ثم يمكن قراءته آليًا.

هل هناك تنسيق / ملف يبحث فيه zenodo لاستخراج معلومات إضافية للمستودع؟ شبيه بـ .travis.yml أو شيء من هذا القبيل؟

كنت أحاول تجنب الاضطرار إلى تحليل الملفات في المستودع :-)

أود أن أقول إن أفضل طريقة ستكون عبر CodeMeta بطريقة ما - https://codemeta.github.io نظرًا لأننا نخطط لتمكين قراءة البيانات الوصفية من ملف codemeta.

يدعم BinderHub و repo2docker الآن الإطلاق من Zenodo DOIs: 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 ( yuvipanda ،choldgraf) ، هو إنشاء عرض أكبر بكثير لخدمة MyBinder ، و DoS-ing it ، والذي سينتهي به الأمر إلى جعل المستخدمين يتبعون رابطًا إلى "معطّل " صفحة. تخيل أن المستخدمين الذين ينتهي بهم الأمر في سجل برنامج Zenodo الذي يحمل شعار Binder ، قد ينقرون عليه بدافع الفضول.

لقد قرأت مستندات الموثوقية ، وتبدو آليات تحديد المعدل الموضوعة جيدة ، لذلك أعتقد أنه مجرد سؤال إذا كان مشرفو خدمة MyBinder موافقين على ذلك :)

كقاعدة عامة ، لا ينبغي أن تكون الزيادات في حركة المرور كبيرة جدًا طالما أنها ليست ارتفاعات هائلة . ما نوع حركة المرور التي تتخيلونها جميعًا؟ :-)

كمرجع ، يمكنك الحصول على فكرة عن تحميل و "شدة" المستودعات لنشر 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: لنوع العلاقة. اقتراحي سيكون "بيئة تفاعلية (حوسبة)" ، لأن Binders هي للاستخدام البشري ، وليس التنفيذ لمرة واحدة (والذي قد يعني "تنفيذ هذا التحميل").

تعتمد مفردات نوع العلاقة المتاحة للمعرفات ذات الصلة على مخطط DataCite v4.1 ، لذلك

IMHO ، سيكون نوع العلاقة الأكثر ملاءمة هو isSourceOf (على سبيل المثال ، "يكون هذا التحميل مصدره" في نموذج التحميل) ، بمعنى أن تسجيلة Zenodo هي المصدر الذي يستخدمه Binder لتنفيذه:

image

إذا كان لدينا إجماع عام على ذلك ، أعتقد أنه يمكننا شحن هذا في الإصدار التالي :)

ملاحظة (choldgraf): سؤال اليوم السخيف: حقوق الطبع والنشر ، هل من الجيد لنا استخدام شعار Binder من الريبو الخاص بك ؟

slint نعم يمكنك استخدام الشعار. بدون القيام بأي شيء إضافي يتم ترخيصه بهذا الشكل. الذي ربما لا يكون مثاليًا للعمل الفني.

إذا كنت تنوي إنشاء "زر" ليضغط عليه الأشخاص ، فهناك أيضًا https://static.mybinder.org/badge_logo.svg الذي نوصي به باعتباره "الزر لتشغيل الرابط"

slint لم أدرك أن نوع العلاقة للمعرفات ذات الصلة / البديلة مأخوذ من مخطط DataCite v4.1. ربما يمكن ذكر ذلك في النص الرئيسي للقسم ، بعد النص الذي يوضح نطاق المعرفات المقبولة.

أوافق على أنه من بين أنواع العلاقات المتاحة ، فإن isSourceOf هو الأنسب وقد قمت بتحديث سجل Zenodo الخاص بي الذي يتم استخدامه كمثال.

هل يعتمد حقل نوع المورد على ResourceTypeGeneral في DataCite 4.1 (الجدول 7)؟ إذا كان الأمر كذلك ، فإن interactiveResource ("مورد يتطلب تفاعلًا من المستخدم ليتم فهمه أو تنفيذه أو خبرته") يبدو لي أنسب قيمة. للأسف ، هذا غير متوفر في القائمة المنسدلة ، لذلك اخترت "أخرى".

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات