Zenodo: [फ़ीचर अनुरोध] उपयुक्त गिटहब रेपो के लिए "बाइंडर में खोलें" विकल्प

यह सामान्य तौर पर बहुत अच्छा होगा।

मुझे (2) में और भी अधिक दिलचस्पी होगी ताकि बाइंडर ज़ेनोडो डीओआई को हल कर सके और गिट रिपॉजिटरीज़ के बजाय सीधे उनसे लॉन्च कर सके। अधिकांश काम (बाइंडर की तरफ) शायद repo2docker जो कि वह उपकरण है जिसका उपयोग हम वास्तव में कंटेनरों को बनाने के लिए करते हैं। अभी यह सामग्री लाने या स्थानीय निर्देशिका का उपयोग करने के लिए git का उपयोग करता है।

https://github.com/jupyterhub/binderhub/issues/216 में हमने OSF.io से लॉन्च करने के लिए इस विचार पर थोड़ी चर्चा की

टिम की टिप्पणी का समर्थन करना - बाइंडर टीम को बताएं कि क्या कुछ है जो हम मदद कर सकते हैं!

मुझे लगता है कि यह .tar.gz और अन्य संपीड़ित प्रारूपों के पूर्वावलोकन की WIP सुविधा से संबंधित है: https://github.com/zenodo/zenodo/issues/557।

सहमत हूं, यह एक बहुत अच्छी सुविधा होगी। तकनीकी रूप से ऐसा लगता है कि बाइंडर रेपो 2 डॉकर का उपयोग करता है, जहां तक ​​​​मैं कह सकता हूं कि काम करने के लिए एक गिट भंडार की आवश्यकता है। मुझे लगता है कि यह मुख्य बाधा है क्योंकि ज़ेनोडो केवल विशिष्ट रिलीज की ज़िप-बॉल संग्रहीत करता है। कार्य-आसपास केवल GitHub रिपॉजिटरी को इंगित करना होगा (क्योंकि हमारे पास हमारे द्वारा संग्रहीत रिलीज़ का SHA है), लेकिन फिर हम अनिवार्य रूप से Zenodo को बायपास करते हैं, और केवल GitHub रेपो पर बैज होने पर कोई वास्तविक अतिरिक्त मूल्य नहीं है .

इस मुद्दे पर हमारे पास वापस आने के लिए धन्यवाद, @lnielsen! कुछ विचार:

वर्कअराउंड केवल गिटहब रिपोजिटरी को इंगित करना होगा (क्योंकि हमारे पास उस रिलीज का एसएचए है जिसे हमने संग्रहीत किया है) [...]

सीधे गिटहब भंडार को इंगित करने के बजाय, ज़ेनोडो पर "बाइंडर" बैज होना समझ में आता है जो ज़ेनोडो पर संग्रहीत विशिष्ट प्रतिबद्धता/टैग को इंगित करता है (क्योंकि बाइंडर शाखाओं, टैग या प्रतिबद्धताओं को संभाल सकता है)। इसका मतलब है कि आप सीधे कोड/रेपो के उसी संस्करण पर जा सकते हैं जो डीओआई से जुड़ा हुआ है।

[...] तो हम अनिवार्य रूप से ज़ेनोडो को बायपास कर देते हैं, और गिटहब रेपो पर बैज होने पर कोई वास्तविक अतिरिक्त मूल्य नहीं है।

ठीक है, यदि आप विशिष्ट प्रतिबद्ध/टैग को इंगित करते हैं, तो अभी भी मूल्य है, क्योंकि गिटहब में बैज आमतौर पर master में नवीनतम प्रतिबद्धता को इंगित करते हैं। हालांकि, "संरक्षण" और "दृढ़ता" के बिंदु से जो एक डीओआई प्रदान करने वाला है, यह समझ में आता है कि क्या हम वास्तव में गिटहब को बायपास कर सकते हैं और रेपो को सीधे ज़ेनोडो से प्रस्तुत कर सकते हैं, ताकि सामग्री अभी भी "इंटरैक्टिव" हो, भले ही मूल गिटहब रेपो नीचे ले जाया जाता है।

@choldgraf , @betatim : क्या ज़िप-बॉल से गिट रेपो को "नकली" करने का कोई तरीका है? repo2docker वर्कफ़्लो में किसी प्रकार का अनिवार्य रूप से उद्देश्यहीन* git init जोड़कर? इसलिए:

• repo2docker ज़िप-बॉल को अनपैक करता है → repo2docker git init चलता है → बाइंडर सामग्री/नोटबुक की ओर इशारा करता है।

• संपादित करें

@choldgraf , @betatim : क्या ज़िप-बॉल से गिट रेपो को "नकली" करने का कोई तरीका है? repo2docker वर्कफ़्लो में किसी प्रकार का अनिवार्य रूप से git init जोड़कर?

यह एक अच्छा सवाल है - मुझे लगता है कि यह संभव होगा, शायद repo2docker के लिए एक बिल्डपैक के रूप में (जिसे या तो r2d के भीतर किया जा सकता है, या एक "एक्सटेंशन" के रूप में जो एक अलग भंडार में रहता है)। वह बिल्डपैक एक डॉकफाइल में लाइनों को सम्मिलित करेगा जो अनज़िपिंग आदि करता है।

मैंने अभी इस मुद्दे को r2d के भीतर चर्चा करने के लिए खोला है: https://github.com/jupyter/repo2docker/issues/234

यह कमाल होगा!

मुझे लगता है कि इसके लिए दो भाग हैं:

1. किसी दिए गए URL पर एक ज़िप फ़ाइल से रेपो2डॉकर में पढ़ने की क्षमता जोड़ना
2. उपयुक्त ज़िप फ़ाइल में एक संस्करण वाले ज़ोनोडो पहचानकर्ता को पढ़ने की क्षमता जोड़ना + बाइंडरहब को कैशिंग सेमेन्टिक्स।

इस बीच, मुझे लगता है कि जीथब पर टैग किए गए संस्करण के लिए एक लिंक जोड़ना सबसे आसान काम है!

अरे, @युविपांडा। फिलहाल, हाँ, एक बाइंडर बैज की तलाश है और फिर गिटहब पर उपयुक्त संस्करण से लिंक करना एक अंतरिम समाधान है - यह कैसे

के बारे में:

2. उपयुक्त ज़िप फ़ाइल में एक संस्करण वाले ज़ोनोडो [एसआईसी] पहचानकर्ता को पढ़ने की क्षमता जोड़ना + बाइंडरहब को कैशिंग सेमेन्टिक्स।

ज़ेनोडो केवल एक नई रिलीज़ जारी होने पर रेपो लेता tree को इंगित करता है। क्या इससे कोई मदद मिलती है?

बैज जोड़ना बहुत आसान होगा, अगर हम पहले से ही जानते हैं कि जीथब रेपो बाइंडर का समर्थन करता है, लेकिन हमारे लिए यह पता लगाना आसान नहीं है कि बाइंडर समर्थित है या नहीं। हम जो कर सकते थे वह "रिलीज़ किए गए पहचानकर्ता" फ़ील्ड में लिंक जोड़ने की अनुमति देता है, जो तब जीथब जैसे लोगो को प्रस्तुत करेगा जो आपको इसे बाइंडर में लॉन्च करने की अनुमति देता है।

@lnielsen कुछ विचार जो दिमाग में आते हैं:

1. जांचें कि क्या रेपो के पास उनके README में बाइंडर बैज है
2. जांचें कि क्या रेपो में किसी प्रकार का टैग है (उदाहरण के लिए "बाइंडर-रेडी", "बाइंडर")
3. जांचें कि क्या रेपो में एक या अधिक कॉन्फ़िगरेशन फ़ाइलें हैं और यदि ऐसा है, तो इसे बाइंडर बिल्ड एपीआई के माध्यम से प्रयास करें और बनाएं ... यदि यह सफल होता है, तो आगे बढ़ें।

बस यहाँ स्पिटबॉलिंग :-)

मुझे लगता है कि यह जानना कि क्या रेपो कुछ उपयोगी करेगा यदि आप इसे बाइंडरहब पर लॉन्च करते हैं तो कंप्यूटर के लिए बहुत कठिन है। कई रिपॉजिटरी का निर्माण और लॉन्च होगा, लेकिन उनमें से अधिकांश काम नहीं करते हैं :-( इसलिए मैं रीडमे में बाइंडर बैज की तलाश करूंगा, लेकिन यह भी एक क्रूड हेयुरिस्टिक है (आप कैसे पाएंगे (पैमाने पर) रिपोजिटरी जिसमें एक बाइंडर है बैज जो mybinder.org से अलग उदाहरण की ओर इशारा करता है?) -> 'बाइंडर-रेडी' स्थिति को मानव ऑप्ट-इन बनाना शायद सबसे अच्छा है और फिर यह मशीन-पठनीय भी हो सकता है।

क्या कोई प्रारूप/फ़ाइल है जिसे ज़ेनोडो एक भंडार के लिए अतिरिक्त जानकारी निकालने के लिए देखता है? .travis.yml या कुछ ऐसे?

मैं भंडार में पार्स फाइलों से बचने की कोशिश कर रहा था :-)

मैं कहूंगा कि किसी भी तरह कोडमेटा के माध्यम से सबसे अच्छा तरीका होगा - https://codemeta.github.io क्योंकि हम कोडमेटा फ़ाइल से मेटाडेटा पढ़ने को सक्षम करने की योजना बना रहे हैं।

BinderHub और repo2docker अब Zenodo DOIs से लॉन्चिंग का समर्थन करते हैं: https://twitter.com/mybinderteam/status/1139136841792315392

जैसा कि https://github.com/zenodo/zenodo/issues/1416#issuecomment -398732740 में उल्लेख किया गया है, मुझे लगता है कि एक उचित समाधान उचित mybinder लिंक (गिटहब एक के समान) के साथ एक बाइंडर लोगो प्रदर्शित करना होगा, जब वहां "संबंधित पहचानकर्ताओं" में https://mybinder.org का लिंक है (उदाहरण रिकॉर्ड: https://zenodo.org/record/3402938)

मेरी एकमात्र चिंता है, और शायद बाइंडर टीम (cc @betatim , @yuvipanda , @choldgraf), MyBinder सेवा का बहुत बड़ा प्रदर्शन कर रही है, और इसे DoS-ing कर रही है, जो अंत में उपयोगकर्ताओं को "टूटे हुए" लिंक का अनुसरण करने के लिए मजबूर करेगी। " पृष्ठ। कल्पना कीजिए कि जो उपयोगकर्ता एक 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: संबंध प्रकार के लिए। मेरा सुझाव "इंटरएक्टिव (कंप्यूटिंग) पर्यावरण" होगा, क्योंकि बाइंडर्स मनुष्यों के उपयोग के लिए हैं, न कि एक बार निष्पादन (जो "इस अपलोड को निष्पादित करता है" का अर्थ हो सकता है)।

संबंधित पहचानकर्ताओं के लिए उपलब्ध संबंध प्रकार शब्दावली डेटासाइट v4.1 स्कीमा पर आधारित है, इसलिए मैं एक नया "कस्टम" संबंध प्रकार जोड़ने से

IMHO, सबसे उपयुक्त संबंध प्रकार isSourceOf (यानी अपलोड फॉर्म में "इस अपलोड को इसके स्रोत के रूप में है", इस अर्थ में कि ज़ेनोडो रिकॉर्ड वह स्रोत है जिसे बाइंडर इसे निष्पादित करने के लिए उपयोग करता है:

अगर उस पर हमारी आम सहमति है, तो मेरा मानना ​​है कि हम इसे अगली रिलीज में भेज सकते हैं :)

PS (@choldgraf): आज का मूर्खतापूर्ण प्रश्न: कॉपीराइट के अनुसार, क्या आपके रेपो से बाइंडर लोगो का उपयोग

@slint हाँ आप लोगो का उपयोग कर सकते हैं। हमें कुछ भी अतिरिक्त किए बिना इसे इस तरह लाइसेंस दिया जाता है। जो शायद कलाकृति के लिए आदर्श नहीं है।

यदि आप लोगों को प्रेस करने के लिए "बटन" बनाने जा रहे हैं तो https://static.mybinder.org/badge_logo.svg भी है जिसे हम "बाइंडर लॉन्च करने के लिए बटन" के रूप में सुझाते हैं।

@slint मुझे नहीं पता था कि संबंधित/वैकल्पिक पहचानकर्ताओं के लिए संबंध प्रकार डेटासाइट v4.1 स्कीमा से लिया गया था। शायद यह स्वीकार किए जाने वाले पहचानकर्ताओं की श्रेणी बताते हुए पाठ के बाद, खंड के मुख्य पाठ में कहा जा सकता है।

मैं सहमत हूं कि उपलब्ध संबंध प्रकारों में से, isSourceOf सबसे उपयुक्त है और मैंने अपने ज़ेनोडो रिकॉर्ड को अपडेट कर दिया है जिसका एक उदाहरण के रूप में उपयोग किया जा रहा है।

क्या संसाधन प्रकार फ़ील्ड डेटासाइट 4.1 (तालिका 7) में संसाधन टाइप जनरल पर आधारित है? यदि ऐसा है, तो interactiveResource ("एक संसाधन जिसे समझने, क्रियान्वित करने या अनुभव करने के लिए उपयोगकर्ता से बातचीत की आवश्यकता होती है") मुझे सबसे उपयुक्त मूल्य लगता है। दुर्भाग्य से, यह ड्रॉप डाउन सूची में उपलब्ध नहीं है, इसलिए मैंने "अन्य" को चुना।