Go: cmd/go: गो टूलचैन में पैकेज संस्करण समर्थन जोड़ें

अक्सर पूछे जाने वाले प्रश्नों

यह अंक टिप्पणी सबसे अधिक पूछे जाने वाले प्रश्नों का उत्तर देती है, चाहे नीचे दी गई चर्चा से या अन्य चर्चाओं से। चर्चा के अन्य प्रश्न अगले अंक टिप्पणी में हैं।

प्रस्ताव " डिप का उपयोग" क्यों नहीं है?

यात्रा की शुरुआत में, लगभग दो साल पहले, हम सभी का मानना ​​​​था कि इसका उत्तर रूबी के बंडलर और फिर रस्ट के कार्गो द्वारा अनुकरणीय पैकेज संस्करण दृष्टिकोण का पालन करना होगा: टैग किए गए सिमेंटिक संस्करण, एक हाथ से संपादित निर्भरता बाधा फ़ाइल मेनिफेस्ट के रूप में जाना जाता है, एक अलग मशीन-जनरेटेड ट्रांजिटिव डिपेंडेंसी विवरण जिसे लॉक फ़ाइल के रूप में जाना जाता है, एक वर्जन सॉल्वर जो मैनिफेस्ट को संतुष्ट करने वाली लॉक फ़ाइल की गणना करता है, और रिपॉजिटरी को वर्जनिंग की इकाई के रूप में जाना जाता है। डेप इस मोटे योजना का लगभग बिल्कुल पालन करता है और मूल रूप से गो कमांड एकीकरण के लिए मॉडल के रूप में काम करने का इरादा था। हालांकि, जितना अधिक मैंने बंडलर/कार्गो/डिप दृष्टिकोण के विवरण को समझा और गो के लिए उनका क्या अर्थ होगा, विशेष रूप से गो कमांड में निर्मित, और जितना अधिक मैंने गो टीम पर अन्य लोगों के साथ उन विवरणों पर चर्चा की, कुछ विवरण गो के लिए कम से कम एक अच्छा फिट लग रहा था। प्रस्ताव उन विवरणों को एक ऐसी प्रणाली की शिपिंग की आशा में समायोजित करता है जो डेवलपर्स के लिए समझने और उपयोग करने में आसान हो। हम जिस विशिष्ट विवरण को बदलना चाहते हैं, उसके बारे में और प्रस्ताव की घोषणा करने वाले ब्लॉग पोस्ट के बारे में अधिक जानकारी के लिए प्रस्ताव का तर्क अनुभाग देखें।

आयात पथों में प्रमुख संस्करण संख्याएं क्यों दिखाई देनी चाहिए?

आयात संगतता नियम का पालन करने के लिए, जो बाकी सिस्टम को नाटकीय रूप से सरल बनाता है। प्रस्ताव की घोषणा करने वाला ब्लॉग पोस्ट भी देखें, जो आयात संगतता नियम के लिए प्रेरणा और औचित्य के बारे में अधिक बात करता है।

आयात पथ से प्रमुख संस्करण v0, v1 क्यों छोड़े गए हैं?

v1 को दो कारणों से आयात पथ से हटा दिया गया है। सबसे पहले, कई डेवलपर ऐसे पैकेज बनाएंगे जो v1 तक पहुंचने के बाद कभी भी एक ब्रेकिंग परिवर्तन नहीं करते हैं, जो कि कुछ ऐसा है जिसे हमने शुरू से प्रोत्साहित किया है। हमें विश्वास नहीं है कि उन सभी डेवलपर्स को एक स्पष्ट v1 रखने के लिए मजबूर किया जाना चाहिए, जब उनके पास कभी भी v2 जारी करने का कोई इरादा नहीं हो सकता है। V1 सिर्फ शोर बन जाता है। यदि वे डेवलपर्स अंततः एक v2 बनाते हैं, तो अतिरिक्त सटीकता डिफ़ॉल्ट से अलग करने के लिए, v1. v1 को हर जगह लगाने के लिए दृश्य स्थिरता के बारे में अच्छे तर्क हैं, और अगर हम एक सिस्टम को खरोंच से डिजाइन कर रहे थे, तो शायद यह इसे एक करीबी कॉल बना देगा। लेकिन मौजूदा कोड का वजन संतुलन को दृढ़ता से v1.

v0 आयात पथ से हटा दिया गया है क्योंकि - सेवर के अनुसार - उन संस्करणों के लिए कोई संगतता गारंटी नहीं है। एक स्पष्ट v0 तत्व की आवश्यकता संगतता सुनिश्चित करने के लिए बहुत कम करेगी; आपको पूरी तरह से सटीक होने के लिए v0.1.2 कहना होगा, लाइब्रेरी के हर अपडेट पर सभी आयात पथों को अपडेट करना। यह ओवरकिल जैसा लगता है। इसके बजाय हम आशा करते हैं कि डेवलपर्स केवल उन मॉड्यूल की सूची को देखेंगे जिन पर वे निर्भर हैं और उन्हें मिलने वाले किसी भी v0.xy संस्करणों से उचित रूप से सावधान रहें।

इसका आयात पथ में v1 से v0 को अलग नहीं करने का प्रभाव है, लेकिन आमतौर पर v0 v1 के लिए अग्रणी परिवर्तनों को तोड़ने का एक क्रम है, इसलिए यह समझ में आता है कि v1 को उस ब्रेकिंग अनुक्रम में अंतिम चरण के रूप में माना जाता है, न कि कुछ ऐसा जिसे v0 से अलग करने की आवश्यकता होती है। . जैसा कि @Merovius ने कहा है (https://github.com/golang/go/issues/24301#issuecomment-376213693):

v0.x का उपयोग करके, आप स्वीकार कर रहे हैं कि v0.(x+1) आपको अपना कोड ठीक करने के लिए बाध्य कर सकता है। यह एक समस्या क्यों है यदि v0.(x+1) को इसके बजाय v1.0 कहा जाता है?

अंत में, प्रमुख संस्करणों v0 और v1 को छोड़ना अनिवार्य है - वैकल्पिक नहीं - ताकि प्रत्येक पैकेज के लिए एक एकल विहित आयात पथ हो।

मास्टर पर काम करना जारी रखने के बजाय मुझे v2 के लिए एक नई शाखा क्यों बनानी चाहिए?

आपको एक नई शाखा बनाने की आवश्यकता नहीं है। दुर्भाग्य से वीजीओ मॉड्यूल पोस्ट "प्रमुख शाखा" भंडार लेआउट की चर्चा में उस छाप को देता है। लेकिन vgo शाखाओं की परवाह नहीं करता है। यह केवल टैग को देखता है और हल करता है कि वे किस विशिष्ट कमिट को इंगित करते हैं। यदि आप मास्टर पर v1 विकसित करते हैं, तो आप तय करते हैं कि आप पूरी तरह से v1 के साथ कर चुके हैं, और आप मास्टर पर v2 कमिट बनाना शुरू करना चाहते हैं, यह ठीक है: मास्टर को v2.xy टैग के साथ टैग करना शुरू करें। लेकिन ध्यान दें कि आपके कुछ उपयोगकर्ता v1 का उपयोग करते रहेंगे, और आप कभी-कभी एक मामूली v1 बग फिक्स जारी करना चाह सकते हैं। आप उस कार्य के लिए कम से कम उस बिंदु पर एक नई v1 शाखा फोर्क करना चाहेंगे जहां आप v2 के लिए मास्टर का उपयोग करना शुरू करते हैं।

क्या न्यूनतम संस्करण चयन डेवलपर्स को महत्वपूर्ण अपडेट प्राप्त करने से नहीं रोकेगा?

यह एक सामान्य डर है, लेकिन मुझे सच में लगता है कि अगर कुछ विपरीत होगा। https://research.swtch.com/vgo-mvs के "अपग्रेड स्पीड" खंड का हवाला देते हुए:

यह देखते हुए कि न्यूनतम संस्करण चयन प्रत्येक निर्भरता का न्यूनतम अनुमत संस्करण लेता है, यह सोचना आसान है कि इससे पैकेजों की बहुत पुरानी प्रतियों का उपयोग होगा, जो बदले में अनावश्यक बग या सुरक्षा समस्याओं का कारण बन सकता है। व्यवहार में, हालांकि, मुझे लगता है कि विपरीत होगा, क्योंकि न्यूनतम अनुमत संस्करण सभी बाधाओं में से अधिकतम है, इसलिए एक बिल्ड में सभी मॉड्यूल के लिए उपलब्ध नियंत्रण का एक लीवर एक नए संस्करण के उपयोग को मजबूर करने की क्षमता है। एक निर्भरता की तुलना में अन्यथा उपयोग किया जाएगा। मुझे उम्मीद है कि कम से कम संस्करण चयन के उपयोगकर्ता ऐसे कार्यक्रमों के साथ समाप्त होंगे जो कार्गो जैसे अधिक आक्रामक सिस्टम का उपयोग करके अपने दोस्तों के रूप में लगभग अप-टू-डेट हैं।

उदाहरण के लिए, मान लें कि आप एक प्रोग्राम लिख रहे हैं जो कुछ अन्य मॉड्यूल पर निर्भर करता है, जो सभी कुछ बहुत ही सामान्य मॉड्यूल पर निर्भर करते हैं, जैसे gopkg.in/yaml.v2। आपके प्रोग्राम का निर्माण आपके मॉड्यूल द्वारा अनुरोध किए गए और कुछ हद तक निर्भरताओं के बीच नवीनतम वाईएएमएल संस्करण का उपयोग करेगा। यहां तक ​​​​कि केवल एक ईमानदार निर्भरता आपके निर्माण को कई अन्य निर्भरताओं को अद्यतन करने के लिए मजबूर कर सकती है। यह कुबेरनेट्स गो क्लाइंट समस्या के विपरीत है जिसका मैंने पहले उल्लेख किया था।

यदि कुछ भी, न्यूनतम संस्करण चयन इसके बजाय विपरीत समस्या का सामना करेगा, कि यह "अधिकतम न्यूनतम" उत्तर एक शाफ़्ट के रूप में कार्य करता है जो निर्भरता को बहुत तेज़ी से आगे बढ़ाता है। लेकिन मुझे लगता है कि व्यवहार में निर्भरता सिर्फ सही गति से आगे बढ़ेगी, जो कि कार्गो और दोस्तों की तुलना में सही मात्रा में धीमी है।

"सही मात्रा धीमी" से मैं मुख्य संपत्ति का जिक्र कर रहा था कि उन्नयन केवल तभी होता है जब आप उनसे पूछते हैं, न कि जब आपने नहीं किया है। इसका मतलब है कि कोड केवल तब बदलता है (संभावित रूप से अप्रत्याशित और ब्रेकिंग तरीकों से) जब आप उम्मीद कर रहे हैं कि ऐसा होने और इसका परीक्षण करने के लिए तैयार है, इसे डीबग करें, और इसी तरह।

प्रतिक्रिया भी देखें https://github.com/golang/go/issues/24301#issuecomment -375992900 @Merovius द्वारा।

यदि $GOPATH को पदावनत कर दिया जाता है, तो डाउनलोड किया गया कोड कहाँ रहता है?

जिस कोड की आप जांच करते हैं और जिस पर काम करते हैं और संशोधित करते हैं, उसे आपके फाइल सिस्टम में कहीं भी संग्रहीत किया जा सकता है, ठीक उसी तरह जैसे कि अनिवार्य रूप से हर दूसरे डेवलपर टूल के साथ होता है।

डाउनलोड किए गए स्रोत कोड को रखने और बायनेरिज़ को स्थापित करने के लिए Vgo को कुछ स्थान की आवश्यकता होती है, और इसके लिए यह अभी भी $GOPATH का उपयोग करता है, जो कि Go 1.9 डिफ़ॉल्ट रूप से $HOME/go पर है। इसलिए डेवलपर्स को कभी भी $GOPATH सेट करने की आवश्यकता नहीं होगी जब तक कि वे नहीं चाहते कि ये फ़ाइलें किसी भिन्न निर्देशिका में हों। केवल बाइनरी इंस्टॉल स्थान बदलने के लिए, वे $GOBIN (हमेशा की तरह) सेट कर सकते हैं।

आप // import टिप्पणी क्यों पेश कर रहे हैं?

नहीं थे। यह एक पूर्व-मौजूदा सम्मेलन था। दौरे में उस उदाहरण का उद्देश्य यह दिखाना था कि कैसे go.mod आयात टिप्पणियों से सही मॉड्यूल पथ का पता लगा सकता है, यदि वे मौजूद हैं। एक बार जब सभी प्रोजेक्ट go.mod फ़ाइलों का उपयोग कर लेते हैं, तो आयात टिप्पणियां पूरी तरह से बेमानी हो जाएंगी और संभवत: पदावनत हो जाएंगी।

चर्चा सारांश (अंतिम अद्यतन 2017-04-25)

इस मुद्दे की टिप्पणी में नीचे दी गई चर्चा का सारांश है।

हम प्रवासन को कैसे संभाल सकते हैं?

[ https://github.com/golang/go/issues/24301#issuecomment -374739116 @ChrisHines द्वारा।]

प्रतिक्रिया https://github.com/golang/go/issues/24301#issuecomment -377529520 @rsc द्वारा। मूल प्रस्ताव मानता है कि माइग्रेशन को उपनिर्देशिकाओं में जाने वाले लेखकों द्वारा नियंत्रित किया जाता है जब संगतता उनके लिए महत्वपूर्ण होती है, लेकिन निश्चित रूप से प्रेरणा गलत है। उन उपयोगकर्ताओं के लिए संगतता सबसे महत्वपूर्ण है, जिनका लेखकों के स्थानांतरण पर बहुत कम प्रभाव पड़ता है। और यह पुराने संस्करणों की मदद नहीं करता है। लिंक की गई टिप्पणी, अब #25069 भी, मॉड्यूल-जागरूक कोड का उपभोग और निर्माण करने में सक्षम होने के लिए पुराने "गो बिल्ड" में न्यूनतम परिवर्तन का प्रस्ताव करती है।

हम सिंगलटन पंजीकरण से कैसे निपट सकते हैं?

[ https://github.com/golang/go/issues/24301#issuecomment -374791885 @jimmyfrasche द्वारा।]

प्रतिक्रिया https://github.com/golang/go/issues/24301#issuecomment -377527249 @rsc द्वारा। पूरी तरह से अलग मॉड्यूल के बीच सिंगलटन पंजीकरण टकराव (जैसे एक ही पथ के http.Handle) प्रस्ताव से अप्रभावित हैं। एकल मॉड्यूल के विभिन्न प्रमुख संस्करणों के बीच टकराव के लिए, लेखक समन्वय की अपेक्षा करने के लिए विभिन्न प्रमुख संस्करण लिख सकते हैं, आमतौर पर v1 को v2 में कॉल करके, और फिर यह सुनिश्चित करने के लिए एक आवश्यकता चक्र का उपयोग करें कि v2 का उपयोग पुराने v1 के साथ नहीं किया जाता है। समन्वय के बारे में पता नहीं है।

हमें एक वर्जन कमांड कैसे स्थापित करना चाहिए?

[ https://github.com/golang/go/issues/24301#issuecomment -375106068 @leonklingele द्वारा।]

प्रतिक्रिया https://github.com/golang/go/issues/24301#issuecomment -377417565 @rsc द्वारा। संक्षेप में, गो गेट का उपयोग करें। हम अभी भी स्थापित स्थान के लिए $GOPATH/bin का उपयोग करते हैं। याद रखें कि $GOPATH अब डिफ़ॉल्ट रूप से $HOME/go हो जाता है, इसलिए कमांड $HOME/go/bin में समाप्त हो जाएंगे, और $GOBIN इसे ओवरराइड कर सकता है।

आयात पथ में v0, v1 क्यों छोड़े गए हैं? दूसरों को क्यों दिखना चाहिए? v0, v1 कभी क्यों नहीं दिखना चाहिए?

[ https://github.com/golang/go/issues/24301#issuecomment -374818326 @justinian द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -374831822 @jayschwa द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -375437150 @mrkanister द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376093912 @mrkanister द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376135447 @kaikuehne द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376141888 @kaikuehne द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376213693 @Merovius द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376247926 @kaikuehne द्वारा।]

ऊपर पूछे जाने वाले प्रश्न में जोड़ा गया।

प्रस्ताव में ज़िप फाइलों का उल्लेख क्यों किया गया है?

[ https://github.com/golang/go/issues/24301#issuecomment -374839409 @nightlyone द्वारा।]

एक ठोस इंटरचेंज प्रारूप को परिभाषित करने से पारिस्थितिकी तंत्र को लाभ होगा। यह प्रॉक्सी और अन्य टूलींग को सक्षम करेगा। साथ ही, हम संस्करण नियंत्रण के प्रत्यक्ष उपयोग को छोड़ रहे हैं ( इस पोस्ट के शीर्ष पर तर्क देखें)। यह दोनों विशिष्ट प्रारूप का वर्णन करने के लिए प्रेरित करते हैं। अधिकांश डेवलपर्स को ज़िप फ़ाइलों के बारे में बिल्कुल भी सोचने की आवश्यकता नहीं होगी; किसी भी डेवलपर को उनके अंदर देखने की जरूरत नहीं होगी, जब तक कि वे godoc.org जैसा कुछ नहीं बना रहे हों।

ज़िप बनाम टार के बारे में #24057 भी देखें।

प्रमुख संस्करणों को आयात पथ में नहीं डालने से DRY का उल्लंघन होता है?

[ https://github.com/golang/go/issues/24301#issuecomment -374831822 @jayschwa द्वारा।]

नहीं, क्योंकि एक आयात के शब्दार्थ को go.mod फ़ाइल के संदर्भ के बिना समझा जा सकता है। go.mod फ़ाइल केवल बारीक विवरण निर्दिष्ट कर रही है। प्रस्ताव के सिमेंटिक इंपोर्ट वर्जन सेक्शन का दूसरा भाग देखें, जो ब्लॉक कोट से शुरू होता है।

इसके अलावा, यदि आप बहुत अधिक सूखते हैं तो आप नाजुक प्रणालियों के साथ समाप्त हो जाते हैं। अतिरेक एक अच्छी बात हो सकती है। तो "उल्लंघन [आईएनजी] डीआरवाई" - यानी, सीमित रूप से खुद को दोहराना - हमेशा बुरा नहीं होता है। उदाहरण के लिए हम निर्देशिका में प्रत्येक .go फ़ाइल में पैकेज क्लॉज डालते हैं, न कि केवल एक। इसने ईमानदार गलतियों को जल्दी पकड़ लिया और बाद में बाहरी परीक्षण पैकेज (पैकेज x बनाम पैकेज x_test) को अलग करने का एक आसान तरीका बन गया। एक संतुलन बनाना है।

छद्म-संस्करणों में टाइमस्टैम्प के लिए किस समयक्षेत्र का उपयोग किया जाता है?

[ https://github.com/golang/go/issues/24301#issuecomment -374882685 @tpng द्वारा।]

यु.टी. सी। यह भी ध्यान दें कि आपको कभी भी स्वयं एक छद्म-संस्करण टाइप करने की आवश्यकता नहीं है। आप एक git प्रतिबद्ध हैश (या हैश उपसर्ग) टाइप कर सकते हैं और vgo उपयुक्त छद्म-संस्करण की गणना और स्थानापन्न करेगा।

क्या vgo गैर-गो निर्भरता को संबोधित करेगा, जैसे C या प्रोटोकॉल बफ़र्स? उत्पन्न कोड?

[ https://github.com/golang/go/issues/24301#issuecomment -374907338 @AlexRouSg द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376606788 @stevvooe द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -377186949 @ nim-nim द्वारा।]

गैर-गो विकास go कमांड का एक गैर-लक्ष्य बना हुआ है, इसलिए सी पुस्तकालयों के प्रबंधन के लिए समर्थन नहीं होगा और न ही प्रोटोकॉल बफर के लिए स्पष्ट समर्थन होगा।

उस ने कहा, हम निश्चित रूप से समझते हैं कि गो के साथ प्रोटोकॉल बफ़र्स का उपयोग करना बहुत कठिन है, और हम इसे अलग से संबोधित करना चाहते हैं।

जनरेट किए गए कोड के लिए अधिक सामान्य रूप से, एक वास्तविक क्रॉस-लैंग्वेज बिल्ड सिस्टम उत्तर है, विशेष रूप से क्योंकि हम नहीं चाहते कि प्रत्येक उपयोगकर्ता को सही जनरेटर स्थापित करने की आवश्यकता हो। लेखक के लिए जनरेटर चलाने और परिणाम की जांच करने के लिए बेहतर है।

क्या न्यूनतम संस्करण चयन डेवलपर्स को महत्वपूर्ण अपडेट प्राप्त करने से नहीं रोकेगा?

[ https://github.com/golang/go/issues/24301#issuecomment -375090551 @TocarIP द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -375985244 @ nim-nim द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -375992900 @Merovius द्वारा।]

अक्सर पूछे जाने वाले प्रश्न में जोड़ा गया।

### क्या मैं v1 विकसित करने के लिए मास्टर का उपयोग कर सकता हूं और फिर इसे v2 विकसित करने के लिए पुन: उपयोग कर सकता हूं?

[ https://github.com/golang/go/issues/24301#issuecomment -375248753 @mrkanister द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -375989173 @aarondl द्वारा।]

हां। अक्सर पूछे जाने वाले प्रश्न में जोड़ा गया।

इसके लिए समय-सीमा क्या है?

[ https://github.com/golang/go/issues/24301#issuecomment -375415904 @flibustenet द्वारा।]

@rsc द्वारा https://github.com/golang/go/issues/24301#issuecomment -377413777 में प्रतिक्रिया। संक्षेप में, लक्ष्य गो 1.11 में "प्रौद्योगिकी पूर्वावलोकन" लाना है; काम फ्रीज में कुछ हफ्तों तक जारी रह सकता है लेकिन आगे नहीं। जब तक प्रस्ताव स्वीकृत नहीं हो जाता और cmd/go की डेवलपमेंट कॉपी अपडेट नहीं हो जाती, तब तक आपको मिलने वाली हर लाइब्रेरी में go.mod जोड़ते हुए पीआर न भेजें।

मैं पश्चगामी-असंगत सुरक्षा परिवर्तन कैसे कर सकता हूँ?

[ https://github.com/golang/go/issues/24301#issuecomment -376236546 @buro9 द्वारा।]

@rsc द्वारा https://github.com/golang/go/issues/24301#issuecomment -377415652 में प्रतिक्रिया। संक्षेप में, गो 1 संगतता दिशानिर्देश प्रमुख संस्करण को टक्कर देने से बचने के लिए सुरक्षा कारणों से परिवर्तनों को तोड़ने की अनुमति देते हैं, लेकिन ऐसा करना हमेशा सबसे अच्छा होता है जिससे मौजूदा कोड जितना संभव हो सके काम करता रहे। उदाहरण के लिए, किसी फ़ंक्शन को न हटाएं। इसके बजाय, फ़ंक्शन को पैनिक करें या लॉग करें। केवल गलत तरीके से कॉल किए जाने पर घातक।

यदि एक रेपो उपनिर्देशिकाओं में अलग-अलग मॉड्यूल रखता है (जैसे, v2, v3, v4), तो क्या vgo अलग-अलग कमिट से मिक्स एंड मैच कर सकता है?

[ https://github.com/golang/go/issues/24301#issuecomment -376266648 @jimmyfrasche द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376270750 @AlexRouSg द्वारा।]

हां। यह प्रत्येक संस्करण टैग को समग्र भंडार के केवल एक उपट्री के अनुरूप मानता है, और यह प्रत्येक निर्णय के लिए एक अलग टैग (और इसलिए अलग प्रतिबद्धता) का उपयोग कर सकता है।

क्या होगा यदि परियोजनाएं सेवर का दुरुपयोग करती हैं? क्या हमें आयात पथों में छोटे संस्करणों की अनुमति देनी चाहिए?

[ https://github.com/golang/go/issues/24301#issuecomment -376640804 @pbx0 द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376645212 @powerman द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376650153 @pbx0 द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376660236 @powerman द्वारा।]

जैसा कि @powerman नोट करता है, हमें निश्चित रूप से एक एपीआई स्थिरता परीक्षक प्रदान करने की आवश्यकता है ताकि कम से कम परियोजनाओं को बताया जा सके कि वे स्पष्ट रूप से ब्रेकिंग परिवर्तन जारी करने वाले हैं।

क्या आप यह निर्धारित कर सकते हैं कि आपके पास बिल्ड में एक से अधिक पैकेज हैं या नहीं?

[ https://github.com/golang/go/issues/24301#issuecomment -376640804 @pbx0 द्वारा।]

परिणामी बाइनरी पर goversion -m का उपयोग करने के लिए सबसे आसान काम होगा। हमें बाइनरी के निर्माण के बिना एक ही चीज़ दिखाने के लिए एक विकल्प बनाना चाहिए।

प्रॉक्सी बनाम विक्रेता, विशेष रूप से ओपन सोर्स बनाम उद्यम पर vgo निर्भरता के बारे में चिंताएं।

[ https://github.com/golang/go/issues/24301#issuecomment -376925845 @joeshaw द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376936614 @kardianos द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376947621 @Merovius द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376979054 @joeshaw द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -376988873 @jamiethermo द्वारा।]
[ https://github.com/golang/go/issues/24301#issuecomment -377134575 @Merovius द्वारा।]

प्रतिक्रिया: [ https://github.com/golang/go/issues/24301#issuecomment -377411175 @rsc द्वारा।] प्रॉक्सी और विक्रेता दोनों का समर्थन किया जाएगा। उद्यम के लिए प्रॉक्सी बहुत महत्वपूर्ण है, और स्रोत खोलने के लिए विक्रेता बहुत महत्वपूर्ण है। हम एक विश्वसनीय मिरर नेटवर्क भी बनाना चाहते हैं, लेकिन केवल एक बार vgo बन जाता है।

GOPATH शब्दार्थ के आधार पर प्रोटोबिल्ड के बारे में चिंताएँ।

[ https://github.com/golang/go/issues/24301#issuecomment -377601170 @stevvooe द्वारा।]

प्रतिक्रिया [ https://github.com/golang/go/issues/24301#issuecomment -377602765 by @rsc] ने एक नए अंक में अधिक विवरण के लिए कहा, लेकिन ऐसा लगता है कि यह मुद्दा दायर नहीं किया गया है।

विशेष vgo-v1-lock टैग जोड़ने का सुझाव।

[ https://github.com/golang/go/issues/24301#issuecomment -377662150 @kybin द्वारा।]

यह पहली बार में आकर्षक लगता है लेकिन विशेष मामलों की ओर ले जाता है जो शायद लेने लायक नहीं हैं। https://github.com/golang/go/issues/24301#issuecomment -384344659 में पूर्ण प्रतिक्रिया।

विक्रेता के बिना एक गहरी निर्भरता कैसे पैच करता है?

[ https://github.com/golang/go/issues/24301#issuecomment -378255833 @chirino द्वारा।]

प्रतिक्रिया [ https://github.com/golang/go/issues/24301#issuecomment -378261916 @kardianos द्वारा।] एक बदलें निर्देश का उपयोग करके।

मॉड्यूल नाम बदलने के बारे में हम क्या करेंगे?

[ https://github.com/golang/go/issues/24301#issuecomment -379020339 @jimmyfrasche द्वारा।]

प्रतिक्रिया [ https://github.com/golang/go/issues/24301#issuecomment -379307176 @rsc द्वारा।]
ये वास्तविक, पूर्व-मौजूदा समस्याएं हैं जिन्हें वीजीओ प्रस्ताव सीधे संबोधित करने का प्रयास नहीं करता है, लेकिन स्पष्ट रूप से हमें उन्हें अंततः संबोधित करना चाहिए। कोड गायब होने का उत्तर कैशिंग प्रॉक्सी (दर्पण) के साथ-साथ उन पर भरोसा करने का कारण है; वह भविष्य का काम है। (या यदि आप चाहें तो शीर्ष-स्तरीय प्रोजेक्ट में वेंडरिंग का उपयोग करें।) कोड मूविंग का उत्तर मॉड्यूल या पैकेज रीडायरेक्ट की एक स्पष्ट अवधारणा को जोड़ना है, बहुत कुछ प्रकार के उपनाम टाइप रीडायरेक्ट हैं; वह भी भविष्य का काम है।

स्थानीय गिट सर्वर से कनेक्ट करने के बारे में क्या?

[ https://github.com/golang/go/issues/24301#issuecomment -383168012 @korya द्वारा।]

डायरेक्ट गिट एक्सेस को योजना में वापस जोड़ा गया है। #24915 देखें।

बाइनरी-ओनली पैकेज के बारे में क्या?

[ https://github.com/golang/go/issues/24301#issuecomment -382793364 @sdwarwick द्वारा।]

GOPATH/pkg में किसी प्रकार के आउट-ऑफ़-बैंड इंस्टालेशन की सीमित परिस्थितियों में केवल बाइनरी-ओनली पैकेज का ही समर्थन किया गया है। गो गेट ने कभी भी बाइनरी-ओनली पैकेज लाने और स्थापित करने का समर्थन नहीं किया है, और यह इसका समर्थन नहीं करना जारी रखेगा। एक बाइनरी-ओनली पैकेज केवल एक विशेष कंपाइलर और निर्भरता की एक विशेष प्रति के साथ काम करता है, जो गंभीर रूप से सीमित करता है कि इसे कितनी अच्छी तरह से समर्थित किया जा सकता है। इसके बजाय स्रोत कोड का उपयोग करने के लिए सही उत्तर लगभग हमेशा होता है।

क्या हमें go.mod फ़ाइल में पथ@संस्करण सिंटैक्स का उपयोग करना चाहिए?

[ https://github.com/golang/go/issues/24301#issuecomment -382791513 @sdwarwick द्वारा।]

यह #24119 है। यह पहली बार में एक अच्छा विचार लग रहा था, लेकिन सावधानीपूर्वक विचार करने के बाद, नहीं।

.

.

बदलें https://golang.org/cl/101678 इस मुद्दे का उल्लेख करता है: design: add 24301-versioned-go

यह प्रस्ताव प्रभावशाली है और मुझे इसके बारे में सब कुछ पसंद है। हालाँकि, मैंने मेलिंग सूची पर निम्नलिखित चिंताएँ पोस्ट कीं, लेकिन मुझे कभी कोई उत्तर नहीं मिला। इस बीच मैंने गोफ़र्स स्लैक चैनल में vgo के लिए अन्य लोगों द्वारा उठाए गए इस मुद्दे को देखा है और वहां भी कोई संतोषजनक उत्तर नहीं देखा है।

प्रेषक: https://groups.google.com/d/msg/golang-dev/Plc42fslQEk/rlfeNlazAgAJ

मैं एक पूर्व-वीजीओ दुनिया और एक वीजीओ दुनिया के बुरी तरह से चल रहे प्रवास पथ के बारे में सबसे ज्यादा चिंतित हूं। मुझे लगता है कि यदि प्रवास का सुगम मार्ग नहीं है तो हम गो समुदाय को बड़ी पीड़ा देने का जोखिम उठाते हैं। स्पष्ट रूप से माइग्रेशन पूरे समुदाय में परमाणु नहीं हो सकता है, लेकिन अगर मैंने अब तक वो सब कुछ समझ लिया है जो आपने vgo के बारे में लिखा है, तो ऐसी कुछ स्थितियां हो सकती हैं जहां मौजूदा व्यापक रूप से उपयोग किए जाने वाले पैकेज प्री-वीगो टूल और पोस्ट दोनों द्वारा उपयोग करने योग्य नहीं होंगे। -वीजीओ उपकरण।

विशेष रूप से, मेरा मानना ​​​​है कि मौजूदा पैकेज जिनमें पहले से ही प्रमुख संस्करणों के साथ रिलीज़ टैग किए गए हैं> = 2 vgo के साथ काम नहीं करेंगे जब तक कि उनके पास go.mod फ़ाइल न हो और एक /vN संवर्धित आयात पथ के साथ आयात भी किया जाता है। हालांकि, एक बार उन परिवर्तनों को भंडार में किए जाने के बाद यह पैकेज के पूर्व-वीजीओ उपयोग को तोड़ देगा।

यह एक अलग प्रकार की हीरा आयात समस्या पैदा करता प्रतीत होता है जिसमें हीरे के बीच में दो भाई पैकेज एक सामान्य v2+ पैकेज आयात करते हैं। मुझे चिंता है कि भाई-बहन के पैकेजों को परमाणु रूप से vgo आयात पथों को अपनाना चाहिए ताकि हीरे के शीर्ष पर पैकेज को एक निर्माण योग्य स्थिति में होने से रोका जा सके चाहे वह vgo या pre-vgo टूल का उपयोग कर रहा हो।

मैंने अभी तक ऐसा कुछ भी नहीं देखा है जो इस परिदृश्य में माइग्रेशन पथ की व्याख्या करता हो।

प्रस्ताव में कहा गया है:

मॉड्यूल-जागरूक बिल्ड गैर-मॉड्यूल-जागरूक पैकेज आयात कर सकते हैं (वे जो एक go.mod फ़ाइल वाले पेड़ के बाहर हैं) बशर्ते उन्हें v0 या v1 सिमेंटिक संस्करण के साथ टैग किया गया हो। वे फ़ॉर्म v0.0-yyyymmddhhmmss-commit के "छद्म-संस्करण" का उपयोग करके किसी विशिष्ट प्रतिबद्धता का भी उल्लेख कर सकते हैं। छद्म-संस्करण प्रपत्र अचिह्नित कमिट के साथ-साथ उन कमिट्स को संदर्भित करने की अनुमति देता है जो v2 या उससे ऊपर के सिमेंटिक संस्करणों के साथ टैग किए गए हैं, लेकिन जो सिमेंटिक आयात संस्करण सम्मेलन का पालन नहीं करते हैं।

लेकिन मुझे गैर-मॉड्यूल-जागरूक पैकेजों के लिए संक्रमणीय निर्भरता के साथ मॉड्यूल-जागरूक पैकेज आयात करने का कोई तरीका नहीं दिख रहा है> = v2. ऐसा लगता है कि पारिस्थितिक तंत्र के विखंडन का कारण अभी तक संबोधित नहीं किया गया है। एक बार जब आपके पास एक मॉड्यूल-जागरूक निर्भरता होती है जिसमें एक पैकेज होता है >= v2 कहीं न कहीं इसकी संक्रमणीय निर्भरता में जो इसके सभी आश्रितों को भी निर्माण को काम करने के लिए vgo अपनाने के लिए मजबूर करता है।

अपडेट करें: https://github.com/golang/go/issues/24454 भी देखें

गो प्रोजेक्ट ने इस सम्मेलन को परियोजना की शुरुआत से प्रोत्साहित किया है, लेकिन यह प्रस्ताव इसे और अधिक दांत देता है: पैकेज उपयोगकर्ताओं द्वारा उन्नयन केवल उस हद तक सफल या विफल होगा जब तक पैकेज लेखक आयात संगतता नियम का पालन करते हैं।

यह मेरे लिए स्पष्ट नहीं है कि इसका क्या अर्थ है और यह वर्तमान स्थिति से कैसे बदलता है। यह मुझे प्रतीत होता है, कि यह वर्तमान स्थिति का भी वर्णन करता है: यदि मैं इस नियम को तोड़ता हूं, तो अपग्रेड और गो-गेट विफल हो जाएगा। एआईयूआई वास्तव में कुछ भी नहीं बदलता है और मैं कम से कम "अधिक दांत" के उल्लेख को हटाने का सुझाव दूंगा। जब तक, निश्चित रूप से, इस अनुच्छेद का अर्थ यह नहीं है कि टूटने को दंडित करने/रोकने के लिए अतिरिक्त तंत्र हैं?

यह डेटाबेस ड्राइवरों और छवि प्रारूपों जैसी चीजों को भी प्रभावित करेगा जो खुद को init के दौरान किसी अन्य पैकेज के साथ पंजीकृत करते हैं, क्योंकि एक ही पैकेज के कई प्रमुख संस्करण ऐसा कर सकते हैं। यह मेरे लिए स्पष्ट नहीं है कि इसके सभी परिणाम क्या होंगे।

यदि प्रमुख संस्करण v0 या v1 है, तो संस्करण संख्या तत्व को छोड़ दिया जाना चाहिए; अन्यथा इसे शामिल किया जाना चाहिए।

ऐसा क्यों है? लिंक किए गए पोस्ट में, मैं केवल तर्क देखता हूं कि डेवलपर्स वर्तमान में वैकल्पिक पथ बनाने के लिए करते हैं जब वे ब्रेकिंग परिवर्तन करते हैं - लेकिन यह इस तथ्य के लिए एक समाधान है कि वे शुरू में टूलींग के लिए योजना नहीं बनाते हैं उनके लिए संस्करणों को संभालना नहीं है . यदि हम एक नए अभ्यास पर स्विच कर रहे हैं, तो क्यों न अनुमति दें और प्रोत्साहित करें (या यहां तक ​​कि अधिदेशित) कि नए vgo- सक्षम पैकेजों में v0 या v1 शामिल हैं? ऐसा लगता है कि संस्करणों की कमी वाले पथ केवल भ्रम के अवसर हैं। (क्या यह एक vgo- शैली पैकेज है? मॉड्यूल सीमा कहां है? आदि)

मैं आम तौर पर प्रस्ताव पसंद करता हूं, लेकिन आयात पथ में प्रमुख संस्करणों की आवश्यकता पर लटका हुआ हूं:

1. यह DRY सिद्धांत का उल्लंघन करता है जब प्रमुख संस्करण पहले से ही go.mod से जाना जा सकता है। अगर दोनों के बीच बेमेल हो जाए तो क्या होगा, यह समझना भी मुश्किल है।
2. v0 और v1 को अनुपस्थित रहने की अनुमति देने की अनियमितता भी सहज नहीं है।
3. निर्भरता को अपग्रेड करते समय सभी आयात पथ बदलना संभावित रूप से कठिन लगता है।

मैं समझता हूं कि moauth उदाहरण जैसे परिदृश्यों को व्यावहारिक होने की आवश्यकता है, लेकिन उम्मीद है कि अधिक सामान्य परिदृश्यों के लिए चीजों को सरल रखने की कीमत पर नहीं।

सबसे पहले: प्रभावशाली काम!

एक बात जो मेरे लिए पूरी तरह से अस्पष्ट है और थोड़ी सी अनिर्दिष्ट लगती है:

इस प्रस्ताव में ज़िप फ़ाइलें क्यों हैं?

लेआउट, बाधाएं और कई उपयोग के मामले जैसे कि इसे कब बनाया गया और इसका जीवन चक्र कैसे प्रबंधित किया जाता है, किन उपकरणों को समर्थन की आवश्यकता है, लिंटर जैसे उपकरणों को इसके साथ कैसे बातचीत करनी चाहिए, यह भी स्पष्ट नहीं है, क्योंकि वे प्रस्ताव में शामिल नहीं हैं।

इसलिए मैं सुझाव दूंगा कि या तो बाद में, फिर भी अलिखित, प्रस्ताव को यहां देखें और ज़िप शब्द को हटा दें या प्रस्ताव पाठ से पूरे हिस्से को हटा दें, यदि आप इस प्रस्ताव के दायरे में इस पर चर्चा नहीं करने की योजना बनाते हैं।

इस पर बाद में चर्चा करने से भिन्न श्रोताओं को भी यहाँ बेहतर योगदान करने में मदद मिलती है।

छद्म-संस्करण (v0.0-yyymmddhhmmss-commit) में टाइमस्टैम्प के लिए किस टाइमज़ोन का उपयोग किया जाता है?

संपादित करें:
यह यूटीसी में है जैसा कि https://research.swtch.com/vgo-module में बताया गया है।

@rsc क्या आप C निर्भरता को संबोधित करेंगे?

ऐसा लगता है कि न्यूनतम संस्करण चयन गैर-ब्रेकिंग परिवर्तनों के प्रसार को बहुत धीमा कर देता है। मान लीजिए कि हमारे पास एक लोकप्रिय पुस्तकालय फू है, जिसका उपयोग ए, बी और सी परियोजनाओं द्वारा किया जाता है। कोई व्यक्ति एपीआई को बदले बिना फू के प्रदर्शन में सुधार करता है। वर्तमान में अपडेट प्राप्त करना एक ऑप्ट-आउट प्रक्रिया है। यदि प्रोजेक्ट ए ने फू को वेंडर किया, लेकिन बी और सी ने नहीं किया, तो लेखक को केवल ए को वेंडर निर्भरता के अपडेट के साथ पीआर भेजने की जरूरत है। इसलिए गैर-एपीआई ब्रेकिंग योगदान का समुदाय पर उतना प्रभाव नहीं पड़ेगा और वर्तमान की तुलना में कुछ हद तक निराश हैं परिस्थिति। सुरक्षा अद्यतनों के लिए यह और भी अधिक समस्याग्रस्त है। यदि कुछ परित्यक्त/छोटी/बहुत सक्रिय परियोजना (लाइब्रेरी नहीं) पुराने संस्करण पर प्रत्यक्ष निर्भरता की घोषणा करती है जैसे कि x/क्रिप्टो उस परियोजना के सभी उपयोगकर्ता x/क्रिप्टो में दोष के प्रति संवेदनशील होंगे जब तक कि परियोजना अद्यतन नहीं हो जाती, संभावित रूप से हमेशा के लिए। वर्तमान में ऐसी परियोजनाओं के उपयोगकर्ताओं को नवीनतम निश्चित संस्करण प्राप्त होगा, जिससे सुरक्षा की स्थिति और खराब हो जाती है। IIRC कुछ सुझाव थे कि इसे maillist चर्चा में कैसे ठीक किया जाए, लेकिन, जहाँ तक मैं बता सकता हूँ कि यह प्रस्ताव इसका उल्लेख नहीं करता है।

आईआईआरसी कुछ सुझाव थे कि मेललिस्ट चर्चा में [सुरक्षा पैच प्राप्त करना] कैसे ठीक किया जाए, लेकिन, जहां तक ​​​​मैं बता सकता हूं कि इस प्रस्ताव में इसका उल्लेख नहीं है।

go get -p का उल्लेख देखें।

गो गेट -पी का उल्लेख देखें।

मैंने इसे देखा है, लेकिन यह अभी भी एक ऑप्ट-इन तंत्र है।
मैं पुस्तकालय के लिए सभी पिछली रिलीज को असुरक्षित के रूप में चिह्नित करने के तरीके के बारे में सोच रहा था, ताकि उपयोगकर्ता को गो गेट -पी चलाने के लिए मजबूर किया जा सके या असुरक्षित पुस्तकालय में स्पष्ट रूप से ऑप्ट-इन किया जा सके।

यदि go get के लिए समर्थन जैसा कि हम आज जानते हैं, इसे हटा दिया जाएगा और अंततः हटा दिया जाएगा, तो गो बायनेरिज़ को लाने और स्थापित करने का अनुशंसित तरीका क्या है? क्या इसके लिए पहले परियोजना में git clone 'की आवश्यकता होती है, उसके बाद बाइनरी को स्थापित करने के लिए मैन्युअल go install की आवश्यकता होती है?
यदि $GOPATH को हटा दिया जाता है, तो इन बायनेरिज़ को कहाँ स्थापित किया जाएगा?

@leonklingele : मेरी समझ से, इसके विपरीत, go get को बहिष्कृत नहीं किया जाएगा।
इसे स्वचालित और पारदर्शी संस्करण क्षमताओं के साथ बढ़ाया जाएगा। यदि कोई प्रोजेक्ट किसी टैग न किए गए प्रोजेक्ट पर निर्भर करता है, तो यह केवल मास्टर और "विक्रेता" को इस सटीक संस्करण में ले जाएगा।
फिर से, मेरी अपनी समझ vgo के बारे में थोड़ा सा पढ़ने से। मैं अभी भी इसे पूरी तरह समझने की प्रक्रिया में हूं।

मुझे आश्चर्य है कि यह सामान्य रूप से गिट भंडार के साथ काम करने के प्रवाह को कैसे प्रभावित करेगा, प्रस्ताव से इस वाक्य पर भी निर्माण:

यदि प्रमुख संस्करण v0 या v1 है, तो संस्करण संख्या तत्व को छोड़ दिया जाना चाहिए; अन्यथा इसे शामिल किया जाना चाहिए।

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

मुझे पता है कि डिफ़ॉल्ट शाखा को master से v2 में बदला जा सकता है, लेकिन यह अभी भी मुझे अद्यतन करने के लिए कार्य के साथ छोड़ देता है कि हर बार जब मैं एक नया प्रमुख संस्करण जारी करता हूं। व्यक्तिगत रूप से, मेरे पास master और एक v1 शाखा होगी, लेकिन मुझे यकीन नहीं है कि यह वास्तव में प्रस्ताव के अनुरूप कैसे होगा।

नई प्रमुख रिलीज़ मंथन का कारण बनती हैं। जब भी आप कोई नई रिलीज़ करते हैं, यदि आपको अपने Git रिपॉजिटरी (डिफ़ॉल्ट शाखा) में एक सेटिंग बदलनी पड़ती है, तो यह आपके पुस्तकालय के उपयोगकर्ताओं द्वारा नए संस्करण में स्विच करने की तुलना में बहुत मामूली लागत है।

मुझे लगता है कि प्रस्ताव का यह पहलू सही प्रोत्साहन निर्धारित करता है: यह अपस्ट्रीम लेखकों को यह सोचने के लिए प्रोत्साहित करता है कि वे समग्र पारिस्थितिकी तंत्र मंथन को कम करते हुए, पिछड़े-संगत तरीके से परिवर्तन कैसे कर सकते हैं।

अब मेरे पास एक मास्टर और एक v2 शाखा है

इसके बजाय आप मास्टर में v2/ उपनिर्देशिका बना सकते हैं।

@mrkanister

इसके बजाय मेरे पास एक मास्टर और एक v1 शाखा होगी, लेकिन मुझे यकीन नहीं है कि यह प्रस्ताव के अनुरूप कैसे होगा।

https://research.swtch.com/vgo-module vgo की मेरी समझ के अनुसार संस्करणों की पहचान करने के लिए टैग शाखाओं का उपयोग नहीं करता है। इसलिए जब तक टैग सही शाखा की ओर इशारा करते हैं और प्रतिबद्ध हैं, तब तक आप मास्टर और शाखा पर विकास को v1 से दूर रख सकते हैं।

नई प्रमुख रिलीज़ मंथन का कारण बनती हैं। जब भी आप कोई नई रिलीज़ करते हैं, यदि आपको अपने Git रिपॉजिटरी (डिफ़ॉल्ट शाखा) में एक सेटिंग बदलनी पड़ती है, तो यह आपके पुस्तकालय के उपयोगकर्ताओं द्वारा नए संस्करण में स्विच करने की तुलना में बहुत मामूली लागत है।

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

सामान्य प्रोग्रामर वर्कफ़्लो सम्मेलनों के विरुद्ध जाना कोई मामूली कीमत नहीं है।

परंपरागत पथ का पालन न करना कभी-कभी नवाचार के लिए आवश्यक शर्त होती है।

अगर मैं प्रस्ताव के कुछ हिस्सों को सही ढंग से समझता हूं, तो आपको कभी भी उपनिर्देशिका या नई शाखा बनाने की ज़रूरत नहीं है। आपके पास संभावित रूप से केवल एक मास्टर शाखा हो सकती है और गिट आपके रेपो को 0.0, से 1.0, से 2.0 तक टैग कर सकती है और जब तक आप अपने पुस्तकालय के लिए सही आयात पथ पर अपने go.module को अपडेट करना सुनिश्चित करते हैं।

@mrkanister मुझे लगता है, देव के लिए, आपका क्लोन आपके मास्टर (या कोई देव शाखा) है और इसे इंगित करने के लिए "प्रतिस्थापन" निर्देश (vgo-tour देखें) का उपयोग करें। (अगर मैं समझता हूं कि आपका क्या मतलब है, निश्चित नहीं)।

@rsc मैं आपसे रोड मैप के बारे में और अधिक सटीक होने के लिए कहना चाहता हूं और अब हमें क्या करना चाहिए।
क्या यह गो नीति का पालन करेगा और 3 महीने (अभी 2) पर फ़्रीज़ वीगो की सुविधा देगा?
क्या अब हमें अपने तीर्थयात्री के डंडे के साथ जाना चाहिए और प्रत्येक libs अनुरक्षक को एक go.mod फ़ाइल जोड़ने के लिए कहना चाहिए या क्या हमें प्रस्ताव को आधिकारिक रूप से स्वीकार किए जाने की प्रतीक्षा करनी चाहिए (यह सुनिश्चित करने के लिए कि नाम और वाक्य-विन्यास नहीं बदलेगा)?

@flibustenet टूल्स 1.0 नीति द्वारा कवर नहीं किए जाते हैं, इसलिए कुछ भी बदल सकता है।

https://golang.org/doc/go1compat

अंत में, गो टूलचेन (कंपाइलर, लिंकर्स, बिल्ड टूल्स, और इसी तरह) सक्रिय विकास के अधीन है और व्यवहार बदल सकता है। इसका मतलब है, उदाहरण के लिए, कि स्क्रिप्ट जो स्थान और उपकरणों के गुणों पर निर्भर करती हैं, उन्हें एक बिंदु रिलीज द्वारा तोड़ा जा सकता है।

प्रस्ताव से भी

योजना, प्रस्ताव अनुमोदन के अधीन, एक वैकल्पिक सुविधा के रूप में गो 1.11 में मॉड्यूल समर्थन जारी करना है जो अभी भी बदल सकता है। गो 1.11 रिलीज उपयोगकर्ताओं को "असली के लिए" मॉड्यूल का उपयोग करने और महत्वपूर्ण प्रतिक्रिया प्रदान करने का मौका देगा। भले ही विवरण बदल सकते हैं, भविष्य के रिलीज गो 1.11-संगत स्रोत पेड़ों का उपभोग करने में सक्षम होंगे। उदाहरण के लिए, गो 1.12 समझ जाएगा कि गो 1.11 गो.मोड फ़ाइल सिंटैक्स का उपभोग कैसे करें, भले ही तब तक फ़ाइल सिंटैक्स या फ़ाइल का नाम भी बदल गया हो। बाद की रिलीज़ में (जैसे, गो 1.12), हम घोषित करेंगे कि मॉड्यूल समर्थन पूरा हो गया है। बाद की रिलीज़ में (जैसे, गो 1.13), हम गैर-मॉड्यूल के गो गेट के लिए समर्थन समाप्त कर देंगे। GOPATH में काम करने के लिए समर्थन अनिश्चित काल तक जारी रहेगा।

प्रतिपुष्टि के लिए धन्यवाद।

@AlexRouSg

https://research.swtch.com/vgo-module vgo की मेरी समझ के अनुसार संस्करणों की पहचान करने के लिए टैग शाखाओं का उपयोग नहीं करता है। इसलिए जब तक टैग सही शाखा की ओर इशारा करते हैं और प्रतिबद्ध हैं, तब तक आप मास्टर और शाखा पर विकास को v1 से दूर रख सकते हैं।

आप सही हैं, यह पहले की तरह काम करना जारी रखेगा (सुनिश्चित करने के लिए बस दो बार चेक किया गया), अच्छी पकड़!

उस रास्ते से, जिस चीज को मैं (और स्पष्ट रूप से अन्य) समझ नहीं पा रहा हूं वह v1 पैकेज को अस्तित्व में रखने की अनुमति देने के पीछे तर्क है। मैंने आयात के अंत में /v1 का उपयोग करके एक आयात करने का प्रयास किया और इसे आयात किए जा रहे पैकेज के go.mod में भी जोड़ा, लेकिन vgo नामक फ़ोल्डर की तलाश करेगा v1 इसके बजाय

@mrkanister
मुझे लगता है कि आयात पथ में v1 या v0 की अनुमति नहीं देने का मुख्य कारण यह सुनिश्चित करना है कि पैकेज के प्रत्येक संगत संस्करण के लिए केवल एक आयात पथ है।
/v1 के बजाय सादे आयात पथ का उपयोग करना संक्रमण को आसान बनाना है, इसलिए अंत में /v1 जोड़ने के लिए आपको अपने सभी आयात पथों को अपडेट करने की आवश्यकता नहीं है।

नमस्ते,

जबकि प्रस्ताव में बहुत सारे बिंदु स्वागत से अधिक हैं और समय के साथ उभरे बड़े गो कोडबेस को वश में करने में मदद करेंगे, "न्यूनतम संस्करण का उपयोग करें" नियम काफी हानिकारक है:

• आप चाहते हैं कि आपका कोड पारिस्थितिकी तंत्र प्रगति करे। इसका मतलब है कि आप चाहते हैं कि लोग नए संस्करणों का परीक्षण और उपयोग करें और जमा होने से पहले ही समस्याओं का पता लगा लें।
• आप चाहते हैं कि नए मॉड्यूल रिलीज़ हों, जो सुरक्षा समस्याओं को ठीक करें, जल्द से जल्द लागू किया जाए
• आप नए मॉड्यूल रिलीज़ को लागू करने में सक्षम होना चाहते हैं, जो सुरक्षा समस्याओं को जल्द से जल्द ठीक करते हैं। उन्हें हमेशा सुरक्षा सुधारों पर टैग नहीं किया जाता है। यदि आप नई रिलीज़ से बचते हैं तो आप उन सुधारों से भी बचते हैं
• यहां तक ​​​​कि जब एक नई रिलीज में सुरक्षा सुधार शामिल नहीं होते हैं, तो इसके परिवर्तनों को जल्दी लागू करने का मतलब है कि जब अगली रिलीज जिसमें सुरक्षा सुधार शामिल हैं, प्रकाशित होने पर पशु चिकित्सक में कम बदलाव होंगे (और आखिरी चीज जो आप चाहते हैं जब ऐसी रिलीज प्रकाशित हो और आपको इसकी आवश्यकता हो त्वरित रहें उन मध्यस्थ परिवर्तनों में फंसना है जिन्हें आपने पहले नहीं देखा था)।
• मध्यस्थ रिलीज लागू करना केवल हानिकारक है यदि वे कॉम्पेट तोड़ते हैं, और उन्हें कॉम्पेट तोड़ना नहीं चाहिए, और यदि वे इसका पता लगाने के लिए बेहतर कॉम्पेट तोड़ते हैं और मॉड्यूल लेखकों को अगली रिलीज के लिए आदत बनाने से पहले बताते हैं तो आप अंततः पूरी तरह से करेंगे ज़रूरत।
• आप नहीं चाहते कि पुराने कोड आपको नीचे खींचे क्योंकि वे अभी भी एक प्राचीन निर्भरता संस्करण निर्दिष्ट करते हैं और किसी को अपने मैनिफेस्ट को अपडेट करने का समय नहीं मिलता है। एक प्रमुख रिलीज के नवीनतम संस्करण का उपयोग अन्य कोड पारिस्थितिक तंत्र में इस सामाजिक आवश्यकता को पूरा करता है: देवों को नवीनतम संस्करण का परीक्षण करने के लिए मजबूर करें और बहुत देर होने तक स्थगित न करें क्योंकि "अधिक महत्वपूर्ण" (यानी अधिक मजेदार) चीजें हैं।
  
  
  
  • सिद्धांत रूप में, आप मॉड्यूल संस्करणों की एक असीमित संख्या को शिप कर सकते हैं ताकि कोड का प्रत्येक टुकड़ा अपने इच्छित का उपयोग कर सके, अभ्यास में जैसे ही आप दो मॉड्यूल बनाते हैं जो एक ही डिपो का उपयोग करते हैं, आपको एक संस्करण चुनना होगा ताकि आपका अधिक जटिल हो सॉफ़्टवेयर है, जितना कम आप कई संस्करणों को सहन करेंगे। तो आप जल्द ही पुरानी समस्या पर आ गए कि स्ट्रगलर के साथ क्या करना है जो पूरे काफिले को धीमा कर देता है। मैं कभी भी ऐसी मानव संस्कृति से नहीं मिला जिसने स्ट्रगलरों को यह कहकर इस समस्या का प्रबंधन किया "तुम सही हो, जितनी धीमी गति से जाओगे, हर कोई तुम्हारा इंतजार करेगा"। यह अच्छा और परोपकारी हो सकता है लेकिन यह उत्पादक नहीं है।
  
  

मानव जड़ता से लड़ना कठिन और दर्दनाक है, और हम इससे लड़ रहे हैं क्योंकि प्रगति के लिए इसकी आवश्यकता है क्योंकि यह सुखद नहीं है। सुखद उपकरण बनाना जो समस्या से बचते हैं और मनुष्यों को कुछ और विलंब करने के लिए उकसाते हैं, यह बिल्कुल भी मददगार नहीं है, यह केवल परियोजना अवसादन और तकनीकी ऋण संचय में तेजी लाएगा। जीथब पर पहले से ही दर्जनों गो प्रोजेक्ट हैं, जिनमें से अधिकांश लेखक को समर्पित हैं, जो अपने उपयोगकर्ताओं को अपग्रेड करने के लिए भीख माँगते हैं क्योंकि उन्होंने महत्वपूर्ण सुधार किए हैं, सबसे पुरानी रिलीज़ में चूक करने से समस्या सामान्य हो जाएगी।

एक अच्छा नियम होगा "नवीनतम रिलीज का उपयोग करें जो प्रमुख रिलीज से मेल खाता है, हर मध्यस्थ प्रतिबद्धता नहीं"। यह आगे बढ़ने और स्थिरता के लिए एक समझौता होगा। यह मूल प्रोजेक्ट को कमांड में रखता है, जो कोडबेस को सबसे अच्छी तरह जानता है, और यह तय कर सकता है कि अपने उपयोगकर्ताओं को एक नई कोड स्थिति में कब स्विच करना है।

मेरा अनुत्तरित प्रश्न मेलिंग सूची से कॉपी किया गया:

हम उम्मीद करते हैं कि अधिकांश डेवलपर्स सामान्य "प्रमुख शाखा" सम्मेलन का पालन करना पसंद करेंगे, जिसमें विभिन्न प्रमुख संस्करण विभिन्न शाखाओं में रहते हैं। इस मामले में, एक v2 शाखा में रूट निर्देशिका में एक go.mod होगा जो v2 को दर्शाता है, जैसे:

ऐसा लगता है कि उपनिर्देशिकाएं हैं और यह प्रमुख शाखा सम्मेलन है जो दोनों vgo द्वारा समर्थित हैं। मेरे वास्तविक अनुभव में कोई भी भंडार गो या अन्य भाषाओं में इस सम्मेलन का पालन नहीं करता है (वास्तव में gopkg.in द्वारा मजबूर लोगों के अलावा किसी अन्य के बारे में नहीं सोच सकता जो इन दिनों अपेक्षाकृत अप्रयुक्त लगता है)। मास्टर शाखा जो भी नवीनतम है और इसके इतिहास में v2.3.4 टैग हैं। टैग सब कुछ अलग करने के लिए मौजूद हैं (केवल मामूली संस्करण नहीं)। यदि पुराने संस्करण को पैच करना आवश्यक है, तो अंतिम v1 टैग से अस्थायी रूप से एक शाखा बनाई जाती है, धक्का दिया जाता है, एक नया टैग धक्का दिया जाता है, और शाखा को संक्षेप में हटा दिया जाता है। संस्करणों के लिए कोई शाखा नहीं है, यह सिर्फ वर्तमान मास्टर/देव/फीचर शाखाएं + संस्करण टैग हैं। मुझे पता है कि गिट में "सब कुछ एक रेफरी है", लेकिन अन्य वीसीएस के लिए भेद उतना अस्पष्ट नहीं हो सकता है।

ऐसा कहने के बाद, मैंने ऊपर वर्णित वर्कफ़्लो को vgo के साथ परीक्षण किया है (केवल टैग हैं जो v2.0.0, v2.0.1 और कोई शाखा नहीं कहते हैं) और ऐसा लगता है कि यह काम करता है। तो मेरा सवाल है: हालांकि यह अब काम करता है, क्या इसका इरादा है? जैसा कि यह ब्लॉग में अन्य दो वर्कफ़्लो के रूप में पूरी तरह से वर्णित नहीं लगता है, और मैं यह सुनिश्चित करना चाहता हूं कि v2/v3 के बिना काम करना ... शाखा आकस्मिक कार्यक्षमता नहीं है जो गायब हो जाएगी जैसा कि मैंने ऊपर बताया है मैंने कभी नहीं किया है यह देखा (या अन्य) पोस्ट में वर्णित वर्कफ़्लो को किसी के द्वारा बड़े पैमाने पर अपनाया जाना (विशेषकर गो समुदाय के बाहर)।

बेशक मेरा तर्क वरीयता और उपाख्यानों पर आ रहा है, इसलिए यदि आवश्यक हो तो मैं इसे सभी भाषाओं में साबित करने के लिए कुछ रेपो-स्क्रैपिंग करने को तैयार हूं। अब तक मैं वास्तव में प्रस्ताव पदों को पसंद करता हूं और आम तौर पर परिवर्तनों के साथ बोर्ड पर हूं, साथ में पालन करना और vgo के साथ खेलना जारी रखूंगा।

आपकी सभी कोशिशों के लिए शुक्रिया।

क्या कोई स्पष्ट कर सकता है कि एमवीएस के लिए प्रस्तावित वैकल्पिक मॉडल अपग्रेड-ताल में सुधार के लिए कैसे काम करेगा? क्योंकि यह मेरे लिए स्पष्ट नहीं है। वैकल्पिक (व्यापक रूप से प्रयुक्त) मॉडल के बारे में मेरी समझ है

• डेवलपर दस्तकारी मेनिफेस्ट बनाता है, सभी उपयोग की गई निर्भरताओं के लिए संस्करण बाधाओं को सूचीबद्ध करता है
• डेवलपर $solver चलाता है, जो एक लॉकफ़ाइल बनाता है, जो निर्दिष्ट बाधाओं को पूरा करने वाले सकर्मक निर्भरता संस्करणों के कुछ चुने हुए सबसेट को सूचीबद्ध करता है
• यह लॉकफाइल प्रतिबद्ध हो जाता है और प्रतिलिपि प्रस्तुत करने योग्य बिल्ड की गारंटी के लिए निर्माण और स्थापना समय पर उपयोग किया जाता है
• जब एक निर्भरता का एक नया संस्करण जारी किया जाता है और उपयोग किया जाता है, तो डेवलपर संभावित रूप से मेनिफेस्ट को अपडेट करता है, सॉल्वर को फिर से चलाता है और नई लॉकफाइल की सिफारिश करता है

जैसा कि मैं समझता हूं कि प्रस्तावित एमवीएस मॉडल है

• डेवलपर मॉड्यूल में आयात पथों के सेट के आधार पर go.mod स्वत: उत्पन्न करता है, किसी भी संक्रमणीय निर्भरता के वर्तमान नवीनतम संस्करण का चयन करता है
• go.mod प्रतिबद्ध हो जाता है और बिल्ड और इंस्टॉल समय पर संस्करणों पर निचली सीमा प्राप्त करने के लिए उपयोग किया जाता है। एमवीएस प्रतिलिपि प्रस्तुत करने योग्य निर्माण की गारंटी देता है
• जब एक निर्भरता का एक नया संस्करण जारी किया जाता है और उपयोग किया जाता है, तो डेवलपर vgo get -u चलाता है, जो संक्रमणीय निर्भरताओं के नवीनतम संस्करण प्राप्त करता है और नई निचली सीमाओं के साथ go.mod को अधिलेखित कर देता है। इसके बाद सबमिट हो जाता है।

ऐसा लगता है कि मुझे किसी चीज़ को पूरी तरह से नज़रअंदाज़ करना चाहिए और यह मददगार होगा अगर कोई बताए कि क्या है। क्योंकि इस समझ का अर्थ यह प्रतीत होता है कि देय लॉकफाइल्स सटीक संस्करणों को निर्दिष्ट करते हैं और जिन्हें वास्तविक निर्माण में उपयोग किया जा रहा है, एमवीएस अपग्रेड-ताल बढ़ाने में बेहतर है - क्योंकि यह सामान्य रूप से संस्करणों को वापस रखने की अनुमति नहीं देता है।

स्पष्ट रूप से मुझे कुछ याद आ रहा है (और लगभग 5 मी में बेवकूफी महसूस होगी), वह क्या है?

@tpng

/v1 के बजाय सादे आयात पथ का उपयोग करना संक्रमण को आसान बनाना है, इसलिए अंत में /v1 जोड़ने के लिए आपको अपने सभी आयात पथों को अपडेट करने की आवश्यकता नहीं है।

यह वास्तव में आवश्यक नहीं होना चाहिए। मुझे एक उदाहरण देने दें:

एक उपयोगकर्ता वर्तमान में उपयोग कर रहा है उदाहरण के लिए v1.0.0 एक पुस्तकालय का, एक निर्भरता प्रबंधक द्वारा पिन किया गया और अपस्ट्रीम रिपॉजिटरी में टैग। अब अपस्ट्रीम एक go.mod बनाने का फैसला करता है और मॉड्यूल को /v1 भी कहता है। इसके परिणामस्वरूप एक नई प्रतिबद्धता और एक नया टैग (जैसे v1.0.1 ) होना चाहिए। चूंकि vgo कभी भी निर्भरता को अपने आप अपडेट करने का प्रयास नहीं करेगा, इससे उपयोगकर्ता के लिए कुछ भी नहीं टूटना चाहिए, लेकिन वह आयात पथ को बदलकर भी सचेत रूप से अपडेट कर सकता है (पीआर vgo ऐसा कर सकता है उसके लिए)।

मुझे लगता है कि आयात पथ में v1 या v0 की अनुमति नहीं देने का मुख्य कारण यह सुनिश्चित करना है कि पैकेज के प्रत्येक संगत संस्करण के लिए केवल एक आयात पथ है।

हां, मुझे लगता है कि पुस्तकालय के नए उपयोगकर्ताओं को भ्रमित न करने के लिए मैं वास्तव में उस बिंदु को देख सकता हूं।

यदि प्रमुख संस्करण v0 या v1 है, तो संस्करण संख्या तत्व को छोड़ दिया जाना चाहिए; अन्यथा इसे शामिल किया जाना चाहिए।

क्या कोई कृपया इसके पीछे तर्क समझा सकता है? मैं एक पुस्तकालय के उपयोगकर्ता के रूप में क्या करूँ, जब मैं अभी तक v1 का उपयोग नहीं करना चाहता, क्योंकि इसने एक ब्रेकिंग परिवर्तन पेश किया, जो सिमेंटिक वर्जनिंग (नया प्रमुख संस्करण) के साथ पूरी तरह से ठीक होगा?

मैं केवल संस्करण 1 से पहले के संस्करण को छोड़ना पसंद करूंगा, जो एक अस्थिर/अधूरे पैकेज को इंगित करता है। संस्करण 1 से शुरू करके, मैं इस तथ्य पर भरोसा करने में सक्षम होना चाहता हूं कि मुझे एक स्थिर रिलीज मिलती है। आयात पथ में v1 को छोड़ना भ्रमित करने वाला है, क्योंकि आप नहीं जानते कि आप कभी-बदलने वाली लाइब्रेरी या स्थिर संस्करण को ट्रैक कर रहे हैं या नहीं। मुझे लगता है कि यह सिमेंटिक वर्जनिंग स्कीम के साथ भी अच्छी तरह से काम नहीं करता है, जहां v1 पहले स्थिर रिलीज को इंगित करता है, जिसका उपयोग उस संस्करण को 0.x संस्करणों से स्पष्ट रूप से अलग करने के लिए किया जाता है।

@kaikuehne

मैं एक पुस्तकालय के उपयोगकर्ता के रूप में क्या करूँ, जब मैं अभी तक v1 का उपयोग नहीं करना चाहता, क्योंकि इसने एक ब्रेकिंग परिवर्तन पेश किया, जो सिमेंटिक वर्जनिंग (नया प्रमुख संस्करण) के साथ पूरी तरह से ठीक होगा?

जहां तक ​​मुझे समझ में आया, vgo कभी भी निर्भरता को अपने आप अपडेट नहीं करेगा, यहां तक ​​कि पैच संस्करण तक भी नहीं, बल्कि इसे आपके लिए एक सचेत निर्णय के रूप में छोड़ दें। इसलिए यदि आप किसी पुस्तकालय के v0.4.5 पर निर्भर हैं (जिसमें इसके लिए एक टैग है), तो आप सैद्धांतिक रूप से इसे हमेशा के लिए उपयोग करना जारी रख सकते हैं। आप अपनी go.mod फ़ाइल में संस्करण को मैन्युअल रूप से पिन करने में भी सक्षम होंगे।

क्या होगा यदि मेरे द्वारा उपयोग की जाने वाली अन्य निर्भरता उसी पैकेज पर निर्भर करती है, लेकिन संस्करण v1? दोनों पैकेज समान आयात पथ का उपयोग करके आयात किए जाते हैं। क्या उन्हें एक ही बाइनरी में संकलित करते समय कोई संघर्ष नहीं होता है?

अगर हमें आयात पथ का हिस्सा बनने के लिए v1 की आवश्यकता होती है, तो दोनों को अलग-अलग पैकेज के रूप में माना जाएगा, जो कि वे हैं।

@kaikuehne तो यह काम करने वाले न्यूनतम सामान्य संस्करण में अपडेट होगा। (मेरी समझ से)

@kaikuehne मैं आपके तर्क को नहीं समझता। आप v0 का उपयोग कर रहे हैं, इसलिए संभवतः आप परिवर्तनों को तोड़ने के साथ ठीक हैं; यह एक समस्या क्यों होगी यदि v1 टूट जाता है, यह देखते हुए कि आप पहले से ही एक ऐसे संस्करण का उपयोग कर रहे हैं जिसमें स्थिरता की कोई गारंटी नहीं है? इसके अलावा, मान लें कि ब्रेकिंग चेंज के साथ v0.1->v1.0 से जाने के बजाय, अपस्ट्रीम ब्रेक को v0.2 में जोड़ देगा और फिर एक (नॉन-ब्रेकिंग) v1.0 जारी करेगा। यह अर्थपूर्ण संस्करणों के आस-पास अपेक्षाओं के भीतर अच्छी तरह से प्रतीत होता है, लेकिन आपके लिए बिल्कुल समान मात्रा में परिश्रम होगा (इससे कोई फर्क नहीं पड़ता कि पैकेज प्रबंधक का उपयोग किया गया है)। यानी मैं वास्तव में समझ नहीं पा रहा हूं कि कैसे "लेखक ने अचानक अपने एपीआई को तोड़ना बंद कर दिया" एक ऐसी समस्या का गठन करता है जो प्री-1.0 रिलीज के उपयोग के कारण नहीं होता है।

दूसरे शब्दों में कहें तो: v0.x का उपयोग करके, आप स्वीकार कर रहे हैं कि v0.(x+1) आपको अपना कोड ठीक करने के लिए बाध्य कर सकता है। यह एक समस्या क्यों है यदि v0.(x+1) को इसके बजाय v1.0 कहा जाता है?

चर्चा बिंदु 4 पर: स्पष्ट रूप से आयात संगतता नियम को अपनाना और "नया पैकेज पुराने पैकेज के साथ पीछे की ओर संगत होना चाहिए" ...

मेरे मामले में मेरे पास एक सुरक्षा पैकेज है https://github.com/microcosm-cc/bluemonday और मैंने हाल ही में (पिछले साल के अंत में) एक परिदृश्य था जिसमें मैंने सीखा था कि एक सार्वजनिक func मूल रूप से उद्देश्य के लिए उपयुक्त नहीं था। इसलिए मैंने इसे हटा दिया।

इस प्रस्ताव के तहत, अगर मैंने func को हटा दिया तो यह संस्करण को टक्कर देगा और असुरक्षित/असुरक्षित कोड कभी नहीं हटाया जाएगा।

इससे बचने के लिए मैं शायद इसके बजाय log.Fatal() को उस func के भीतर हटा दूंगा, जिसे मैं हटाना चाहता था, विशुद्ध रूप से यह सुनिश्चित करने के लिए कि मौजूदा कोड एक असुरक्षित समापन बिंदु का उपयोग नहीं करता है बल्कि संगतता बनाए रखने के लिए है।

यह देखते हुए कि इनमें से कोई भी आदर्श नहीं है ... हम सुरक्षा सुधारों को कैसे देखते हैं जिनके लिए एक सार्वजनिक फ़ंक्शन की आवश्यकता होती है जिसे कठिन रूप से बहिष्कृत किया जा सकता है? (यदि रनटाइम लॉग के साथ डेवलपर को आश्चर्यचकित करके नहीं। घातक ()?)

इसके लिए प्रतिबद्धता देखने के इच्छुक लोगों के लिए: https://github.com/microcosm-cc/bluemonday/commit/a5d7ef6b249a7c01e66856b585a359970f03502c

@Merovius संस्करण 0.x का उपयोग करते समय स्पष्टीकरण के लिए धन्यवाद। जैसा आपने कहा, 1.0 से पहले के संस्करण का उपयोग करते समय भरोसा करने की कोई गारंटी नहीं है और संस्करण 0.x सेवर में एक विशेष मामला है। अगर मैं सही ढंग से समझ गया, तो उल्लिखित नियम वास्तव में 0.x संस्करणों पर बिल्कुल भी लागू नहीं होते हैं। मेरा सवाल यह है कि अगर कोड में भी इस भेद को प्रतिबिंबित करना समझ में आता है - खासकर जब पैकेज नामकरण करते हैं। उदाहरण के लिए, यदि कोई पैकेज केवल संस्करण के बिना पैकेज आयात करता है, तो आप एक नज़र में देख सकते हैं कि यह अस्थिर कोड पर बनाया गया है। यदि सभी आयातों में एक संस्करण v1 है, तो आप देखते हैं कि यह स्थिर संस्करणों का उपयोग करता है।

@buro9 प्रस्ताव मोटे तौर पर go1 संगतता गारंटी का पालन करने का सुझाव देता है, जिसमें सुरक्षा से संबंधित एपीआई ब्रेकेज के लिए छूट शामिल है।

@kaikuehne धन्यवाद, यह आपकी चिंता को स्पष्ट करता है।

सुविधाओं की एक बातचीत है जिसके बारे में मैं चिंतित हूं (यह मानते हुए कि मैं चीजों को सही ढंग से समझता हूं)।

यदि आपके पास एक मॉड्यूल एम है जो संशोधित संस्करणों का उपयोग करता है (स्रोत में शाब्दिक वीएन निर्देशिका, टैग से प्राप्त सिंथेटिक आयात पथ तत्व नहीं), और आप एक प्रोग्राम पी बना रहे हैं जो एम के कई प्रमुख संस्करणों पर निर्भर करता है, ऐसा नहीं होगा कुछ परिदृश्यों में न्यूनतम संस्करण चयन का उल्लंघन करना है?

अर्थात्, मान लीजिए कि P, M के प्रमुख संस्करण 2, 3 और 4 पर निर्भर करता है। M के प्रत्येक प्रमुख संस्करण के लिए, न्यूनतम पूर्ण संस्करण निर्दिष्ट किया गया है। चूंकि एम शेयर स्रोत के संस्करण स्पष्ट रूप से चीजों को करने में सक्षम होने के लिए समान प्रकार की परिभाषा का उपयोग प्रकार उपनामों के साथ करने में सक्षम होने के कारण, एम की केवल एक प्रति प्रति प्रमुख संस्करण की एक प्रति के बजाय सभी तीन प्रमुख संस्करणों के लिए शामिल की जा सकती है। एक प्रमुख संस्करण के लिए पूर्ण संस्करण का कोई भी विकल्प अन्य दो प्रमुख संस्करणों के पूर्ण संस्करण के विकल्प को ठीक करता है और अन्य प्रमुख संस्करणों में से एक या दोनों के लिए एक गैर-न्यूनतम संस्करण का चयन कर सकता है।

vgo इसे कैसे हैंडल करता है? क्या यह कभी-कभी न्यूनतम से थोड़ा कम होने के अलावा कोई समस्या पैदा कर सकता है? (जैसे कि गलती से मॉड्यूल का एक सेट बनाना संभव है जो कोई समाधान नहीं देता है या सॉल्वर को लूप का कारण बनता है?)

@jimmyfrasche

यदि आप प्रमुख संस्करण निर्देशिकाओं का उपयोग कर रहे हैं, तो vgo अभी भी टैग का उपयोग करेगा और उसके बाद ही उस टैग का मिलान संस्करण फ़ोल्डर प्राप्त करेगा। उदाहरण के लिए आप संस्करण 2, 3, 4 पर निर्भर हैं। vgo चेकआउट टैग v2.nm, v3.nm, v4.nm करेगा।
और फिर टैग से v2.nm केवल v2 फ़ोल्डर प्राप्त करें और इसी तरह। तो अंत में सब कुछ अभी भी टैग का पालन कर रहा है।

मैंने इस मेलिंग सूची पोस्ट में एक प्रश्न पूछा था, लेकिन कोई ठोस उत्तर नहीं देखा। मैं इसे यहां दोहराऊंगा:

गैर-गो संसाधनों के साथ क्या होगा, जैसे प्रोटोबफ़ या सी फ़ाइलें? क्षमा करें यदि आपकी पोस्ट में इसका उत्तर पहले ही दिया जा चुका है, लेकिन हम प्रोटोबफ फ़ाइलों के लिए आयात पथ को वितरित और सेट करने के लिए विक्रेता पथ का उपयोग करते हैं। जबकि हम पूर्व-संकलित प्रोटोबफ आउटपुट के खिलाफ गो पैकाकेज को संकलित करेंगे, हमें विक्रेता निर्भरता पर निर्भर प्रोटोबफ फाइलों से नए गो पैकेजों को संकलित करने के मामले पर भी विचार करना होगा (यानी संदर्भ आरपीसी। किसी अन्य प्रोटोबफ फ़ाइल से स्थिति)। मैं कुछ और ठोस उदाहरण प्रदान कर सकता हूं यदि वह विवरण बहुत घना है।

विशेष रूप से, मेरे पास प्रोटोबिल्ड नामक एक प्रोजेक्ट है जो किसी को प्रोटोबफ फ़ाइल आयात को GOPATH स्थानों पर मैप करने की अनुमति देता है। मैं यह नहीं देख रहा हूं कि यह प्रस्ताव GOPATH में संसाधनों के समाधान को कैसे संभालेगा और हम इसे अन्य कंपाइलर आयात स्थानों में कैसे मैप कर सकते हैं।

हमारे लिए प्रोटोबफ के साथ काम करने के लिए यह एक बहुत बड़ा दर्द बिंदु था और इस परियोजना ने उन कई समस्याओं को कम किया। यह शर्म की बात होगी अगर यह प्रस्ताव के साथ पूरी तरह से असंगत था।

फिर से, अगर कुछ छूट गया हो तो क्षमा करें।

मुझे प्रस्ताव पसंद है। मुझे केवल इस बात की चिंता है कि बहुत सी परियोजनाएँ अक्सर छोटे संस्करणों के बीच छोटे ब्रेकिंग परिवर्तन पेश करती हैं और केवल बहुत बड़े ब्रेकिंग परिवर्तनों के लिए प्रमुख संस्करण बम्प आरक्षित करती हैं। यदि मामूली संस्करण तोड़ने वाले परिवर्तन बार-बार होते हैं, तो हीरे पर निर्भरता के मुद्दे पैदा होंगे क्योंकि यह SIV की धारणा का उल्लंघन करता है। मुझे आश्चर्य है कि अगर आयात विवरण में छोटे संस्करण को शामिल करने से अधिक परियोजनाओं को गैर-ब्रेकिंग परिवर्तन अनुबंध का अनुपालन करने में मदद मिलेगी। मुझे लगता है कि डाउनसाइड्स अतिरिक्त आयात मंथन हैं और मामूली संस्करणों को अपडेट करना अधिक कठिन (और अधिक स्पष्ट) हो जाता है।

यह मेरे पास एक और प्रश्न लाता है: क्या यह आसान (आज) vgo के साथ यह निर्धारित करने के लिए है कि क्या आपके पास एक बिल्ड में पैकेज का 1 संस्करण अधिक है? एक ही पैकेज के दो संस्करणों की अनुमति देना कभी-कभी आगे बढ़ने के लिए महत्वपूर्ण होता है, ऐसा लगता है कि अधिकांश प्रोजेक्ट इससे बचना चाहेंगे जब तक कि init के संभावित अप्रत्याशित दुष्प्रभावों के कारण अस्थायी न हो। इसे जांचने का एक आसान तरीका उपयोगी हो सकता है और कुछ प्रोजेक्ट कोड चेक इन के दौरान इसे लागू करना चाह सकते हैं।

मुझे केवल इस बात की चिंता है कि बहुत सी परियोजनाएँ अक्सर छोटे संस्करणों के बीच छोटे ब्रेकिंग परिवर्तन पेश करती हैं और केवल बहुत बड़े ब्रेकिंग परिवर्तनों के लिए प्रमुख संस्करण बम्प आरक्षित करती हैं।

ब्रेकिंग चेंज एक ब्रेकिंग चेंज है। यह छोटा या बड़ा नहीं हो सकता। मुझे लगता है कि इस तरह के पैकेज अंततः समुदाय द्वारा बहुत अविश्वसनीय और सेवर का पालन नहीं करने के कारण खारिज कर दिए जाएंगे। यहां तक ​​​​कि अगर वे सेवर का पालन करेंगे और जल्दी से बड़ी संख्या में 42.xx तक पहुंच जाएंगे, तो वे वैसे भी उपयोग करने के लिए बहुत असुविधाजनक होंगे। इसलिए, यदि आप बहुत सारे ब्रेकिंग परिवर्तन करना चाहते हैं तो बस प्रमुख संख्या 0 का उपयोग करते रहें। इस तरह यह समान मुद्दों के साथ वर्तमान go get की तरह ही काम करना जारी रखेगा। यदि आप गैर-0 प्रमुख संस्करण जारी करने के बाद एपीआई के साथ प्रयोग करना चाहते हैं - इन प्रयोगों को "प्रयोगात्मक" पैकेज को हमेशा के लिए प्रमुख 0 से अलग करने के लिए स्थानांतरित करें और जब आप "छोटे ब्रेकिंग परिवर्तन" के साथ करते हैं तो मुख्य पैकेज के प्रमुख को बढ़ाएं और अंत में अगला स्थिर एपीआई प्राप्त करें।

आयात पथ में नाबालिग को शामिल करना सेवर विचारधारा का उल्लंघन करता है और प्रमुख सहित कोई नई सुविधाएँ प्रदान नहीं करता है।

जबकि मैं समझता हूं कि लेखकों को सेवर के शब्दार्थ को देखते हुए यही करना चाहिए , मेरा डर यह है कि मामूली संस्करणों में मामूली ब्रेकिंग परिवर्तन किसी के लिए पहले से ही पिछले संस्करण 1 के लिए एक आम और आकर्षक मामला है। मेरे वास्तविक अनुभव में, पैकेज लेखक नहीं करते हैं सेवर के सटीक शब्दार्थ का पालन करें और अक्सर कंपनियां विपणन उद्देश्यों के लिए प्रमुख संस्करणों के धक्कों को आरक्षित करती हैं। इसलिए मेरी अपील इस बारे में नहीं है कि आदर्श क्या है, बल्कि इस बारे में है कि क्या सीवर जैसी गन्दा मानवीय वास्तविकता से बेहतर तरीके से निपटने के लिए कुछ बदलाव करना व्यावहारिक हो सकता है।

हो सकता है कि वैकल्पिक रूप से सेवर का पालन न करने वाले पैकेजों के लिए मामूली संस्करण शामिल करना संभव हो, हो सकता है कि पूरे प्रस्ताव को खराब कर दिया जाए, मुझे इसके बारे में और अधिक सोचने की आवश्यकता होगी। मैं यह प्रस्तावित नहीं कर रहा हूं कि यह केवल एक बेहतर तरीका है कि मैं आयात में मामूली संस्करण को शामिल करने या अनिवार्य रूप से वैकल्पिक रूप से व्यापार-बंद की खोज करने में रूचि रखता हूं।

गो कॉर्पस (और एक उपकरण जो स्पष्ट ब्रेकिंग परिवर्तनों की तलाश करता है) से यहां बेहतर डेटा उत्पन्न करना संभव है, यह निर्धारित करने के लिए कि सेवर टैग का उपयोग करने वाली मौजूदा लोकप्रिय परियोजनाओं के बीच कितनी बार सेवर का पालन किया जाता है।

वीजीओ प्रस्ताव प्रमुख संस्करणों को एपीआई परिवर्तनों को इनायत से तोड़ने की अनुमति देता है। यह (अपने आप में) उन्हें रोकने के लिए कुछ नहीं करता है।

वीजीओ प्रस्ताव एक प्रमुख संस्करण को दूसरे प्रमुख संस्करण को संदर्भित करने की अनुमति देता है, जिससे सुंदर कोड का पुन: उपयोग किया जा सकता है। यह जबरदस्ती करने के लिए कुछ नहीं करता है।

vgo MVS प्रस्ताव नए पैकेजों को अद्यतन करने की अनुमति देता है। यह आपको अपडेट करने के लिए बाध्य नहीं करता है।

यहाँ वे चीज़ें हैं जिन्हें हम vgo की दुनिया में बहुत अधिक आसानी से बना सकते हैं:

1. मॉड्यूल होस्ट को पुश करने से पहले एपीआई ब्रेकिंग परिवर्तनों को पकड़ने के लिए टूलिंग। प्रत्येक संस्करण एक ज़िप में है और कई अलग-अलग वीसीएस टूल और कमांड के बिना तुलना की जा सकती है।
2. सुरक्षा समस्या रजिस्ट्री। मूल्यवर्धन के लिए मॉड्यूल होस्टिंग के साथ होस्ट करें। उपकरण उन्हें मैन्युअल रूप से या स्वचालित रूप से go list के समान क्वेरी कर सकते हैं और एक क्वेरी द्वारा फ़िल्टर किए गए मुद्दों की सूचना प्राप्त कर सकते हैं।

vgo इनके द्वारा आसान बनाता है:

• समस्या-स्थान को रोकना (केवल ज़िप फ़ाइलों के साथ काम करना, एपीआई तुलना करने के लिए मनमाने ढंग से git/hg/svn इतिहास को संग्रहीत करने की कोई आवश्यकता नहीं है)।
  
  
  
  • समस्या-स्थान को परिभाषित करना (एमवीएस, संस्करण परिभाषा)
  
  
• निर्माण भाग को टूलींग।

vgo एक मुख्य सिद्धांत पर काम करता है: इनपुट के एक सेट को हमेशा एक ही चीज़ का निर्माण करना चाहिए। अगर हम सुरक्षा अद्यतनों को पकड़ने के लिए यादृच्छिक पुनर्निर्माण पर भरोसा कर रहे हैं तो हम इसे गलत कर रहे हैं । परियोजनाओं के अनुरक्षक के रूप में, कुछ गो परियोजनाएं बिना पुनर्निर्माण के वर्षों तक चलती हैं। मैं सहमत हूं कि समय पर सुरक्षा अद्यतन महत्वपूर्ण हैं: vgo इस आवश्यकता के निर्माण भाग को संतुष्ट करता है।

हमें भ्रमित नहीं होना चाहिए कि vgo क्या अनुमति देता है और vgo क्या है।

@ pbx0 मुझे यकीन नहीं है कि इस तरह की चर्चा के लिए यह एक सही जगह है, शायद मेलिस्ट अधिक उपयुक्त है। किसी भी स्थिति में, प्रमुख संख्या को बदले बिना परिवर्तन को तोड़ना होता है। कभी कभार भी। सेमर ने इस मामले का उत्तर अक्सर पूछे जाने वाले प्रश्नों में दिया है:

जैसे ही आपको पता चलता है कि आपने सिमेंटिक वर्जनिंग स्पेक को तोड़ दिया है, समस्या को ठीक करें और एक नया माइनर वर्जन जारी करें जो समस्या को ठीक करता है और पश्च संगतता को पुनर्स्थापित करता है।

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

मैं प्रमुख संस्करणों को स्कोप करने के लिए पथों का उपयोग करने में दृढ़ता से विश्वास करता हूं और अपने समर्थन, एफडब्ल्यूआईडब्ल्यू को आवाज देना चाहता हूं।

एक साल पहले, मेरा मानना ​​​​था कि इस तरह के आयात पथ में संस्करण डालना बदसूरत, अवांछनीय और शायद टालने योग्य था। लेकिन पिछले एक साल में, मुझे समझ में आया है कि वे सिस्टम में कितनी स्पष्टता और सरलता लाते हैं।

लगभग बीस साल पहले मुझे अपने स्टार्टअप के लिए वीसीएस की जरूरत थी और लगभग दस अलग-अलग कोशिश की। मैंने तुरंत पर्सफोर्स को खारिज कर दिया क्योंकि उसने निर्देशिकाओं का उपयोग करके शाखाओं का खुलासा किया। तो v2 शाखा बस एक ही कोड होगी, लेकिन एक v2 फ़ोल्डर के अंतर्गत। मुझे इस विचार से नफरत थी। लेकिन अन्य नौ के साथ पायलट चलाने के बाद, मैंने पाया कि मैं अक्सर अपने स्थानीय फाइल सिस्टम पर एक शाखा के दोनों संस्करण रखना चाहता था, और यह पता चला कि पर्सफोर्स ने इसे बहुत आसान बना दिया जबकि अन्य ने इसे आश्चर्यजनक रूप से जटिल बना दिया। फाइल सिस्टम हमारा नियंत्रण रूपक है। आइए इसका इस्तेमाल करें।

प्रस्ताव से:

प्रॉक्सी से गो मॉड्यूल लाने के लिए एक यूआरएल स्कीमा परिभाषित करें, कस्टम डोमेन नामों का उपयोग करके मॉड्यूल स्थापित करने के लिए और $GOPROXY पर्यावरण चर सेट होने पर भी उपयोग किया जाता है। उत्तरार्द्ध कंपनियों और व्यक्तियों को सुरक्षा, उपलब्धता या अन्य कारणों से प्रॉक्सी के माध्यम से सभी मॉड्यूल डाउनलोड अनुरोध भेजने की अनुमति देता है।

मैंने इसका कहीं और उल्लेख किया है, लेकिन प्रस्ताव के साथ मेरी सबसे बड़ी चिंता यह है कि ऐसा लगता है कि आज वेंडरिंग की सबसे बड़ी ताकतों में से एक को छोड़ना (या कम से कम पता नहीं है): हमेशा उपलब्ध कोड और पूरी तरह से प्रतिलिपि प्रस्तुत करने योग्य बनाता है। मुझे नहीं लगता कि प्रस्तावित प्रॉक्सी प्रणाली पर्याप्त पते या इन शक्तियों को प्रतिस्थापित करती है।

एक प्रोजेक्ट जो आज वेंडरिंग का उपयोग करता है, उसे केवल गो टूलचैन और गिट (या अन्य संस्करण नियंत्रण प्रणाली) की आवश्यकता होती है। विफलता का केवल एक ही बिंदु मौजूद है: git रिपॉजिटरी। एक बार कोड की जांच हो जाने के बाद, इसे फिर से नेटवर्क को छूने की आवश्यकता के बिना पूरी तरह से बनाया और पुनर्निर्माण किया जा सकता है - एक महत्वपूर्ण सुरक्षा विचार। हम में से अधिकांश के लिए एक विक्रेता परियोजना के लिए किसी अतिरिक्त बुनियादी ढांचे की आवश्यकता नहीं होती है - बस आपका स्थानीय कंप्यूटर और एक मुफ्त गिटहब खाता।

vgo प्रॉक्सी पर निर्भरता एक गैर-तुच्छ आधारभूत संरचना ओवरहेड पेश करती है जो मुझे विश्वास है कि पर्याप्त रूप से जोर नहीं दिया गया है। नए बुनियादी ढांचे का प्रावधान, कार्यान्वयन, रखरखाव और निगरानी की जानी चाहिए। यह सॉफ्टवेयर संगठनों के लिए उचित हो सकता है, लेकिन यह व्यक्तियों और विकेंद्रीकृत ओपन सोर्स प्रोजेक्ट्स के लिए एक बोझ है। इसके अलावा, सीआई जैसी चीजें अक्सर ट्रैविस सीआई जैसे तीसरे पक्ष को आउटसोर्स की जाती हैं, जो कंपनी के विकास के माहौल के समान बुनियादी ढांचे में नहीं चलती हैं। इससे प्रॉक्सी इन्फ्रास्ट्रक्चर का पुन: उपयोग करना कठिन हो जाता है।

अन्य भाषाएं कैशिंग प्रॉक्सी के उपयोग की अनुमति देती हैं। पायथन वह है जिसके साथ मुझे सबसे अधिक अनुभव है, और मेरे अनुभव में इसका उपयोग शायद ही कभी एक को स्थापित करने के ऊपरी हिस्से के कारण किया जाता है। हो सकता है कि गो प्रोजेक्ट इसे आसान बना दे, लेकिन अगर यह डिफ़ॉल्ट नहीं है तो हम पाएंगे कि इसका इस्तेमाल कम होता है और जंगली में गो बिल्ड की उपलब्धता में काफी कमी आएगी। लेफ्ट-पैड एनपीएम इवेंट का प्रभाव इस संबंध में एक बेहतरीन केस स्टडी है।

यदि मॉड्यूल और प्रॉक्सी सिस्टम हमें अपने स्वयं के प्रोजेक्ट के कोड के साथ निर्भरता की जांच करने की अनुमति देता है (आज के वेंडरिंग के समान, लेकिन जरूरी नहीं कि समान कार्यान्वयन) और vgo प्रॉक्सी कार्यान्वयन इसका उपयोग कर सकता है, तो यह मेरी चिंताओं को दूर करेगा। लेकिन अगर ऐसा इरादा है, तो मुझे लगता है कि प्रस्ताव में इसे और अधिक पूरी तरह से संबोधित करने की जरूरत है।

@joeshaw आप स्वयं निहित निर्माण बनाने के लिए विक्रेता निर्देशिका का उपयोग करने में सक्षम रहेंगे।

प्रस्ताव से:

एक सीमित उपयोग को छोड़कर, विक्रेता निर्देशिकाओं के उपयोग को अस्वीकार करें: निर्मित किए जा रहे शीर्ष-स्तरीय मॉड्यूल के फ़ाइल ट्री के शीर्ष पर एक विक्रेता निर्देशिका अभी भी बिल्ड पर लागू होती है, ताकि स्व-निहित एप्लिकेशन रिपॉजिटरी को अनुमति देना जारी रखा जा सके। (अन्य विक्रेता निर्देशिकाओं को अनदेखा करना यह सुनिश्चित करता है कि गो उस बिल्ड पर लौटता है जिसमें प्रत्येक आयात पथ का पूरे निर्माण में समान अर्थ होता है और यह स्थापित करता है कि किसी दिए गए आयात पथ वाले पैकेज की केवल एक प्रति किसी दिए गए निर्माण में उपयोग की जाती है।)

एक प्रोजेक्ट जो आज वेंडरिंग का उपयोग करता है, उसे केवल गो टूलचैन और गिट (या अन्य संस्करण नियंत्रण प्रणाली) की आवश्यकता होती है। विफलता का केवल एक ही बिंदु मौजूद है: git रिपॉजिटरी।

आज, यदि आप अपने स्वयं के डोमेन के अंतर्गत पैकेज होस्ट कर रहे हैं, तो आपको a) git-repository को होस्ट करना होगा और b) गो-गेट को खोजने के लिए आवश्यक <meta> टैग की सेवा करनी होगी। भविष्य में, आपको a) .zip और .json फाइलों की सेवा करनी होगी जो कोड लाने के लिए vgo के लिए आवश्यक हैं। ऐसा लगता है कि शुद्ध होस्टिंग के लिए विफलताओं के कम बिंदु और कम बुनियादी ढांचे की आवश्यकता है। बेशक आपको अभी भी विकास के लिए भंडार की मेजबानी करने की आवश्यकता है, लेकिन यह न केवल हमें पहले के समान स्तर पर ले जाता है, बल्कि भंडार को भी बहुत कम स्केलेबल और विश्वसनीय होस्टिंग की आवश्यकता होती है, क्योंकि इसका उपयोग केवल वास्तव में विकसित होने वाले लोगों द्वारा किया जाता है।

इसलिए, वैनिटी इंपोर्ट के लिए, ओवरहेड के मामले में बहुत अधिक अंतर नहीं दिखता है।

यदि, ओटीओएच, आप वैनिटी आयात का उपयोग नहीं कर रहे हैं, तो आप सभी बुनियादी ढांचे की अवहेलना कर रहे हैं जो जीथब आपके लिए चल रहा है। तो यह एक सेब-से-सेब तुलना प्रतीत नहीं होता है: शीर्ष पर आने का एकमात्र तरीका यह है कि आप अन्य लोगों को कठिन समस्याओं को हल करने देते हैं। लेकिन भविष्य में ऐसा करने से आपको कोई रोक नहीं सकता। एआईयूआई माइक्रोसॉफ्ट और अन्य ने पहले ही स्वेच्छा से इस कार्य में इंजीनियरिंग घंटे और सेवा क्षमता का निवेश किया है। मुझे उम्मीद है कि भविष्य में, गो पैकेज की मेजबानी का प्रयास एनपीएम पैकेज या रत्न या बक्से की मेजबानी के प्रयास से लगभग कम होगा: आपके पास एक जीथब रिपोजिटरी है और फिर कुछ केंद्रीय रूप से "इसे उपलब्ध कराएं" बटन पर क्लिक करें ज़िप को होस्ट करने के लिए प्रबंधित सेवा।

vgo की प्रॉक्सी पर निर्भरता

व्यक्तिगत रूप से, मैं "प्रॉक्सी" शब्द को नापसंद करता हूं कि आवश्यक बुनियादी ढांचा क्या करता है। "दर्पण" अधिक उपयुक्त लगता है। दर्पण को एक प्रॉक्सी के रूप में लागू किया जा सकता है, लेकिन यह आपकी पसंद के वेबसर्वर द्वारा दी जाने वाली फाइलों का एक समूह भी हो सकता है, जो लगभग अनंत स्केलेबिलिटी और अपटाइम के लिए क्लाउडफ्लेयर के पीछे छिपा होता है।

अन्य भाषाएं कैशिंग प्रॉक्सी के उपयोग की अनुमति देती हैं।

मैं तर्क दूंगा कि अन्य भाषाएं पूरी तरह से ठीक मॉडल के रूप में काम करती हैं कि यह वास्तव में कोई समस्या क्यों नहीं है। वे अपने पैकेजों को होस्ट करने के लिए केंद्रीकृत होस्टिंग पर भरोसा करते हैं - vgo न केवल इस मॉडल का बहुत अच्छी तरह से समर्थन करता है, यह इसे वैकल्पिक भी बनाता है (इसलिए आपको बिना किसी नुकसान के सभी फायदे मिलते हैं) और बहुत सरल लागू करने, स्केल करने और संचालित करने के लिए।

IMO, यदि आप सीधे तुलना करते हैं कि गो और अन्य भाषाओं में पहले और बाद में क्या हो रहा है, तो यह स्पष्ट होना चाहिए कि बहुत सारी 1:1 समानताएँ हैं। और ऐसा लगता है कि भविष्य में और अधिक प्रयास होने का एकमात्र कारण यह है कि हम मौजूदा बुनियादी ढांचे को हल्के में लेते हैं और देखते हैं कि नया बुनियादी ढांचा अभी तक मौजूद नहीं है। लेकिन मुझे नहीं लगता कि हमारे पास संदेह करने के अच्छे कारण हैं कि ऐसा होगा।

इसलिए, वैनिटी इंपोर्ट के लिए, ओवरहेड के मामले में बहुत अधिक अंतर नहीं दिखता है।

सच है, लेकिन _vast_ अल्पसंख्यक पैकेज वैनिटी डोमेन का उपयोग करते हैं, इसलिए मुझे नहीं लगता कि यह एक मजबूत काउंटरपॉइंट है। (मेरे पास वैनिटी डोमेन के साथ अन्य व्यावहारिक मुद्दे भी हैं, जो यह है कि उनकी उपलब्धता केवल गिटहब का उपयोग करने से _बहुत खराब_ हो जाती है।)

यदि, ओटीओएच, आप वैनिटी आयात का उपयोग नहीं कर रहे हैं, तो आप सभी बुनियादी ढांचे की अवहेलना कर रहे हैं जो जीथब आपके लिए चल रहा है।

हाँ बिल्कुल! मुझे लगता है कि यह मेरे लिए मेरी बात बनाता है। आपको बुनियादी ढांचे और अपटाइम को मुफ्त में या उचित कीमत पर बनाए रखने पर वह सब बढ़िया काम मिलता है। इससे भी महत्वपूर्ण बात यह है कि इसमें आपका अपना कोई समय शामिल नहीं है।

अगर गिटहब ने vgo -संगत दर्पण चलाना समाप्त कर दिया, तो शायद यह चिंता का विषय नहीं है, हालांकि मुझे एक गिट फ़ेच की लालित्य पसंद है - उपयोगकर्ता के परिप्रेक्ष्य से एक परमाणु क्रिया - जिसमें सभी कोड शामिल हैं मुझे एक प्रोजेक्ट बनाना है।

मैं तर्क दूंगा कि अन्य भाषाएं पूरी तरह से ठीक मॉडल के रूप में काम करती हैं कि यह वास्तव में कोई समस्या क्यों नहीं है। वे पैकेजों को होस्ट करने के लिए अपने पैकेज के लिए केंद्रीकृत होस्टिंग पर भरोसा करते हैं - वीजीओ न केवल इस मॉडल का बहुत अच्छी तरह से समर्थन करता है, यह इसे वैकल्पिक भी बनाता है (इसलिए आपको बिना किसी नुकसान के सभी फायदे मिलते हैं) और लागू करने के लिए बहुत आसान, स्केल और संचालन।

समस्या यह है कि यह एक परियोजना के निर्माण के लिए विफलता के एकल बिंदु (एसपीओएफ) जोड़ता है। कोड वीसीएस में रहने वाला है, इससे कोई फर्क नहीं पड़ता (और शायद गिटहब), तो वह एक एसपीओएफ है। अन्य भाषाओं में, एक केंद्रीकृत भंडार दूसरा एसपीओएफ है। गो के लिए, प्रत्येक आयात पथ एक अतिरिक्त एसपीओएफ (github.com, golang.org, honnef.co, rsc.io, आदि) है और एसपीओएफ बढ़ने से समग्र उपलब्धता कम हो जाती है।

एक दर्पण चलाने से वह वापस दो तक कम हो सकता है, लेकिन यह आधारभूत संरचना है जिसका मैं तर्क देता हूं कि अस्तित्व की आवश्यकता नहीं है। अपने डिपो (या एक स्थानीय ऑन-डिस्क मिरर) को बेचने से यह वापस केवल एक हो जाता है: आपका वीसीएस।

किसी भी मामले में, यह एक विवादास्पद मुद्दा हो सकता है। मुझे मूल रूप से शीर्ष-स्तरीय vendor निर्देशिका के प्रस्ताव के हिस्से को समझ में नहीं आया जो मेरी मुख्य चिंताओं को हल करने के लिए प्रतीत होता है - इसे इंगित करने के लिए धन्यवाद, @kardianos - हालांकि पुराने से एक साफ ब्रेक वेंडरिंग सिस्टम बेहतर हो सकता है।

मुझे खुशी है कि "शीर्ष-स्तर vendor " अभी भी एक समर्थित कॉन्फ़िगरेशन होगा क्योंकि मुझे git grep बहुत पसंद है।

एक दर्पण चलाने से वह वापस दो तक कम हो सकता है, लेकिन यह आधारभूत संरचना है जिसका मैं तर्क देता हूं कि अस्तित्व की आवश्यकता नहीं है।

एंटरप्राइज़ डेवलपर यहाँ। हो सकता है कि हम लक्षित जनसांख्यिकीय नहीं हैं, लेकिन हम गो का उपयोग करना चाहेंगे। मैं यह नहीं देख सकता कि हमारे उद्यम के अंदर दर्पण के बिना हो रहा है, जैसा कि हम जावा और जावास्क्रिप्ट के लिए करते हैं, यह सुनिश्चित करने के लिए कि आज हम जो कुछ भी बनाते हैं वह कल बनाया जा सकता है।

एंटरप्राइज़ डेवलपर यहाँ। हो सकता है कि हम लक्षित जनसांख्यिकीय नहीं हैं, लेकिन हम गो का उपयोग करना चाहेंगे। मैं यह नहीं देख सकता कि हमारे उद्यम के अंदर दर्पण के बिना हो रहा है, जैसा कि हम जावा और जावास्क्रिप्ट के लिए करते हैं, यह सुनिश्चित करने के लिए कि आज हम जो कुछ भी बनाते हैं वह कल बनाया जा सकता है।

@jamiethermo क्या वेंडरिंग आज आपके लिए इसे संबोधित नहीं करती है?

परदे के पीछे या दर्पण के लिए समर्थन ठीक है, और अगर यह गो को अपनाने में मदद करता है तो मैं इसके लिए तैयार हूं। मेरी चिंता स्थानीय, स्व-निहित स्रोत पेड़ों (जिसे हम आज वेंडरिंग कहते हैं) के प्रतिस्थापन के रूप में दर्पण थे।

@joeshaw

क्या वेंडरिंग आज आपके लिए इसे संबोधित नहीं करती है?

खैर, मुझे अज्ञानता, और "मुझे अपना कोड कैसे व्यवस्थित करना चाहिए" के साथ एक निश्चित मात्रा में निराशा स्वीकार करनी चाहिए। "स्व-निहित स्रोत पेड़" से, क्या आपका मतलब है कि मेरे पास एक विशाल गिट रेपो है जिसमें मेरे सभी कोड, साथ ही विक्रेता पेड़ में सभी कोड शामिल हैं? तो मुझे दर्पण की आवश्यकता नहीं है क्योंकि मैंने अपने सभी अन्य कोड को अपने स्वयं के रेपो में चेक किया है?

"मुझे अपना कोड कैसे व्यवस्थित करना चाहिए" के संबंध में, यह पृष्ठ, गो कोड कैसे लिखें , निर्देशिका संरचना पर निर्देश देता है, लेकिन विक्रेता का कोई उल्लेख नहीं करता है।

सिमेंटिक आयात संस्करण को अपनाएं, जिसमें प्रत्येक प्रमुख संस्करण का एक अलग आयात पथ होता है। विशेष रूप से, एक आयात पथ में एक मॉड्यूल पथ, एक संस्करण संख्या और मॉड्यूल के अंदर एक विशिष्ट पैकेज का पथ होता है। यदि प्रमुख संस्करण v0 या v1 है, तो संस्करण संख्या तत्व को छोड़ दिया जाना चाहिए; अन्यथा इसे शामिल किया जाना चाहिए।

my/thing/sub/pkg , my/thing/v2/sub/pkg, और my/thing/v3/sub/pkg के रूप में आयात किए गए पैकेज मॉड्यूल my/thing के प्रमुख संस्करणों v1 , v2, और v3 से आते हैं, लेकिन बिल्ड उन्हें केवल तीन अलग-अलग पैकेजों के रूप में मानता है।

my/thing/sub/pkg भी v0 हो सकता है।

मैंने दौरे का पालन किया। उदाहरण GOPATH पेड़ के बाहर बनाया गया है, और यह काम करता है, जबकि उस स्थिति में dep init barfs। मैं अब 80 टीमों के साथ काम करता हूं, और यह वास्तव में अच्छा होगा कि एक विशाल पेड़ न हो। (जैसा कि मैं इसे लिख रहा था, कोई अपने लैपटॉप और एक भद्दे चेहरे के साथ चला गया, और "मुझे यह वास्तव में अजीब बग मिला है ...")

@joeshaw

आपको बुनियादी ढांचे और अपटाइम को मुफ्त में या उचित कीमत पर बनाए रखने पर वह सब बढ़िया काम मिलता है।

मैंने इसे खराब तरीके से कहा। मेरे कहने का मतलब था "यदि आप दावा करते हैं कि आपको कम बुनियादी ढांचे की आवश्यकता होती है यदि आप वैनिटी आयात का उपयोग नहीं कर रहे हैं, तो आप सभी बुनियादी ढांचे की अवहेलना कर रहे हैं जो आपके लिए जीथब चलाता है"। मेरा मतलब यह बताना था कि बुनियादी ढांचा अभी भी है और अभी भी चलने की जरूरत है। और यह आपके लिए भविष्य में भी चलाना जारी रख सकता है।

तो आपकी चिंता का समाधान उस स्थिति में किया जाएगा जिसे मैं सबसे संभावित परिदृश्य मानता हूं: कि एक वित्त पोषित निकाय (वर्तमान में माइक्रोसॉफ्ट इसे आकार दे रहा है) ज़िप-फाइलों की मेजबानी कर रहा है।

हालांकि मुझे एक एकल गिट फ़ेच का लालित्य पसंद है - उपयोगकर्ता के परिप्रेक्ष्य से एक परमाणु क्रिया

vgo get उतना ही एक परमाणु क्रिया है और यह कम काम करता है, उसी प्रकृति का (HTTP अनुरोध) जिसे समझना आसान है।

समस्या यह है कि यह एक परियोजना के निर्माण के लिए विफलता के एकल बिंदु (एसपीओएफ) जोड़ता है।

फिर मेरी आखिरी टिप्पणी कहाँ गलत है? क्योंकि यह मेरे लिए बहुत स्पष्ट प्रतीत होता है कि विफलताओं के बिंदुओं की संख्या, यदि कुछ भी कम है, तो वे सरल, स्केल करने में आसान और चलाने के लिए सस्ता हैं।

अन्य भाषाओं में, एक केंद्रीकृत भंडार दूसरा एसपीओएफ है। गो के लिए, प्रत्येक आयात पथ एक अतिरिक्त एसपीओएफ (github.com, golang.org, honnef.co, rsc.io, आदि) है और एसपीओएफ बढ़ने से समग्र उपलब्धता कम हो जाती है।

मुझे लगता है कि यह अति सरलीकृत है। यदि आप अपने कोड को एक दर्पण पर होस्ट करते हैं जो नीचे जाता है, तो आप अभी भी विकसित हो सकते हैं (जीथब अभी भी ऊपर है) और उपयोगकर्ता अभी भी स्थापित करने में सक्षम हो सकते हैं (एक अलग दर्पण का उपयोग करके)। आपकी निर्भरताओं में से एक के नीचे जाने से कोई फर्क नहीं पड़ता, क्योंकि आप अपनी निर्भरताओं को प्रतिबिंबित करते हैं। यदि आप "केंद्रीकृत" समुदाय द्वारा संचालित दर्पण पर भरोसा नहीं करते हैं, तो आप अपना खुद का चला सकते हैं या इसे करने के लिए किसी को भुगतान कर सकते हैं, उपयोगकर्ताओं को कोई फर्क नहीं पड़ता, आपको इस पर पूर्ण नियंत्रण प्रदान करता है कि आप डाउनटाइम से कितना प्रभावित हैं केंद्रीकृत रेपो।

आप जिन चीजों का उल्लेख करते हैं उनमें से कोई भी वास्तव में एक एसपीओएफ नहीं है, क्योंकि आप अभी भी कम से कम अपमानित ऑपरेशन प्राप्त करते हैं। उसमें जोड़ें, कि वास्तविक दर्पण संचालित करने के लिए तुलनात्मक रूप से तुच्छ हैं (क्योंकि वे केवल स्टेटलेस HTTP सर्वर हैं) और मुझे विश्वास नहीं है कि विश्वसनीयता और उपलब्धता सार्थक रूप से घट जाएगी।

और एफटीआर, अभी आपकी गिट-होस्टिंग एक एसपीओएफ है : यदि आपका गिट-होस्ट डाउन है, तो उपयोगकर्ता इंस्टॉल नहीं कर सकते हैं और आप विकसित नहीं कर सकते हैं।

एक दर्पण चलाने से वह वापस दो तक कम हो सकता है, लेकिन यह आधारभूत संरचना है जिसका मैं तर्क देता हूं कि अस्तित्व की आवश्यकता नहीं है।

और ऊपर मेरा (खराब वाक्यांश) बिंदु था, कि यह पहले से ही करता है :) आप बस ए) अनदेखा कर रहे हैं कि यह अभी होता है और बी) यह मानते हुए कि यह भविष्य में नहीं होगा :)

एक अलग दृष्टिकोण देने के लिए:

• हम अपने सिस्टम-वाइड क्रॉस-लैंग्वेज सॉफ्टवेयर कंपोनेंट मैनेजर (फेडोरा, सेंटोस और आरएचईएल पर आरपीएम/डीएनएफ) के साथ कई गो प्रोजेक्ट बना रहे हैं।
• यह हमें आरपीएम परत घटक नामस्थान पर खेलकर वीजीओ प्रस्ताव के समान कई चालें करने की अनुमति देता है (आमतौर पर, प्रोजेक्ट से कॉम्पैट-प्रोजेक्ट-एक्स में आरपीएम नेमस्पेस स्तर पर एक प्रोजेक्ट का नाम बदलकर असंगत संस्करणों के बीच अंतर करने की अनुमति देता है। वही आयात पथ, ठीक वैसे ही जैसे vgo करेगा)।
• जटिल गो परियोजनाओं के निर्माण में मदद करने के लिए ये तरकीबें निश्चित रूप से उपयोगी हैं
• हालांकि यह भाषा के स्तर पर करने जितना पूर्ण और मजबूत नहीं है
• हम मूल कोड पर बाधाओं के आरपीएम/डीएनएफ ओवरले जोड़ने के बजाय आरपीएम/डीएनएफ में भाषा बाधाओं को रिले करना चाहते हैं।
• गो प्रोजेक्ट स्रोतों को देखने के लिए गो टूल्स को मनाने के लिए वर्तमान में आवश्यक सभी फाइल सिस्टम वर्कअराउंड से हम काफी बीमार हैं। भौतिक GOPATH को बिल्कुल भी याद नहीं किया जाएगा।

इसलिए हम vgo को लेकर रोमांचित हैं और आशा करते हैं कि इसे जल्द ही तैनात किया जाएगा (हमें इसकी वर्षों पहले आवश्यकता थी)।

कहा जा रहा है कि हमारे vgo- जैसे कार्यप्रवाहों के उपयोग ने निम्नलिखित कठिनाइयों को उजागर किया।

मेकफ़ाइल्स को अनावश्यक बनाने के लिए vgo प्रस्ताव खुद को बधाई देता है। यह बिलकुल सच नहीं है।

• कई गो परियोजनाओं को ऑटोजेनरेटेड गो फाइलों से प्यार हो गया है और उन्हें पुन: उत्पन्न करने की मांग करने या पीढ़ी को सफल होने की आवश्यकता को व्यक्त करने के लिए कोई मानक तरीका नहीं है
• यह इतना बुरा है कि कई परियोजनाओं को प्रीजेनरेटेड फाइलों के साथ शिप करना पड़ता है (कभी-कभी पूरी तरह से अलग प्रीजेनरेटेड फाइल रिपोजिटरी बनाते हैं)
• वे फ़ाइलें संस्करण असंगतियों का एक बड़ा स्रोत हैं। मनुष्य कोड लिखने में सावधानी बरतता है जिसे नए निर्भरता संस्करणों के संपर्क में आने पर हर दिन बदलने की आवश्यकता नहीं होगी। ऑटोजेनरेटेड फाइलें ओटीओएच अक्सर सटीक पीढ़ी के वातावरण से निकटता से जुड़ी होती हैं, क्योंकि जनरेटर टूल लेखक मानते हैं कि आप उन्हें आवश्यकतानुसार पुन: उत्पन्न करेंगे।
• vgo के सफल होने के लिए, इसे उन फ़ाइलों की पहचान करने, उन्हें .zip मॉड्यूल से अलग करने और .zip मॉड्यूल के उपयोगकर्ताओं के लिए उन्हें पुन: उत्पन्न करने का तरीका व्यक्त करने की आवश्यकता है।

यह वर्तमान "सब कुछ गोपथ में होना चाहिए" नियम से बढ़ गया है

• सब कुछ GOPATH में नहीं हो सकता है जब पीढ़ी बहु-भाषा परियोजनाओं द्वारा GOPATH के बाहर प्रकाशित प्रोटो फाइलों पर निर्भर करती है
• गो टूलचेन को अपने GOPATH के बाहर के संसाधनों को पढ़ना सीखना होगा
• गो टूलचैन को GOPATH के बाहर संसाधनों को प्रकाशित करने के लिए सीखने की जरूरत है, जब वे उन परियोजनाओं के संपर्क में आते हैं जो जरूरी नहीं कि गो में लिखे गए हों
• GOPATH के साथ प्रतियों में संसाधनों को डुप्लिकेट करने का वर्तमान समाधान संस्करण असंगतियों का एक अन्य स्रोत है
• हर कोई एक ही फाइल को एक ही समय में कॉपी नहीं करेगा
• कभी-कभी प्रोजेक्ट कई स्रोतों से कॉपी करते हैं, एक-एक तरह के मिश्रण बनाते हैं।
• हर प्रोजेक्ट अपनी कॉपी पर क्यूए करेगा, जिससे गो प्रोजेक्ट कंपोजिशन खतरनाक हो जाएगा
• अगर यह कोड रिलीज के बीच संबंधों की गणना करता है लेकिन संसाधन रिलीज के बीच संबंधों को अनदेखा करता है तो वीजीओ संस्करण सॉल्वर इरादा के अनुसार काम नहीं करेगा।
• vgo को असंगत मॉड्यूल संस्करणों के विस्फोट से बचने के लिए GOPATH के बाहर प्रकाशित चीजों की निजी प्रतियों को अनावश्यक बनाने की आवश्यकता है।

कई परियोजनाओं ने अलग-अलग उपनिर्देशिकाओं में असंगत, या पूरी तरह से टूटे हुए कोड वाली परियोजनाओं को प्रकाशित करने के लिए "हर गो निर्देशिका एक अलग पैकेज है" नियम का फायदा उठाया है

• कई अन्य गो परियोजनाओं ने विशिष्ट उपनिर्देशिकाओं को चुनने के लिए समान नियम का उपयोग किया है और मूल परियोजना इकाई परीक्षणों और क्यूए के साथ असंगत संदर्भ में उनका उपयोग किया है
• वह "काम करता है" और "पुनरुत्पादित बिल्ड" का उत्पादन करता है जब तक कि मूल परियोजना में या परियोजना में कोई परिवर्तन नहीं होता है, उपभोक्ता मूल परियोजना के किसी अन्य भाग का उपयोग करता है। जब ऐसा होता है तो संचित तकनीकी ऋण के तहत पूरा रेत महल उखड़ जाता है,
• आप परियोजनाओं को नए प्रोजेक्ट संस्करणों में अपडेट करने से इनकार करते हुए देखते हैं क्योंकि इसके लिए अन्य परियोजनाओं के अपने पिछले दुरुपयोगों को साफ करने की आवश्यकता होती है।
• आपके पास एक अजीब सिज़ोफ्रेनिया है जहां गो प्रोजेक्ट खुद को कोडबेस में बग के लिए जिम्मेदार नहीं मानते हैं, और साथ ही उसी कोडबेस द्वारा प्रकाशित सुधारों को लागू करने से इनकार करते हैं (मुझे लगता है कि हम सभी इंसान हैं और अप्रिय वास्तविकता इनकार कठिन है मानव मस्तिष्क में)
• फ़िक्सेस प्रचारित नहीं होते हैं, और सब कुछ "ठीक" है जब तक कि आप उन बग्स को हिट नहीं करते हैं जिन्हें पहले स्थान पर फ़िक्सेस की आवश्यकता होती है या यूनिट परीक्षण जो चेरी-पिकिंग द्वारा अमान्य थे।
• एक स्वचालित सुरक्षा चेकर जो परियोजनाओं की सुरक्षा स्थिति की तुलना करता है, विक्रेता डीआईआर के अंदर समान परियोजनाओं की सुरक्षा स्थिति के साथ, एक क्षेत्र दिवस होगा
• परियोजना जितनी बड़ी होगी, उतनी ही अधिक संभावना है कि उसके विक्रेता के अंदर ऐसे टिक बम छिपे हों
• ज़िप मॉड्यूल के अंदर परियोजना की सीमाओं को स्पष्ट रूप से परिभाषित करके, vgo ऐसी प्रथाओं को समाप्त कर देगा
• हालाँकि यह कई गो कोडबेस की एक बड़ी सफाई भी करेगा
• वीजीओ के सफल होने के लिए, इसे मौजूदा गो प्रोजेक्ट्स रिफैक्टर की मदद करने के लिए टूलिंग प्रदान करने की आवश्यकता है और उनके कोडबेस को मॉड्यूल में विभाजित करना है जो एक सॉफ्टवेयर संगतता बिंदु से समझ में आता है। अन्यथा वीजीओ का उपयोग करने वाली परियोजनाएं या तो असंगत बाधाओं का उत्पादन करेंगी या बस यथास्थिति को बंद कर देंगी (जो मौजूदा कोड के लिए काम करती है, लेकिन कोड विकास के दृष्टिकोण से भयानक है)।

परियोजनाओं के बीच थोड़ी सी सीमा के साथ एकल गोपथ पेड़ में संपूर्ण गो कोडबेस को उजागर करने की वर्तमान प्रथा ने एक सॉफ्टवेयर इंजीनियरिंग POW से हानिकारक दुष्प्रभाव उत्पन्न किए हैं।

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

टेस्टफ़िंग/फिक्स्चर, उदाहरण और टेस्टडेटा कीड़े की एक पूरी अन्य कैन हैं, उनकी अपनी निर्भरता और निर्भरता संस्करण की जरूरत है

• उन्हें अलग-अलग मॉड्यूल में एक तरह से या किसी अन्य को अलग करने की आवश्यकता है या उनकी ज़रूरतें सॉल्वर संस्करण रिज़ॉल्यूशन को जहर देंगी
• यदि आप उनकी जरूरतों को नजरअंदाज करते हैं तो आप प्रभावी रूप से किसी को भी तय नहीं करते हैं लेकिन मूल परियोजना इकाई परीक्षण चलाएगी
• जब आप संस्करण उन्नयन की अनुमति देते हैं तो यह काफी खतरनाक होता है। समस्याएं होंगी। आपको उनका पता लगाने की जरूरत है
• एकीकरण परीक्षण जो न केवल किसी अन्य कोड पर निर्भर करता है, बल्कि एक विशिष्ट वातावरण कोई भी नहीं बल्कि मूल परियोजना दोहरा सकता है (उदाहरण के लिए, एक विशिष्ट सर्वर या बात करने के लिए वेबसाइट), शायद विशिष्ट अलगाव की आवश्यकता है

मैं शायद और भी बहुत कुछ भूल गया हूँ, लेकिन वे सबसे महत्वपूर्ण हैं।

अंततः:

• गो प्रोजेक्ट आइसोलेशन में नहीं रहते
• कुछ गो प्रोजेक्ट कनेक्टर्स को अन्य भाषाओं में प्रकाशित करते हैं
• अन्य भाषाओं में कुछ प्रोजेक्ट गो कनेक्टर प्रकाशित करते हैं
• जो कि अन्य भाषाओं की तरह सेवर को एक अलग तरीके से ट्रीट करने को एक समस्या बना देता है।
• जब कोई बहु-भाषा प्रोजेक्ट रिलीज़ होता है तो आपके पास गो पार्ट को नवीनतम लघु संस्करण में अपडेट करने के अलावा सब कुछ नहीं हो सकता है।
• यह एक परिचालन प्रबंधन POW से नरक होगा।
• नवीनतम सबरिलीज़ में स्वचालित अपग्रेड सभी को पुराने संस्करणों को वैक्यूम करके सॉफ़्टवेयर बाधा ग्राफ़ को सरल बनाने में एक बड़ी भूमिका निभाता है (लाभ तकनीकी है, तंत्र सामाजिक है)।
• उच्च फ़िडेलिटी पुनर्निर्माण पिक्सेल-पूर्ण वेबसाइटों के समान हैं। वे स्पष्ट रूप से एक अच्छे विचार की तरह दिखते हैं, वे मूल लेखक अहंकार को पुरस्कृत करते हैं, लेकिन वे किसी के लिए भी एक PITA हैं जो वास्तव में परिणाम का उपयोग करने की कोशिश करते हैं क्योंकि वे विकसित नहीं होते हैं और स्थानीय (मूल नहीं) संदर्भ के अनुकूल होते हैं।

प्रॉक्सी सर्वर पर:

आसान डिबगिंग के लिए, $GOPROXY एक फ़ाइल भी हो सकती है: /// URL एक स्थानीय पेड़ की ओर इशारा करता है।

कृपया इसे एक फ़ाइल के साथ काम करें: /// https:/// URL की ओर इशारा करते हुए एक निर्देशिका की ओर इशारा करते हुए एक ज़िप रूप में तीसरे पक्ष के मॉड्यूल (और बाकी सब को बाहर करें)

एक इकाई के लिए कई विकास टीमों के काम का समन्वय करने का यह सबसे आसान तरीका है जो एक ही तीसरे पक्ष की परियोजनाओं की सूची के सबसेट पर भरोसा करते हैं: एक क्यूए/कानूनी/सुरक्षा व्यक्ति है जो "अच्छे" तीसरे पक्ष के रिलीज की जांच करने और उन्हें तैनात करने के लिए जिम्मेदार है। एक सामान्य डीआईआर में और बाकी सभी का काम इस सामान्य डीआईआर में उपलब्ध मॉड्यूल पर निर्भर करता है।

इस तरह आप सुनिश्चित हैं कि कोई भी दूसरों के काम के साथ असंगत रेव पर काम करना शुरू नहीं करता है, और कोई भी किसी अन्य टीम द्वारा पहले से पहचाने गए बग्गी या खतरनाक रेव पर नहीं रहता है, और आपके देव स्टेशन लगातार उसी प्रतियों के डाउनलोड होने की प्रतीक्षा नहीं कर रहे हैं स्थानीय स्तर पर पहले से उपलब्ध साफ्टवेयर का

@Merovius मैं असहमत हूं, लेकिन मुझे लगता है कि हम विषय से भटक रहे हैं और इस मुद्दे की चर्चा को कम नहीं करना चाहते हैं। हालाँकि, मुझे एक अलग माध्यम में फॉलो-अप करने में खुशी हो रही है। (मेरा ईमेल मेरे जीथब प्रोफाइल में है और मैं गोफर्स स्लैक पर जोशव हूं।)

https://github.com/golang/go/issues/24301#issuecomment -374882685, @tpng :

छद्म-संस्करण (v0.0-yyymmddhhmmss-commit) में टाइमस्टैम्प के लिए किस टाइमज़ोन का उपयोग किया जाता है?

जैसा कि आपने अपने संपादन में उल्लेख किया है, UTC. लेकिन यह भी ध्यान रखें कि आपको उन्हें कभी भी टाइप नहीं करना है। आप बस एक git कमिट हैश (उपसर्ग) टाइप कर सकते हैं और vgo सही छद्म-संस्करण की गणना और स्थानापन्न करेगा।

https://github.com/golang/go/issues/24301#issuecomment -374907338, @AlexRouSg :

क्या आप सी निर्भरताओं को संबोधित करेंगे?

https://github.com/golang/go/issues/24301#issuecomment -376606788, @stevvooe :

गैर-गो संसाधनों के साथ क्या होगा, जैसे प्रोटोबफ़ या सी फ़ाइलें?

https://github.com/golang/go/issues/24301#issuecomment -377186949, @ nim-nim:

मेकफ़ाइल्स को अनावश्यक बनाने के लिए vgo प्रस्ताव खुद को बधाई देता है। यह बिलकुल सच नहीं है। [उत्पन्न कोड की चर्चा।]

गैर-गो विकास go कमांड का एक गैर-लक्ष्य बना हुआ है, इसलिए सी पुस्तकालयों के प्रबंधन के लिए समर्थन नहीं होगा और न ही प्रोटोकॉल बफर के लिए स्पष्ट समर्थन होगा।

उस ने कहा, हम निश्चित रूप से समझते हैं कि गो के साथ प्रोटोकॉल बफ़र्स का उपयोग करना बहुत कठिन है, और हम इसे अलग से संबोधित करना चाहते हैं।

जनरेट किए गए कोड के लिए अधिक सामान्य रूप से, एक वास्तविक क्रॉस-लैंग्वेज बिल्ड सिस्टम उत्तर है, विशेष रूप से क्योंकि हम नहीं चाहते कि प्रत्येक उपयोगकर्ता को सही जनरेटर स्थापित करने की आवश्यकता हो। लेखक के लिए जनरेटर चलाने और परिणाम की जांच करने के लिए बेहतर है।

https://github.com/golang/go/issues/24301#issuecomment -375248753, @mrkanister :

मुझे पता है कि डिफ़ॉल्ट शाखा को मास्टर से v2 में बदला जा सकता है, लेकिन यह अभी भी मुझे अपडेट करने के लिए कार्य के साथ छोड़ देता है कि हर बार जब मैं एक नया प्रमुख संस्करण जारी करता हूं। व्यक्तिगत रूप से, मेरे पास एक मास्टर और एक v1 शाखा होगी, लेकिन मुझे यकीन नहीं है कि यह वास्तव में प्रस्ताव के अनुरूप कैसे होगा।

जैसा कि @AlexRouSg और शायद अन्य ने बताया, आप यह कर सकते हैं। मैं सिर्फ उनके उत्तरों की पुष्टि करना चाहता था। मैं इसे अक्सर पूछे जाने वाले प्रश्न में भी जोड़ूंगा।

https://github.com/golang/go/issues/24301#issuecomment -375989173, @aarondl :

हालांकि यह अब काम करता है, क्या इसका इरादा है?

बिलकुल हाँ।

@jamiethermo , विभिन्न निर्देशिकाओं में पर्सफोर्स और शाखाओं के बारे में टिप्पणी के लिए बहुत बहुत धन्यवाद। मैं उस विशेषता के बारे में भूल गया था, लेकिन हो सकता है कि इसने मुझे आश्वस्त किया कि vgo में अनुमति देना महत्वपूर्ण था।

वेंडरिंग बनाम प्रॉक्सी के बारे में https://github.com/golang/go/issues/24301#issuecomment -376925845 पर एक अच्छी चर्चा शुरू हुई है। यहां स्पष्ट रूप से दो अलग-अलग चिंताएं हैं।

ओपन सोर्स डेवलपर्स बुनियादी ढांचे पर भरोसा करने से बचना चाहते हैं, इसलिए वे वेंडरिंग चाहते हैं, जैसा कि @joeshaw ने लिखा है। पुष्टि करने के लिए, हम उस काम को सीमित रूप में रखेंगे (केवल समग्र लक्ष्य मॉड्यूल के शीर्ष स्तर पर विक्रेता निर्देशिका जहां आप गो कमांड चला रहे हैं)।

एंटरप्राइज़ डेवलपर्स को बुनियादी ढांचे पर भरोसा करने में कोई समस्या नहीं है - यह सिर्फ एक और लागत है - खासकर अगर यह कुछ बड़ी लागत में कमी लाता है, जैसे कि प्रत्येक रेपो में अपने सभी विक्रेता कोड को डुप्लिकेट नहीं करना और इसे सभी को सिंक में रखने में समय व्यतीत करना पड़ता है। अनिवार्य रूप से जिस कंपनी से हमने बात की है, वह प्रॉक्सी/दर्पण चाहता है, विक्रेता नहीं, जैसा कि @jamiethermo ने मांगा था। हम सुनिश्चित करेंगे कि यह भी काम करे।

हम एक साझा मिरर नेटवर्क भी बनाना चाहते हैं, जिस पर डेवलपर्स के पास भरोसा करने और भरोसा करने का कारण हो, ताकि सभी ओपन सोर्स डेवलपर्स को यह महसूस न हो कि उन्हें विक्रेता होना चाहिए। लेकिन वह बाद में है। पहले वीगो को गो बनने की जरूरत है।

https://github.com/golang/go/issues/24301#issuecomment -377220411, @ nim-nim:

कृपया इसे एक फ़ाइल के साथ काम करें: /// https: /// URL की ओर इशारा करते हुए एक निर्देशिका की ओर इशारा करते हुए एक ज़िप रूप में तीसरे पक्ष के मॉड्यूल (और बाकी सब को बाहर करें)

"बाकी सब कुछ छोड़ दें" कहकर मैं बिल्कुल निश्चित नहीं हूं कि आप क्या मांग रहे हैं। यदि $GOPROXY सेट है, तो vgo उस प्रॉक्सी से पूछता है। यह कभी वापस कहीं और नहीं गिरता। उस प्रॉक्सी को एक स्थिर फ़ाइल ट्री द्वारा परोसा जा सकता है, जो ज़िप रूप में अधिकतर तृतीय-पक्ष मॉड्यूल है। फ़ाइल ट्री में नेविगेशन और लुकअप के लिए कुछ अन्य मेटाडेटा फ़ाइलें भी होनी चाहिए। वे अतिरिक्त फाइलें अपरिहार्य हैं, क्योंकि HTTP हमें निर्देशिका सूची जैसी चीजों को करने का एक मानक तरीका नहीं देता है।

https://github.com/golang/go/issues/24301#issuecomment -377186949, @ nim-nim:

वाह, यह एक लंबी टिप्पणी है। मुझे लगता है कि आपने जो लिखा है, उसमें से अधिकांश से मैं सहमत हूं। मैं आपकी पोस्ट में आखिरी बुलेट का जवाब देना चाहता हूं:

• उच्च फ़िडेलिटी पुनर्निर्माण पिक्सेल-पूर्ण वेबसाइटों के समान हैं। वे स्पष्ट रूप से एक अच्छे विचार की तरह दिखते हैं, वे मूल लेखक अहंकार को पुरस्कृत करते हैं, लेकिन वे किसी के लिए भी एक PITA हैं जो वास्तव में परिणाम का उपयोग करने की कोशिश करते हैं क्योंकि वे विकसित नहीं होते हैं और स्थानीय (मूल नहीं) संदर्भ के अनुकूल होते हैं।

मुझे लगता है कि मैं तर्क दूंगा कि लॉक फाइलें पिक्सेल-परफेक्ट वेबसाइटों की तरह हैं। उच्च-निष्ठा, इसके विपरीत, संदर्भ परिवर्तन के रूप में इनायत से नीचा दिखाती है। डिफ़ॉल्ट रूप से, एक बिल्ड B 1.2 और C 1.4 का उपयोग करेगा। लेकिन फिर अगर यह एक बड़े निर्माण का हिस्सा है जिसे बी 1.3 की आवश्यकता है, तो ठीक है, यह बी 1.3 के साथ मिल जाएगा लेकिन अपग्रेड करने के लिए ठोस आवश्यकता के अभाव में सी 1.4 (भले ही नए मौजूद हों) रखें। तो वास्तव में उच्च-निष्ठा निर्माण दोनों दुनिया के सर्वश्रेष्ठ हैं: जहां तक ​​​​संभव हो मूल के प्रति वफादार, लेकिन जब यह संभव नहीं है तो पिक्सेल-परिपूर्ण पर जोर नहीं देते।

https://github.com/golang/go/issues/24301#issuecomment -375415904, @flibustenet :

@rsc मैं आपसे रोड मैप के बारे में और अधिक सटीक होने के लिए कहना चाहता हूं और अब हमें क्या करना चाहिए।
क्या यह गो नीति का पालन करेगा और 3 महीने (अभी 2) पर फ़्रीज़ वीगो की सुविधा देगा?

Vgo एक प्रोटोटाइप है और इसे कभी भी अपने आप जारी नहीं किया जाएगा। यह फ्रीज या किसी अन्य चीज के अधीन नहीं है। लेकिन यह प्रस्ताव विचारों और अधिकांश कोड को मुख्य cmd/go में स्थानांतरित करने का है। रिलीज के हिस्से के रूप में, cmd/go निश्चित रूप से फ्रीज के अधीन है। क्योंकि यह ऑप्ट-इन है और क्योंकि vgo-विशिष्ट कोड गो कमांड के बाकी संचालन से काफी अच्छी तरह से अलग है, vgo- विशिष्ट भागों पर काम करना काफी कम जोखिम है और मैं इसे कुछ हफ्तों तक जारी रख सकता हूं। फ्रीज में। अभी मैं प्रस्ताव चर्चा और समायोजन पर ध्यान केंद्रित कर रहा हूं। एक बार जब प्रस्ताव महत्वपूर्ण समस्याओं के बिना अच्छी स्थिति में प्रतीत होता है, तो हम कोड को cmd/go में स्थानांतरित कर देंगे।

क्या अब हमें अपने तीर्थयात्रियों के डंडे के साथ जाना चाहिए और प्रत्येक libs अनुरक्षक को एक go.mod फ़ाइल जोड़ने के लिए कहना चाहिए या क्या हमें प्रस्ताव को आधिकारिक रूप से स्वीकार किए जाने की प्रतीक्षा करनी चाहिए (यह सुनिश्चित करने के लिए कि नाम और वाक्य-विन्यास नहीं बदलेगा)?

मुझे लगता है कि go.mod सिंटैक्स बदलने की संभावना है (इस मुद्दे को देखें)। लेकिन जैसा कि मैंने प्रस्ताव में उल्लेख किया है, हम पुराने सिंटैक्स को हमेशा के लिए स्वीकार करते रहेंगे, और vgo केवल मौजूदा फाइलों को अपडेट करेगा, इसलिए यह कोई बड़ी बात नहीं है। उस ने कहा, मैं हर पुस्तकालय में पीआर भेजने की कोशिश नहीं करूँगा जब तक कि कोड cmd/go की विकास प्रति में भूमि न हो जाए।

https://github.com/golang/go/issues/24301#issuecomment -37664804, @pbx0 :

क्या यह आसान (आज) vgo के साथ यह निर्धारित करने के लिए है कि क्या आपके पास एक बिल्ड में पैकेज का 1 संस्करण अधिक है?

आज सबसे आसान काम है बाइनरी बनाना और फिर उस पर गोवर्सन-एम चलाना (देखें https://research.swtch.com/vgo-repro)। जब हमारे पास अधिक सामान्य मॉड्यूल-जागरूक सूची है, तो यह पहले बाइनरी के निर्माण के बिना वही काम करने में सक्षम होना चाहिए।

https://github.com/golang/go/issues/24301#issuecomment -376236546, @buro9 :

[क्या मैं एक बैकवर्ड-असंगत सुरक्षा परिवर्तन कर सकता हूं, जैसे कि माइक्रोकॉसम-सीसी/ ब्लूमॉन्डे@a5d7ef6? ]

जैसा कि @Merovius ने कहा, अगर हमें गो 1 संगतता दिशानिर्देशों को अपनाना है तो प्रमुख संस्करण को टक्कर दिए बिना सुरक्षा परिवर्तनों की स्पष्ट रूप से अनुमति है।

उस ने कहा, यहां तक ​​​​कि जब आपको सुरक्षा के लिए कुछ करना है, तब भी आपको कम से कम व्यवधान के लिए प्रयास करना चाहिए। यकीनन आप जिस प्रतिबद्धता से जुड़े हैं, वह आवश्यकता से अधिक विघटनकारी है, और भविष्य की स्थिति में मैं आपको इस दृष्टिकोण से इस तरह के बदलाव के लिए प्रोत्साहित करूंगा कि "मैं सुरक्षा समस्या को समाप्त करते हुए यथासंभव कम से कम ग्राहकों को कैसे तोड़ूं? "

उदाहरण के लिए, किसी फ़ंक्शन को न हटाएं। इसके बजाय, फ़ंक्शन को पैनिक करें या लॉग करें। केवल गलत तरीके से कॉल किए जाने पर घातक।

इस मामले में, AllowDocType को हटाने के बजाय, मैं इसे रखता और निश्चित रूप से AllowDocType (गलत) को स्वीकार करना जारी रखता, क्योंकि यह सुरक्षित सेटिंग है। अगर किसी ने आपकी लाइब्रेरी के लिए एक रैपर लिखा था, शायद एक कमांड लाइन प्रोग्राम के रूप में -allowdoctype ध्वज के साथ, तो उस ध्वज के बिना प्रोग्राम के कम से कम उपयोग काम करना जारी रखेंगे।

और फिर उससे परे, ऐसा लगता है कि चिंता यह थी कि सिद्धांत पूरी तरह से अनियंत्रित था, लेकिन शायद मैंने सबसे आम उपयोगों को काम करने के लिए न्यूनतम जांच में रखा होगा, और फिर रूढ़िवादी रूप से दूसरों को अस्वीकार कर दिया होगा। उदाहरण के लिए, कम से कम, मैं अनुमति देता रहता और शायद ..> को बिना किसी &#<>\ वर्णों के उद्धृत तारों के साथ अनुमति देने के लिए परेशान होता।

https://github.com/golang/go/issues/24301#issuecomment -375090551, @TocarIP :

[तुरंत अपडेट न मिलने की चिंता।]

मुझे सच में लगता है कि इसके विपरीत होगा, कि प्रोग्राम अधिक अद्यतित हो सकते हैं, क्योंकि न्यूनतम संस्करण चयन में समग्र निर्माण को नए संस्करण में अपडेट होने से रोकने के लिए एक निर्भरता के लिए यह _impossible_ है।

@Merovius ने https://github.com/golang/go/issues/24301#issuecomment -375992900 में जो लिखा वह मुझे बिल्कुल सही लगता है। मुख्य बिंदु यह है कि जब आप उनसे पूछते हैं तो आपको केवल अपडेट मिलते हैं, इसलिए चीजें (संभावित रूप से) तभी टूटती हैं जब आप इसकी अपेक्षा कर रहे हों और परीक्षण, डिबग आदि के लिए तैयार हों। आपको उनके लिए पूछना होगा, लेकिन लॉक फ़ाइलों वाले अन्य सिस्टम की तुलना में अधिक बार नहीं। और हम "आप एक बहिष्कृत/असुरक्षित संस्करण के साथ निर्माण कर रहे हैं" जैसी चेतावनियों को सतह पर लाना आसान बनाना चाहते हैं। लेकिन यह महत्वपूर्ण है कि नॉन-अपडेट ऑपरेशंस के साइड इफेक्ट के रूप में केवल चुपचाप अपडेट न करें।

एफएक्यू में भी जोड़ा गया।

अब तक की शानदार चर्चा और एक-दूसरे के सवालों के जवाब देने के लिए सभी का धन्यवाद। बहुत सारे लोगों से वास्तव में बहुत अच्छे उत्तर, लेकिन @Merovius और @kardianos के लिए विशेष धन्यवाद। मैंने अक्सर पूछे जाने वाले प्रश्न https://github.com/golang/go/issues/24301#issuecomment -371228664 और चर्चा सारांश https://github.com/golang/go/issues/24301#issuecomment -371228742 को अपडेट कर दिया है। ऐसे तीन महत्वपूर्ण प्रश्न हैं जिनका उत्तर अभी तक नहीं दिया गया है (वे सारांश में TODO कहते हैं), जिन पर मैं आगे काम करूंगा। :-)

@rsc , #24057 में ज़िप के बजाय टैर का उपयोग करने पर कुछ चर्चा है।

https://github.com/golang/go/issues/24301#issuecomment -375106068, @leonklingele :

यदि गो गेट के लिए समर्थन जैसा कि हम आज जानते हैं, इसे हटा दिया जाएगा और अंततः हटा दिया जाएगा, तो गो बायनेरिज़ को लाने और स्थापित करने का अनुशंसित तरीका क्या है?

यह अभी भी जाना होगा। यदि बाइनरी का रेपो अचिह्नित है, तो गो गेट नवीनतम कमिट का उपयोग करेगा। लेकिन वास्तव में बाइनरी प्रकाशित करने वाले लोगों को युक्त रेपो को पुस्तकालयों (या मिश्रण) वाले रेपो के समान टैग करने के लिए प्रोत्साहित किया जाना चाहिए।

यदि $GOPATH को पदावनत कर दिया जाता है, तो इन बायनेरिज़ को कहाँ स्थापित किया जाएगा?

आपको अब $GOPATH में काम करने की आवश्यकता नहीं है, लेकिन कोड अभी भी $GOPATH में सूचीबद्ध पहली निर्देशिका में लिखा गया है - यह स्रोत कैश है, vgo का उपयोग करने के बाद $GOPATH/src/v देखें। $GOPATH/bin में बायनेरिज़ स्थापित हैं। कुछ रिलीज़ पहले के रूप में आपको $GOPATH सेट करने की आवश्यकता नहीं है - इसमें एक डिफ़ॉल्ट, $HOME/go है। तो क्या होना चाहिए कि डेवलपर्स $GOPATH को सेट करने या यहां तक ​​​​कि यह जानने के बारे में चिंता करना बंद कर दें कि यह क्या है, और वे सिर्फ यह सीखते हैं कि उनके बायनेरिज़ $HOME/go/bin में हैं। वे उस स्थान को ओवरराइड करने के लिए $GOBIN का उपयोग कर सकते हैं।

@dsnet , धन्यवाद मैंने चर्चा सारांश में एक लिंक जोड़ा। चलिए उस चर्चा को वहीं रखते हैं।

यदि $GOPROXY सेट है, तो vgo उस प्रॉक्सी से पूछता है। यह कभी वापस कहीं और नहीं गिरता। उस प्रॉक्सी को एक स्थिर फ़ाइल ट्री द्वारा परोसा जा सकता है, जो ज़िप रूप में अधिकतर तृतीय-पक्ष मॉड्यूल है। फ़ाइल ट्री में नेविगेशन और लुकअप के लिए कुछ अन्य मेटाडेटा फ़ाइलें भी होनी चाहिए। वे अतिरिक्त फाइलें अपरिहार्य हैं, क्योंकि HTTP हमें निर्देशिका सूची जैसी चीजों को करने का एक मानक तरीका नहीं देता है।

जब तक मूल मॉड्यूल को ज़िप रूप में रखा जाता है, उनके साथ छेड़छाड़ करने के किसी भी प्रलोभन को हटा दिया जाता है, और इंडेक्सर मजबूत और हल्का होता है जो ठीक है।

हालांकि लिस्टिंग बाधाएं फाइलों पर लागू नहीं होती हैं और एलएफटीपी जैसे यूटिलिट्स उम्र के लिए http निर्देशिकाओं को सूचीबद्ध करने में सक्षम हैं (इससे कोई फर्क नहीं पड़ता कि यह गैर-मानक है अगर यह प्रमुख http सर्वर पर काम करता है)। इसलिए इंडेक्स-लेस ऑपरेशन संभवत: उन छोटी संस्थाओं के लिए संभव और बेहतर है जो इंफ्रा में निवेश नहीं करना चाहते हैं। yum/dnf/zipper भी कस्टम इंडेक्स पर निर्भर करता है और एक साझा निर्देशिका को अनुक्रमित करना हमेशा उतना आसान नहीं होता जितना आप कुछ संगठनों में सोच सकते हैं।

ओपन सोर्स डेवलपर्स बुनियादी ढांचे पर भरोसा करने से बचना चाहते हैं, इसलिए वे वेंडरिंग चाहते हैं, जैसा कि @joeshaw ने लिखा

वास्तव में नहीं, ओपन सोर्स डेवलपर्स ज्यादातर चाहते हैं कि पूरी प्रक्रिया खुली और पारदर्शी हो, और किसी और की शुभकामनाओं पर भरोसा न करना पड़े। तो इंफ्रा पूरी तरह से ठीक है जब तक कि यह स्वयं खुला स्रोत है और स्थानीय रूप से तैनात करना आसान और सस्ता है। जीथब जैसी विशाल ब्लैकबॉक्स स्वामित्व वाली साइटों पर निर्भर होना स्पष्ट रूप से इस श्रेणी में नहीं आता है, लेकिन यह इंफ्रा जैसी चीज नहीं है। ओपन सोर्स लोगों ने हर किसी से दशकों पहले दर्पण किया था। वे जो स्वीकार नहीं करेंगे वे बंद हैं और दर्पण स्थापित करने के लिए महंगे हैं (खुले स्रोत के संदर्भ में महंगा मानव समय में मापा जाता है)

वेंडरिंग की खुली आसान और सस्ती प्रकृति की सराहना की जाती है, स्वयं वेंडरिंग प्रक्रिया और जिस तरह से यह थर्ड पार्टी कोड के अप्रचलित संस्करणों पर कोडबेस के प्रगतिशील जीवाश्मीकरण को प्रोत्साहित करता है, इतना नहीं।

एंटरप्राइज़ डेवलपर्स को बुनियादी ढांचे पर भरोसा करने में कोई समस्या नहीं है - यह सिर्फ एक और लागत है

Google में काम करना बहुत अच्छा होगा :(। मौजूदा बड़े गो ऑपरेशन के साथ कुछ उद्यमों को छोड़कर जहां गो इंफ्रा में निवेश करना कोई ब्रेनर नहीं है, बाकी सभी को लंबी और थकाऊ अनुमोदन प्रक्रियाओं से गुजरना होगा , अगर केवल समस्या को देखने के लिए किसी को भुगतान करने का औचित्य साबित करने के लिए। तो किसी भी बुनियादी लागत से गो पहुंच कम हो जाएगी और नई संरचनाओं द्वारा इसे अपनाने से रोक दिया जाएगा।

उद्यम ओपनसोर्सर्स की तरह हैं, वे सस्ते और आसान की परवाह करते हैं। वे खुले के बारे में बिल्कुल भी परवाह नहीं करते थे, लेकिन अब यह धीरे-धीरे बदल रहा है कि उन्हें एहसास हुआ कि यह सस्ते से संबंधित है (पारंपरिक एंटरप्राइज़ आपूर्तिकर्ताओं की निराशा के लिए जो महंगे ब्लैकबॉक्स समाधानों पर महंगे परामर्श के साथ तैनाती में सहायता के लिए उपयोग करते थे)।

सबसे कम बोली लगाने वाले को आंतरिक आईटी अनुबंधित करने वाले उद्यम निश्चित रूप से दर्पणों पर जोर देंगे क्योंकि वे निश्चित रूप से नहीं चाहते हैं कि उनके सस्ते-गधा डेवलपर्स टूटे या खतरनाक कोड को डाउनलोड करें जो डेवलपर्स इंटरनेट से नहीं समझते हैं। वे समस्याओं के लिए स्थानीय दर्पण सामग्री को स्कैन करने के लिए मनुष्यों और उपकरणों का भुगतान करेंगे, और आंतरिक आईटी को विशेष रूप से इसका उपयोग करने के लिए मजबूर करेंगे।

हम एक साझा मिरर नेटवर्क भी बनाना चाहते हैं, जिस पर डेवलपर्स के पास भरोसा करने और भरोसा करने का कारण हो, ताकि सभी ओपन सोर्स डेवलपर्स को यह महसूस न हो कि उन्हें विक्रेता होना चाहिए।

बस एक अनुक्रमित निर्देशिका की संदर्भ प्रति प्रकाशित करें जिसमें कहीं मॉड्यूल हों। किसी भी प्रॉक्सी-जैसे सेटअप के बारे में भूल जाएं जिसके लिए विशिष्ट वेब सर्वर कॉन्फ़िगरेशन की आवश्यकता होती है। ओपन सोर्सर्स यही करते हैं और उन्हें खुद को प्रतिबिंबित करने में कोई कठिनाई नहीं होती है। जब तक मिररिंग सिर्फ एक निर्देशिका की सामग्री की प्रतिलिपि बना रहा है और एक विशिष्ट वेबसर्वर कॉन्फ़िगरेशन की आवश्यकता नहीं है, तब तक बहुत सारे संगठन दर्पण के इच्छुक हैं।

जनरेट किए गए कोड के लिए आम तौर पर, एक वास्तविक क्रॉस-लैंग्वेज बिल्ड सिस्टम इसका उत्तर है,

आप मेरे साथ-साथ जानते हैं कि ऐसा कभी नहीं होगा, कोई हमेशा एक नई भाषा का आविष्कार करना चाहेगा जो अपना सामान करे। यह एक स्ट्रॉमैन तर्क है।

यह गो को एक मानक कमांड को सामान्य करने से नहीं रोकता है जो किसी भी प्रोजेक्ट-विशिष्ट प्रक्रिया को कोड उत्पन्न करता है, इस पर सख्त दिशानिर्देशों के साथ कि यह क्या कर सकता है और क्या नहीं (आमतौर पर इसे मानक गो कमांड द्वारा पहले से ही कवर किया गया कुछ भी नहीं करना चाहिए, क्योंकि उन आदेशों को चाहिए पहले से ही ठीक हो)।

विशेष रूप से क्योंकि हम नहीं चाहते कि प्रत्येक उपयोगकर्ता को सही जनरेटर स्थापित करने की आवश्यकता हो। लेखक के लिए जनरेटर चलाने और परिणाम की जांच करने के लिए बेहतर है।

इसके लिए मौजूदा जनरेटर को कैसे लागू किया जाता है, इस पर एक बड़े पुनर्विचार की आवश्यकता होगी, क्योंकि अभी वे संस्करण पोर्टेबिलिटी के बारे में बिल्कुल भी परवाह नहीं करते हैं और उम्मीद करते हैं कि पीढ़ी से पहले सॉफ्टवेयर वातावरण जम जाएगा। प्रत्यक्ष प्रभाव के साथ कि जनरेटिंग किसी भी बाद के संस्करण को पुनर्जनन के बिना खतरनाक बना देता है। इससे कोई फर्क नहीं पड़ता कि परिणाम मनुष्यों द्वारा जाँचा गया है या नहीं, क्योंकि मनुष्य केवल मूल संस्करण सेट के विरुद्ध जाँच करेगा। vgo बाद के संस्करण परिवर्तन करने में सक्षम होने पर निर्भर करता है।

इसलिए vgo को जल्दी या बाद में पुनर्जनन से निपटना होगा। बाद में इसका मतलब है कि परियोजनाओं की प्रतीक्षा में यह पता चलता है कि उत्पन्न कोड की उपस्थिति में वीजीओ अपडेट खतरनाक हैं।

https://github.com/golang/go/issues/24301#issuecomment -374791885, @jimmyfrasche :

यह डेटाबेस ड्राइवरों और छवि प्रारूपों जैसी चीजों को भी प्रभावित करेगा जो खुद को init के दौरान किसी अन्य पैकेज के साथ पंजीकृत करते हैं, क्योंकि एक ही पैकेज के कई प्रमुख संस्करण ऐसा कर सकते हैं। यह मेरे लिए स्पष्ट नहीं है कि इसके सभी परिणाम क्या होंगे।

हां, कोड की समस्या जो मानती है कि "एक कार्यक्रम में इनमें से सिर्फ एक होगा" वास्तविक है, और यह कुछ ऐसा है जिसे हम सभी को नए (बेहतर) सर्वोत्तम प्रथाओं और सम्मेलनों को स्थापित करने के लिए काम करना होगा। मुझे नहीं लगता कि यह समस्या vgo द्वारा पेश की जा रही है, और vgo यकीनन स्थिति को पहले से बेहतर बनाता है।

मैं समझता हूं कि कुछ लोगों का तर्क है कि vgo को Dep के नियम को अपनाना चाहिए कि एक साथ 1.x और 2.x भी नहीं हो सकते हैं, लेकिन यह स्पष्ट रूप से उस बड़े कोड बेस के पैमाने पर नहीं है जिसे हम Go के साथ लक्षित कर रहे हैं। vgo-import पोस्ट से पता चलता है कि पूरे बड़े प्रोग्राम को एक बार में एक एपीआई से दूसरे एपीआई में अपग्रेड करने की उम्मीद करना अव्यावहारिक है। मेरा मानना ​​​​है कि अनिवार्य रूप से अन्य सभी पैकेज प्रबंधक एक ही कारण से 1.x और 2.x को एक साथ अनुमति देते हैं। निश्चित रूप से कार्गो करता है।

सामान्य तौर पर vgo वेंडरिंग की तुलना में दोहराव को कम करता है। वेंडरिंग के साथ किसी दिए गए पैकेज के 1.2, 1.3, और 1.4 को एक बाइनरी में, इसे साकार किए बिना, या शायद 1.2 की तीन प्रतियों के साथ समाप्त करना आसान है। कम से कम vgo संभावित दोहराव को एक 1.x, एक 2.x, और इसी तरह काट देता है।

यह पहले से ही मामला है कि विभिन्न पैकेजों के लेखकों को यह सुनिश्चित करने की ज़रूरत है कि एक ही चीज़ को पंजीकृत करने का प्रयास न करें। उदाहरण के लिए, expvar http.Handle("/debug/vars") करता है और अनिवार्य रूप से उस पथ पर दावा करता है। मुझे उम्मीद है कि हम सभी इस बात से सहमत हैं कि Awesome.io/supervars जैसे तीसरे पक्ष के पैकेज को उसी पथ को पंजीकृत करने का प्रयास नहीं करना चाहिए। यह एक पैकेज के कई संस्करणों के बीच संघर्ष छोड़ देता है।

अगर हम expvar/v2 पेश करते हैं, तो वह एक दूसरा, अलग पैकेज बन जाता है, जैसे कि Awesome.io/supervars, और यह एक बड़े निर्माण में expvar के साथ संघर्ष कर सकता है। पर्यवेक्षकों के विपरीत, हालांकि, expvar/v2 expvar के समान व्यक्ति या टीम के स्वामित्व में है, इसलिए दो पैकेज पंजीकरण साझा करने के लिए समन्वय कर सकते हैं। यह निम्नानुसार काम करेगा। मान लीजिए कि expvar v1.5.0 अंतिम है, इससे पहले कि हम v2 लिखने का निर्णय लें, इसलिए v1.5.0 में एक http.Handle है। हम चाहते हैं कि v2 v1 के लिए प्रतिस्थापन हो, इसलिए हम http.Handle को v2.0.0 पर ले जाएंगे और v2 में API जोड़ देंगे जो v1 को अपनी कॉल को v2 पर अग्रेषित करने की अनुमति देता है। फिर हम v1.6.0 बनाएंगे जो इस अग्रेषण के साथ लागू किया गया है। v1.6.0 http.Handle को कॉल नहीं करता है; यह दर्शाता है कि v2.0.0. अब expvar v1.6.0 और expvar/v2 सह-अस्तित्व में हो सकते हैं, क्योंकि हमने इसकी योजना इस तरह से बनाई थी। एकमात्र समस्या यह है कि क्या होता है यदि कोई बिल्ड expvar v1.5.0 का उपयोग expvar/v2 के साथ करता है? हमें यह सुनिश्चित करने की जरूरत है कि ऐसा न हो। हम ऐसा करते हैं कि expvar/v2 को v1.6.0 (या बाद में) पर expvar की आवश्यकता होती है, भले ही उस दिशा में कोई आयात न हो, और निश्चित रूप से expvar v1.6.0 को expvar/v2 को v2.0.0 या बाद में अपने API को कॉल करने की आवश्यकता होती है। . यह आवश्यकता चक्र हमें यह सुनिश्चित करने देता है कि v1.5.0 और v2 कभी मिश्रित न हों। इस तरह के क्रॉस-मेजर-वर्जन समन्वय के लिए योजना बनाना ठीक यही कारण है कि न्यूनतम संस्करण चयन आवश्यकता ग्राफ में चक्रों की अनुमति देता है।

आवश्यकता ग्राफ में चक्रों को अनुमति देने के साथ संयुक्त "केवल एक प्रमुख संस्करण" नियम लेखकों को उनके मॉड्यूल के विभिन्न प्रमुख संस्करणों के बीच सिंगलटन (और सिंगलटन स्वामित्व के माइग्रेशन) के उचित समन्वय को प्रबंधित करने के लिए आवश्यक टूल देता है। हम समस्या को खत्म नहीं कर सकते हैं, लेकिन हम लेखकों को इसे हल करने के लिए आवश्यक उपकरण दे सकते हैं।

मुझे पता है कि विशेष रूप से प्रोटोकॉल बफ़र्स में पंजीकरण समस्याएं होती हैं, और उन समस्याओं को बहुत ही तदर्थ तरीके से बढ़ा दिया जाता है कि प्रोटोकॉल .pb.go फाइलें पास की जाती हैं और परियोजनाओं में कॉपी की जाती हैं। यह फिर से कुछ ऐसा है जो ज्यादातर vgo से स्वतंत्र है। हमें इसे ठीक करना चाहिए, लेकिन संभवत: गो प्रोटोकॉल बफ़र्स का उपयोग करने के तरीके में बदलाव करके, vgo नहीं।

https://github.com/golang/go/issues/24301#issuecomment -374739116, @ChrisHines :

मैं एक पूर्व-वीजीओ दुनिया और एक वीजीओ दुनिया के बुरी तरह से चल रहे प्रवास पथ के बारे में सबसे ज्यादा चिंतित हूं। [ज्यादा जानकारी]

मैं वास्तव में खुश हूं कि प्रस्ताव पर यह पहली टिप्पणी थी। यह स्पष्ट रूप से सही होने के लिए सबसे महत्वपूर्ण बात है।

पुराने गो गेट से संक्रमण और नए मॉड्यूल सिस्टम के लिए असंख्य वेंडरिंग टूल्स को अविश्वसनीय रूप से सुचारू रूप से चलाना है। मैं हाल ही में बहुत सोच रहा हूं कि यह कैसे काम करेगा।

मूल प्रस्ताव डेवलपर्स को एक मॉड्यूल के संस्करण 2 को एक रेपो उपनिर्देशिका में v2/. उस विकल्प का प्रयोग करने से डेवलपर्स को एक रेपो बनाने की अनुमति मिल जाएगी जो अर्थपूर्ण आयात संस्करण का उपयोग करता है, मॉड्यूल के साथ संगत है, और फिर भी पुराने "गो गेट" के साथ पीछे की ओर संगत है। इस विकल्प का वर्णन करने वाला पोस्ट स्वीकार करता है कि अधिकांश परियोजनाएं इस विकल्प का प्रयोग नहीं करना चाहेंगी, जो ठीक है। यह केवल संगतता के लिए आवश्यक है यदि कोई प्रोजेक्ट पहले से ही v2 या बाद में है। उसी समय, मैंने व्यापक रूप से उपयोग की जाने वाली बड़ी परियोजनाओं की संख्या को कम करके आंका जो कि v2 या बाद में हैं। उदाहरण के लिए:

• github.com/godbus/dbus v4.1.0 (462 पैकेजों द्वारा आयातित) पर है।
• github.com/coreos/etcd/clientv3 v3.3.3 (799 पैकेज द्वारा आयातित) पर है।
• k8s.io/client-go/kubernetes v6.0.0 (1928 पैकेज द्वारा आयातित) पर है।

अपने ग्राहकों को तोड़ने से बचने के लिए, उन परियोजनाओं को एक उपनिर्देशिका में स्थानांतरित करने की आवश्यकता होगी जब तक कि सभी ग्राहकों को मॉड्यूल का उपयोग करने के लिए नहीं माना जा सके, और फिर रूट पर वापस जाएं। यह पूछने के लिए बहुत कुछ है।

गिट सबमॉड्यूल्स के साथ एक ट्रिक खेलने का एक और विकल्प। पुराना गो गेट कमांड रेपो की डिफ़ॉल्ट शाखा पर "go1" नामक एक टैग या शाखा को प्राथमिकता देता है, इसलिए एक प्रोजेक्ट जो एक सहज संक्रमण को सक्षम करना चाहता था, वह "go1" शाखा पर एक प्रतिबद्धता बना सकता था जिसमें केवल "v2" उपनिर्देशिका सेट थी। वास्तविक रेपो रूट पर वापस इशारा करते हुए एक गिट सबमिशन के रूप में। जब "गो गेट" ने उस go1 शाखा और आबादी वाले सबमॉड्यूल की जाँच की, तो उसे सही फ़ाइल ट्री लेआउट मिलेगा। हालांकि, यह बहुत ही भयानक है, और हर बार एक नई रिलीज किए जाने पर सबमॉड्यूल पॉइंटर्स को अपडेट करने की आवश्यकता होगी।

इन दोनों का दुर्भाग्यपूर्ण प्रभाव है कि लेखकों को अपने उपयोगकर्ताओं को तोड़ने से बचने के लिए कदम उठाने चाहिए, और तब भी केवल नई रिलीज़ के लिए। इसके बजाय हम चाहते हैं कि उपयोगकर्ताओं का कोड लेखकों द्वारा अतिरिक्त काम किए बिना भी काम करता रहे, और आदर्श रूप से पुरानी रिलीज़ के लिए भी।

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

मूल रूप से, दो अलग-अलग आयात पथ परंपराएं हैं: पुराना वाला, बिना किसी बड़े संस्करण के, और नया वाला, प्रमुख संस्करणों के साथ v2 या बाद में। एक पुराने पेड़ में कोड शायद पुराने सम्मेलन का उपयोग करता है, जबकि एक नए पेड़ में कोड - एक निर्देशिका के तहत जिसमें एक go.mod फ़ाइल होती है - शायद नए सम्मेलन का उपयोग करती है। हमें एक संक्रमण के दौरान दो सम्मेलनों को ओवरलैप करने का एक तरीका चाहिए। यदि हम पुराने गो को सिमेंटिक इंपोर्ट वर्जनिंग के बारे में एक छोटी राशि प्राप्त करना सिखाते हैं, तो हम ओवरलैप की मात्रा को काफी बढ़ा सकते हैं।

प्रस्तावित परिवर्तन: "नया" कोड को उसी निर्देशिका या मूल निर्देशिका में go.mod फ़ाइल के साथ कोड के रूप में परिभाषित करें। पुराने गो गेट को हमेशा की तरह कोड डाउनलोड करना जारी रखना चाहिए। मेरा प्रस्ताव है कि "गो बिल्ड" चरण "नए" कोड में आयात की इसकी हैंडलिंग को समायोजित करता है। विशेष रूप से, यदि नए कोड में एक आयात x/y/v2/z कहता है लेकिन x/y/v2/z मौजूद नहीं है और x/y/go.mod "मॉड्यूल x/y/v2" कहता है, तो गो बिल्ड पढ़ेगा इसके बजाय x/y/z के रूप में आयात करें। हम इस अपडेट को गो 1.9 और गो 1.10 के लिए एक बिंदु रिलीज के रूप में आगे बढ़ाएंगे।

अपडेट : #25069 पर कॉपी किया गया।

उस परिवर्तन से मॉड्यूल-अनजान पैकेजों के लिए मॉड्यूल-जागरूक पैकेजों के नए संस्करणों का उपयोग करना संभव हो जाना चाहिए, चाहे वे पैकेज अपने रेपो को संरचित करने के लिए "प्रमुख शाखा" या "प्रमुख उपनिर्देशिका" दृष्टिकोण चुनते हैं। उन्हें अब उपनिर्देशिका दृष्टिकोण में मजबूर नहीं किया जाएगा, लेकिन यह अभी भी एक कार्यशील विकल्प होगा। और पुराने गो रिलीज का उपयोग करने वाले डेवलपर्स अभी भी कोड बनाने में सक्षम होंगे (कम से कम बिंदु रिलीज को अपडेट करने के बाद)।

@rsc मैं यह पता लगाने की कोशिश कर रहा हूं कि हम vgo काम में कैसे बदलाव कर सकते हैं, मैं उसी निष्कर्ष पर आया हूं जिसे आपने अपनी प्रतिक्रिया में रखा था और आपका सुझाव मेरे द्वारा आए सर्वोत्तम दृष्टिकोण से मेल खाता है अपने दम पर। मुझे आपका प्रस्तावित परिवर्तन पसंद है।

https://github.com/golang/go/issues/24301#issuecomment -377527249, @rsc :

फिर हम v1.6.0 बनाएंगे जो इस अग्रेषण के साथ लागू किया गया है। v1.6.0 http.Handle को कॉल नहीं करता है; यह दर्शाता है कि v2.0.0 को। अब expvar v1.6.0 और expvar/v2 सह-अस्तित्व में हो सकते हैं, क्योंकि हमने इसकी योजना इस तरह से बनाई थी।

यह जितना आसान लगता है उससे कहीं ज्यादा आसान लगता है। हकीकत में, ज्यादातर मामलों में, इसका मतलब v1.6.0 को v2 रैपर के रूप में v1 का पूर्ण पुनर्लेखन होना चाहिए _(http.Handle पर अग्रेषित कॉल के परिणामस्वरूप एक और हैंडलर पंजीकृत हो जाएगा - एक v2 से - जिसका बदले में सभी संबंधित कोड भी पंजीकृत हैंडर के साथ सही ढंग से बातचीत करने के लिए v2 से होना चाहिए)_।

यह बहुत संभावना है कि v1 व्यवहार के बारे में सूक्ष्म विवरण बदल जाएगा, विशेष रूप से समय के साथ, जैसे v2 विकसित होता है। भले ही हम इन सूक्ष्म विवरण परिवर्तनों की भरपाई करने में सक्षम हों और v1 को v1.6.x में पर्याप्त रूप से अनुकरण कर सकें - फिर भी, यह बहुत अधिक अतिरिक्त काम है और बहुत संभावना है कि यह v1 शाखा का भविष्य का समर्थन करता है (मेरा मतलब v1.5.0 के उत्तराधिकारी हैं) यहाँ) अर्थहीन।

@ पावरमैन , मैं बिल्कुल नहीं कह रहा हूं कि यह मामूली है। और आपको केवल इस हद तक समन्वय करने की आवश्यकता है कि v1 और v2 कुछ साझा संसाधनों जैसे http पंजीकरण पर लड़ते हैं। लेकिन इस पैकेजिंग पारिस्थितिकी तंत्र में भाग लेने वाले डेवलपर्स को यह समझने की आवश्यकता है कि उनके पैकेजों के v1 और v2 को बड़े कार्यक्रमों में सह-अस्तित्व की आवश्यकता होगी। कई पैकेजों को किसी भी काम की आवश्यकता नहीं होगी - उदाहरण के लिए, yaml और ब्लैकफ्राइडे, दोनों v2 पर हैं जो v1 से पूरी तरह से अलग हैं लेकिन लड़ने के लिए कोई साझा स्थिति नहीं है, इसलिए स्पष्ट समन्वय की कोई आवश्यकता नहीं है - लेकिन अन्य करेंगे।

@पॉवरमैन @rsc
मैं एक जीयूआई पैकेज विकसित कर रहा हूं जिसका अर्थ है कि "मुख्य" धागे के उपयोग के कारण मेरे पास 2+ उदाहरण भी नहीं हो सकते हैं। तो सबसे खराब स्थिति सिंगलटन परिदृश्य से आते हुए, मैंने यही करने का फैसला किया है।

• केवल एक v0/v1 रिलीज़ है, इसलिए 2+ संस्करण आयात करना असंभव है

• अपने स्वयं के एपीआई संस्करण फ़ोल्डर में सार्वजनिक कोड रखें, उदाहरण के लिए v1/v2 मानते हुए कि vgo इसे या शायद api1/api2 की अनुमति देता है।

• वे सार्वजनिक एपीआई पैकेज तब एक आंतरिक पैकेज पर निर्भर होंगे, इसलिए v2 पर फिर से लिखने के बजाय, यह एक रोलिंग रीराइट है क्योंकि पैकेज बढ़ता है और इसे संभालना बहुत आसान होता है।

https://github.com/golang/go/issues/24301#issuecomment -377529520 में प्रस्तावित परिवर्तन "नया" कोड को उसी निर्देशिका या मूल निर्देशिका में go.mod फ़ाइल के साथ कोड के रूप में परिभाषित करता है। क्या इसमें उदाहरण के लिए एक Gopkg.toml से निर्भरता में पढ़ने से बनाई गई "संश्लेषित" go.mod फ़ाइलें शामिल हैं?

@zeebo , हाँ। यदि आपके पास अपने पेड़ में go.mod फ़ाइल है तो धारणा यह है कि आपका कोड वास्तव में vgo. यदि नहीं, तो rm go.mod (या कम से कम इसे अपने रेपो में चेक न करें जहां अन्य इसे ढूंढ सकें)।

@AlexRouSg , आपके GUI पैकेज के लिए आपकी योजना मेरे लिए मायने रखती है।

@rsc हम्म .. मुझे यकीन नहीं है कि मैं समझता हूं और क्षमा करें अगर मैं अस्पष्ट था। क्या फ़ाइल ट्री में केवल एक Gopkg.toml वाला पैकेज परिभाषा के लिए "नया" के रूप में गिना जाता है?

@ आरएससी

जनरेट किए गए कोड के लिए अधिक सामान्य रूप से, एक वास्तविक क्रॉस-लैंग्वेज बिल्ड सिस्टम उत्तर है, विशेष रूप से क्योंकि हम नहीं चाहते कि प्रत्येक उपयोगकर्ता को सही जनरेटर स्थापित करने की आवश्यकता हो। लेखक के लिए जनरेटर चलाने और परिणाम की जांच करने के लिए बेहतर है।

हम प्रोटोबफ को GOPATH में मैप करके इसे हल करने में कामयाब रहे। हां, हमारे पास ऐसा है कि आकस्मिक उपयोगकर्ताओं को अपडेट करने के लिए टूल की आवश्यकता नहीं होती है, लेकिन प्रोटोबफ को संशोधित और पुन: उत्पन्न करने वालों के लिए, प्रोटोबिल्ड में समाधान बहुत अच्छी तरह से काम करता है।

यहां जवाब काफी निराशाजनक है। एक नई बिल्ड सिस्टम ढूंढना जो अस्तित्व में नहीं है, केवल एक गैर-उत्तर है। यहां वास्तविकता यह है कि हम इन बिल्ड सिस्टम का पुनर्निर्माण नहीं करेंगे और हम नए vgo सिस्टम को अपनाने से बचते हुए, जो काम करता है उसका उपयोग करना जारी रखेंगे।

क्या vgo सिर्फ उन लोगों के लिए दिवालियेपन की घोषणा करता है जिन्होंने GOPATH को पसंद किया और अपनाया और इसके मुद्दों पर काम किया?

@zeebo , नहीं, एक Gopkg.toml होने की गिनती नए के रूप में नहीं होती है; यहाँ "नया" का अर्थ है vgo-style (अर्थात् आयात संस्करण) आयात का उपयोग करना।

@stevvooe :

हम प्रोटोबफ को GOPATH में मैप करके इसे हल करने में कामयाब रहे। ...
क्या vgo सिर्फ उनके लिए दिवालियेपन की घोषणा करता है जिन्होंने GOPATH को पसंद किया और अपनाया और इसके मुद्दों पर काम किया?

मैंने आपके प्रोटोबिल्ड को नहीं देखा है, लेकिन सामान्य तौर पर, हाँ, हम एक गैर-GOPATH मॉडल की ओर बढ़ रहे हैं, और GOPATH द्वारा सक्षम की गई कुछ तरकीबें पीछे रह जाएंगी। उदाहरण के लिए GOPATH ने मूल गोडेप को वेंडरिंग समर्थन के बिना वेंडरिंग का अनुकरण करने में सक्षम बनाया। यह अब संभव नहीं होगा। एक त्वरित नज़र में, ऐसा लगता है कि प्रोटोबिल्ड इस धारणा पर आधारित है कि यह फ़ाइलों (pb.go) को अन्य पैकेजों में छोड़ सकता है जो आपके पास नहीं हैं। उस तरह के वैश्विक संचालन का अब समर्थन नहीं किया जाएगा, नहीं। मैं यह सुनिश्चित करने के बारे में पूरी तरह से गंभीर और ईमानदार हूं कि प्रोटोबफ अच्छी तरह से समर्थित हैं, vgo से अलग हैं। @neild शायद सुझाव सुनने में दिलचस्पी लेंगे लेकिन शायद इस मुद्दे पर नहीं।

@stevvooe ने https://github.com/golang/go/issues/24301#issuecomment -377602765 में @rsc की टिप्पणियां दीं मैंने https://github.com/golang/protobuf/issues/526 को क्रॉस रेफर किया है वह मुद्दा vgo कोण को कवर करते हुए समाप्त होता है। अगर चीजें कहीं और निपटाई जाती हैं तो मुझे यकीन है कि @dsnet et al हमें साइनपोस्ट करेंगे।

नोट: मैंने पिछली टिप्पणियों को करीब से नहीं देखा, ऐसा लगता है कि समस्या अलग दृष्टिकोण से हल हो गई है। नीचे मेरा विचार था।

एक विचार है।

कैसे के बारे में vgo get जागरूक विशिष्ट टैग जैसे vgo-v1-lock?
जब किसी रिपॉजिटरी में टैग होता है, तो वह अन्य संस्करण टैग को अनदेखा कर सकता है, और टैग पर पिन कर सकता है।

इसलिए, जब एक रिपॉजिटरी ने v2.1.3 को अंतिम संस्करण के रूप में टैग किया,
लेकिन मालिक भी vgo-v1-lock टैग को उसी कमिट पर धकेलता है जिसे v2.1.3 टैग किया गया है
यह go.mod . लिख सकता है

require (
    "github.com/owner/repo" vgo-v1-lock
)

इसे तब तक अपडेट नहीं किया जाना चाहिए जब तक कि vgo get -u , जब तक कि रिपॉजिटरी के मालिक ने टैग को बदल या हटा नहीं दिया।
यह बड़े भंडारों को उनके स्थानांतरण के लिए तैयार करना आसान बना सकता है।

जब एक पुस्तकालय लेखक तैयार किया जाता है, तो लेखक उपयोगकर्ता को घोषणा कर सकता है
कि वे "/ v2" को इसके आयात पथ में डालकर मैन्युअल रूप से अपडेट कर सकते हैं।

हम उस मामले को कैसे संभालेंगे जहां एक गहरी निर्भरता को पैच करने की आवश्यकता है (उदाहरण के लिए एक सीवीई फिक्स लागू करने के लिए जिसे मूल लेखक ने अभी तक एक टैग में जारी नहीं किया है)। ऐसा लगता है कि विक्रेता रणनीति इसे संभाल सकती है क्योंकि आप मूल लेखकों के रिलीज के लिए एक पैच लागू कर सकते हैं। यह न देखें कि वीजीओ इसे कैसे संभाल सकता है।

@chirino आप पैच पैकेज को इंगित करने के लिए go.mod फ़ाइल में बदलें निर्देश का उपयोग कर सकते हैं।

@ आरएससी

एक त्वरित नज़र में, ऐसा लगता है कि प्रोटोबिल्ड इस धारणा पर आधारित है कि यह फ़ाइलों (pb.go) को अन्य पैकेजों में छोड़ सकता है जो आपके पास नहीं हैं।

यह बिल्कुल नहीं है, परियोजना क्या करती है। यह GOPATH और विक्रेता डीआईआर से एक आयात पथ बनाता है। तब आपके प्रोजेक्ट में कोई भी प्रोटोबफ फाइल उस आयात पथ के साथ उत्पन्न हो जाएगी। यह विशिष्ट गो पैकेजों में मानचित्र आयात जैसी चीजें भी करता है।

इसका लाभ यह है कि यह एक लीफ प्रोजेक्ट में प्रोटोबफ उत्पन्न करने की अनुमति देता है जो निर्भरता में परिभाषित अन्य प्रोटोबफ पर निर्भर होते हैं, बिना सब कुछ पुन: उत्पन्न किए। GOPATH प्रभावी रूप से प्रोटोबफ फाइलों के लिए आयात पथ बन जाता है।

इस प्रस्ताव के साथ बड़ी समस्या यह है कि हम फाइल सिस्टम पर गो पैकेज के सापेक्ष परियोजनाओं में फाइलों को हल करने की क्षमता पूरी तरह से खो देते हैं। अधिकांश पैकेजिंग सिस्टम में ऐसा करने की क्षमता होती है, हालांकि वे इसे कठिन बनाते हैं। GOPATH इस मायने में अद्वितीय है कि इसे करना बहुत आसान है।

@stevvooe मुझे खेद है, लेकिन मुझे लगता है कि मैं अभी भी उलझन में हूं कि प्रोटोबिल्ड क्या करता है। क्या आप एक नया मुद्दा "x/vgo: प्रोटोबिल्ड के साथ संगत नहीं" दर्ज कर सकते हैं और एक फ़ाइल ट्री का एक सरल कार्य उदाहरण दे सकते हैं जो आज मौजूद है, जो प्रोटोबिल्ड ट्री में जोड़ता है, और वह vgo के साथ काम क्यों नहीं करता है? धन्यवाद।

क्या होगा यदि मॉड्यूल का नाम बदलना है (खोया डोमेन, स्वामित्व का परिवर्तन, ट्रेडमार्क विवाद, आदि)?

@jimmyfrasche

उपयोगकर्ता के रूप में:
फिर एक अस्थायी सुधार के रूप में आप उसी आयात पथ को रखते हुए पुराने मॉड्यूल को एक नए के साथ बदलने के लिए go.mod फ़ाइल को संपादित कर सकते हैं। https://research.swtch.com/vgo-tour

लेकिन लंबी अवधि में, आप सभी आयात पथ बदलना चाहेंगे और नए मॉड्यूल का उपयोग करने के लिए go.mod फ़ाइल को संपादित करना चाहेंगे। मूल रूप से वही काम जो आपको vgo के साथ या उसके बिना करना होगा।

पैकेज अनुरक्षक के रूप में:
मॉड्यूल आयात पथ को बदलने के लिए बस go.mod फ़ाइल को अपडेट करें और अपने उपयोगकर्ताओं को परिवर्तन के बारे में बताएं।

@jimmyfrasche ,

क्या होगा यदि मॉड्यूल का नाम बदलना है (खोया डोमेन, स्वामित्व का परिवर्तन, ट्रेडमार्क विवाद, आदि)?

ये वास्तविक, पूर्व-मौजूदा समस्याएं हैं जिन्हें वीजीओ प्रस्ताव सीधे संबोधित करने का प्रयास नहीं करता है, लेकिन स्पष्ट रूप से हमें उन्हें अंततः संबोधित करना चाहिए। कोड गायब होने का उत्तर कैशिंग प्रॉक्सी (दर्पण) के साथ-साथ उन पर भरोसा करने का कारण है; वह भविष्य का काम है। कोड मूविंग का उत्तर मॉड्यूल या पैकेज रीडायरेक्ट की एक स्पष्ट अवधारणा को जोड़ना है, बहुत कुछ प्रकार के उपनाम टाइप रीडायरेक्ट हैं; वह भी भविष्य का काम है।

कोड गायब होने का उत्तर कैशिंग प्रॉक्सी (दर्पण) है

IMO जो वास्तव में उद्यमों के लिए है। अधिकांश छोटी कंपनियां और अन्य सभी निर्भरताओं को एक ही रेपो में बेचने और प्रतिबद्ध करने के साथ पूरी तरह से ठीक होंगे

ऊपर टिप्पणी में मैंने जिस संगतता का उल्लेख किया है, उसके लिए #24916 दायर किया।
एचटीटीपीएस एक्सेस पर जोर देने के बजाय सीधे गिट आदि का उपयोग करने के लिए वापस जाने का प्रस्ताव # 24915 भी दायर किया। ऐसा स्पष्ट लगता है कि कोड होस्टिंग सेटअप अभी केवल API के लिए तैयार नहीं हैं।

नियोजित vgo get कमांड के साथ मॉड फाइलों में स्थिरता बनाने का मामूली प्रस्ताव

"vgo-tour" दस्तावेज़ में, vgo get कमांड को इस प्रकार दिखाया गया है:

vgo get rsc.io/[email protected]

इस प्रारूप को मॉड फ़ाइल में मिरर करने के बारे में कैसे? उदाहरण के लिए:

module "github.com/you/hello"
require (
    "golang.org/x/text" v0.0.0-20180208041248-4e4a3210bb54
    "rsc.io/quote" v1.5.2
)

सरल हो सकता है:

module "github.com/you/hello"
require (
    "golang.org/x/[email protected]"
    "rsc.io/[email protected]"
)

• कमांड लाइन के साथ निरंतरता में सुधार करता है
• एकल पहचानकर्ता आइटम को पूरी तरह से परिभाषित करता है
• मॉड फ़ाइल में परिभाषित सहायक संचालन के लिए बेहतर संरचना जिसके लिए कई संस्करण वाले पैकेज पहचानकर्ताओं की आवश्यकता होती है

यह प्रस्ताव "केवल बाइनरी" पैकेज वितरण से कैसे संबंधित है, इस पर अधिक स्पष्टता की मांग करना।

बाइनरी लाइब्रेरी वर्जनिंग / डिस्ट्रीब्यूशन vgo के आसपास के किसी भी विवरण दस्तावेज़ में दिखाई नहीं देता है। क्या इसे और अधिक ध्यान से देखने की आवश्यकता है?

जिस तरह से यह आज काम करता है, अगर मैं सादे git टूल का उपयोग कर सकता हूं, तो go get ठीक काम करेगा। इससे कोई फर्क नहीं पड़ता कि यह एक निजी Github रिपॉजिटरी है या मेरा अपना Git सर्वर है। मुझे वास्तव में इसे प्यार है।

मैं जो समझता हूं, उसके अनुसार इस तरह से काम करते रहना असंभव होगा। क्या यह सच है? यदि हां, तो क्या कोड को चेकआउट करने के लिए स्थानीय रूप से स्थापित git बाइनरी का उपयोग करने का विकल्प रखना संभव है? (घटना यह एक स्पष्ट सीएलआई ध्वज का उपयोग कर रहा है)

@korya कृपया हाल ही में दायर किया गया मुद्दा देखें https://github.com/golang/go/issues/24915

@sdwarwick , फिर से https://github.com/golang/go/issues/24301#issuecomment -382791513 (go.mod सिंटैक्स), #24119 देखें।

पुन: https://github.com/golang/go/issues/24301#issuecomment -382793364, यह संभव है कि मैं समझ नहीं पा रहा हूं कि आपका क्या मतलब है, लेकिन गो गेट ने कभी भी बाइनरी-ओनली पैकेज का समर्थन नहीं किया है, और हम योजना नहीं बना रहे हैं समर्थन जोड़ने के लिए। सभी संभावित विभिन्न बायनेरिज़ की गणना करना बहुत कठिन है, जिनकी किसी को आवश्यकता हो सकती है। स्रोत की आवश्यकता के लिए बेहतर है और निर्भरता या कंपाइलर बदलने पर पुन: संकलित करने में सक्षम हो।

@rsc मेरा मानना ​​​​है कि https://github.com/golang/go/issues/24301#issuecomment -382793364 का जिक्र है
https://golang.org/pkg/go/build/#hdr -Binary_Only_Packages

@AlexRouSg हाँ। वे "गो गेट" द्वारा समर्थित नहीं हैं (लेकिन "गो बिल्ड" उन्हें बिल्ड प्रकार के रूप में समर्थन करता है), जो कि @rsc का जिक्र है। उन प्रकार के पैकेजों का वितरण "गो गेट" टूलिंग के लिए बाहरी रूप से किया जाना है, और इस प्रकार इस नए प्रस्ताव के लिए भी ऐसा ही होने की संभावना है।

मुझे उम्मीद है कि बाइनरी-ओनली पैकेज के लिए मौजूदा समर्थन उतना ही खराब काम करता रहेगा जितना उसने कभी काम किया है। मैं इसे हटाने के लिए अपने रास्ते से हट नहीं जाऊंगा।

मैंने चर्चा सारांश को फिर से अपडेट किया। मैंने पुराने cmd/go में न्यूनतम मॉड्यूल-जागरूकता के बारे में अपने सुझाव के लिए पहले भी #25069 दायर किया था।

@kybin , फिर से https://github.com/golang/go/issues/24301#issuecomment -377662150 और vgo-v1-lock टैग, मुझे अपील दिखाई दे रही है लेकिन इसके लिए एक विशेष मामला जोड़ने का मतलब है कि अधिक विशेष मामले जोड़ना शेष मॉड्यूल समर्थन। मुझे नहीं लगता कि इस मामले में लाभ लागत के समानुपाती है। समान प्रभाव प्राप्त करने के लिए लोग पहले से ही छद्म-संस्करणों का उपयोग कर सकते हैं। मुझे यह भी चिंता है कि टैग आगे बढ़ेगा और/या लोग पश्चगामी संगतता का ठीक से सम्मान नहीं करेंगे (उदाहरण के लिए केवल अर्थपूर्ण आयात संस्करण से बचने के लिए v2.3.4 से v3.0.0 तक vgo1-v1-lock को स्थानांतरित करना)। तो संतुलन पर मुझे लगता है कि हमें शायद ऐसा नहीं करना चाहिए।

मुझे लगता है कि इस प्रस्ताव को स्वीकृत करने का समय आ गया है।

इसे किसी रूप में स्वीकार किया जाएगा या नहीं इसे लेकर कभी कोई सस्पेंस नहीं रहा। इसके बजाय यहां चर्चा का लक्ष्य सटीक रूप तैयार करना था, यह पहचानने के लिए कि हमें क्या समायोजित करना चाहिए। जैसा कि मैंने ब्लॉग पोस्ट में लिखा है:

मुझे पता है कि इसमें समस्याएं हैं जो गो टीम और मैं नहीं देख सकते, क्योंकि गो डेवलपर्स गो का उपयोग कई चतुर तरीकों से करते हैं जिनके बारे में हम नहीं जानते हैं। प्रस्ताव प्रतिक्रिया प्रक्रिया का लक्ष्य हम सभी के लिए वर्तमान प्रस्ताव में समस्याओं की पहचान करने और उनका समाधान करने के लिए मिलकर काम करना है, यह सुनिश्चित करने के लिए कि भविष्य में गो रिलीज में जहाजों का अंतिम कार्यान्वयन यथासंभव अधिक से अधिक डेवलपर्स के लिए अच्छा काम करता है। कृपया प्रस्ताव चर्चा के मुद्दे पर समस्याओं को इंगित करें। फीडबैक आने पर मैं चर्चा सारांश और अक्सर पूछे जाने वाले प्रश्नों को अपडेट करता रहूंगा।

चर्चा सारांश और अक्सर पूछे जाने वाले प्रश्न अभी अप-टू-डेट हैं। यहां चर्चा और ऑफ-इश्यू ने निम्नलिखित महत्वपूर्ण परिवर्तनों को प्रेरित किया:

• पुराने cmd/go में न्यूनतम मॉड्यूल-जागरूकता, #25069.
• न्यूनतम विक्रेता समर्थन बहाल करना, #25073.
• डायरेक्ट गिट एक्सेस के लिए समर्थन बहाल करना, #24915।
• go.mod, #24641 में उद्धरण चिह्न छोड़ें।
• gopkg.in, #24099, अन्य के लिए बेहतर समर्थन।
• शाखा पहचानकर्ताओं द्वारा नामकरण के लिए समर्थन, #24045।

इसने संभवतः go.mod फ़ाइल नाम और सिंटैक्स को बदलने के बारे में चर्चाओं को प्रेरित किया, लेकिन केवल परिणामी परिवर्तन उद्धरणों को छोड़ रहा था।

चर्चा समाप्त हो गई है, और गिटहब पर लोड करने के लिए काफी दर्दनाक होने के लिए यह काफी लंबा हो गया है (जाहिर है 100 टिप्पणियां बहुत अधिक हैं!) स्वीकृत प्रस्ताव को चिह्नित करके, हम vgo का उपयोग करने और इसे "पूर्वावलोकन" के रूप में Go 1.11 में शामिल करने के लिए तैयार करने पर ध्यान केंद्रित कर सकते हैं, और हम उन मुद्दों पर आगे बढ़ सकते हैं जिन्हें GitHub अधिक तेज़ी से लोड कर सकता है।

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

सभी को धन्यवाद।

@rsc अब vgo आज़माने का तरीका क्या है? क्या हमें github.com/golang/vgo या github.com/golang/go लाना और बनाना चाहिए?

@ngrily go get -u golang.org/x/vgo का उपयोग करते रहें।

@rsc इस प्रस्ताव में आपके द्वारा लगाई गई कड़ी मेहनत और समय के लिए धन्यवाद। मुझे वास्तव में उम्मीद है कि हम अंततः उस बिंदु पर पहुंच जाएंगे जहां गो निर्भरता प्रबंधन के आसपास एक अच्छी कहानी है।

मुझे लगता है कि इस प्रस्ताव को स्वीकृत करने का समय आ गया है।

मुझे नहीं लगता कि किसी प्रस्ताव को प्रस्तुत करने वाले व्यक्ति के लिए यह घोषणा करना उचित है कि वह कब स्वीकार किए जाने के लिए तैयार है। मुझे लगता है कि प्रस्ताव प्रस्तुत करने वालों, विशेष रूप से इतना बड़ा और विचार रखने वालों को, इसे स्वीकार किए जाने पर अपनी बात नहीं रखनी चाहिए। उनका प्रस्ताव प्रस्तुत करना उनके पूर्वाग्रहों का संचार करता है। दूसरी ओर, मुझे लगता है कि लेखकों को निश्चित रूप से प्रस्ताव को अस्वीकार करने में अपनी बात रखनी चाहिए, यदि वे इसे उठाने के बाद हृदय परिवर्तन करते हैं।

इस समय ऐसा लगता है कि vgo के भीतर तकनीकी निर्णयों के बारे में गहरी असहमति है, जो मुझे डर है कि पारिस्थितिकी तंत्र _और_ समुदाय को खंडित कर देगा। इसे ध्यान में रखते हुए, मुझे लगता है कि हमें प्रतिस्पर्धी प्रस्तावों को समाप्त करने और उन पर ध्यान केंद्रित करने के लिए थोड़ा और समय देना चाहिए। एक बार ऐसा हो जाने पर, हमें एक _तटस्थ_ पार्टी की आवश्यकता होती है जिसमें चर्चा और अंतिम निर्णय को सुविधाजनक बनाने के लिए कई कंपनियों और समुदाय के प्रतिनिधित्व शामिल हों।

मुझे इस बात की बढ़ती चिंता है कि गो नेतृत्व का एक अच्छा हिस्सा गो (इसका उपयोग करने वाली अन्य कंपनियों सहित) के समुदाय से बहुत अलग-थलग हो गया है, और परिणामस्वरूप भाषा और पारिस्थितिकी तंत्र को चोट लगने लगी है। यही कारण है कि मुझे लगता है कि हमें एक तटस्थ समूह की आवश्यकता है, जो प्रतिनिधित्व के साथ गो प्रोग्रामिंग भाषा के उपयोगकर्ताओं को दर्शाता है, इस तरह के प्रस्तावों की पुष्टि करने में मदद करता है।

अंततः, उद्योग के एक बड़े हिस्से की तुलना में Google के भीतर एक सॉफ़्टवेयर इंजीनियर के रूप में काम करने का परिणाम एक अलग परिप्रेक्ष्य में होता है। Google के भीतर होने वाले प्रमुख डेवलपर्स का महत्वपूर्ण द्रव्यमान होने से हमें आगे बढ़ने के लिए आवश्यक विविधता में योगदान नहीं होता है।

@theckman आपकी सोच की रेखा प्रतीत होती है:

1. गो के बारे में निर्णय मुख्य रूप से Google इंजीनियरों से बनी एक छोटी टीम द्वारा किए जाते हैं।
2. Google इंजीनियर बाकी समुदाय से अलग-थलग हैं, क्योंकि Google की ज़रूरतें बहुत विशिष्ट हैं।
3. यह उन निर्णयों की ओर ले जाता है जो Google के दृष्टिकोण का पक्ष लेते हैं और अन्य गो उपयोगकर्ताओं के अनुकूल नहीं होते हैं।
4. यह गो समुदाय को आहत और खंडित कर सकता है।
5. इस मुद्दे को हल करने के लिए, गो को एक औपचारिक निर्णय प्रक्रिया अपनानी चाहिए जहां गो समुदाय की विविधता (कुछ "लोकतांत्रिक") को दर्शाते हुए एक समूह द्वारा सामूहिक रूप से निर्णय लिए जाते हैं।

सिद्धांत रूप में, मैं "लोकतांत्रिक" कुछ भी पसंद करूंगा, लेकिन व्यवहार में:

• मुझे नहीं लगता कि गो टीम द्वारा लिए गए निर्णय "छोटे" गो उपयोगकर्ताओं की कीमत पर Google की जरूरतों के प्रति पक्षपाती हैं। एक बहुत छोटी दुकान (Google के बिल्कुल विपरीत) में एक डेवलपर के रूप में, मुझे लगता है कि गो हमारी आवश्यकताओं के लिए बहुत अच्छी तरह अनुकूलित है, और मैं अपने आस-पास की अन्य छोटी टीमों को खुशी से गो का उपयोग करके जानता हूं। व्यक्तिगत रूप से, गो भाषा के साथ मेरी एकमात्र पकड़ गो टीम (निर्भरता प्रबंधन, जेनेरिक की कमी, वर्बोज़ त्रुटि प्रबंधन) द्वारा स्वीकार की गई है और मुझे विश्वास है कि वे इस पर काम कर रहे हैं। क्या आप गो टीम द्वारा लिए गए निर्णयों के उदाहरण प्रदान कर सकते हैं जो अलग होते और "बाकी समुदाय" की बेहतर सेवा करते यदि हमारे पास "लोकतांत्रिक" प्रक्रिया होती?

• मुझे विश्वास नहीं है कि "लोकतांत्रिक" निर्णय प्रक्रिया को अपनाने से आपके द्वारा उल्लिखित मुद्दों का स्वतः समाधान हो जाएगा और समुदाय को "विखंडित" करने का जोखिम समाप्त हो जाएगा। यह बीडीएफएल मॉडल पर एक सुधार हो सकता है, लेकिन यह प्रति स्थिरता की गारंटी नहीं है। ओपन सोर्स इतिहास, और सामान्य रूप से मानव इतिहास, लोकतांत्रिक समाजों के बहुत सारे उदाहरण प्रदान करता है जो असहमति और संघर्षों से बर्बाद हो गए हैं।

@theckman , जबकि @ngrily विनम्र होने की कोशिश कर रहा था, मैं ठोस हो जाऊंगा: यदि आपको कोई तकनीकी समस्या दिखाई देती है तो vgo प्रस्ताव स्वीकार करने के लिए तैयार क्यों नहीं है - हमें जल्द से जल्द और यहीं बताएं! अगर आपको लगता है कि कुछ ज्ञात समस्याओं का पर्याप्त समाधान नहीं किया गया था - हमें बताएं। यदि ऐसे कोई मामले नहीं हैं - तो क्या अंतर है जो कहेंगे "यह प्रस्ताव स्वीकार करने का समय है"? इस पर चर्चा करने के लिए हमारे पास दो महीने का समय था, अगर आपको लगता है कि कोई तकनीकी कारण है तो यह पर्याप्त नहीं है - हमें बताएं।

ऐसा लगता है कि आप बिना किसी कारण के और अधिक राजनीति जोड़ना चाहते हैं, जो सब कुछ धीमा कर देगा, और अगर हम पर्याप्त भाग्यशाली होंगे और इससे कोई अन्य नुकसान नहीं होगा। और अगर आपको लगता है कि इसका कोई कारण है - इस पर चर्चा करने के लिए यह सही जगह नहीं है - कृपया इस चर्चा को इसके बजाय maillist में शुरू करें।

एक और ऑफटॉपिक टिप्पणी के लिए क्षमा करें, सब लोग!

@powerman लंगड़े होने के लिए क्षमा करें और मेरी पिछली टिप्पणी को उद्धृत करें:

इस समय ऐसा लगता है कि vgo के भीतर तकनीकी निर्णयों को लेकर गहरी असहमति है, जिनसे मुझे डर है कि यह पारिस्थितिकी तंत्र और समुदाय को खंडित कर देगा। इसे ध्यान में रखते हुए, मुझे लगता है कि हमें प्रतिस्पर्धी प्रस्तावों को समाप्त करने और उन पर ध्यान केंद्रित करने के लिए थोड़ा और समय देना चाहिए।

मुझे पता है कि वैकल्पिक प्रस्ताव आ रहे हैं, और मेरा कहना था कि किबोश को इसे तब तक स्वीकार करना चाहिए जब तक कि उनके पास दिन का समय न हो। हमारे पास अभी कुछ समय के लिए निर्भरता प्रबंधन नहीं है, इसलिए मुझे लगता है कि अन्य प्रस्तावों पर अंतिम रूप देने की अनुमति देते हुए थोड़े समय के लिए पूछना अनुचित नहीं है।

मुझे यकीन नहीं है कि इस मुद्दे में इसे अच्छी तरह से स्पष्ट करना आसान है, सिर्फ इसलिए कि प्रारूप थोड़ा बाधित है। तब भी मुझे संकोच होगा, क्योंकि मैं मूल रूप से WIP प्रस्तावों के कुछ हिस्सों की नकल कर रहा हूँ। मैं विचारों को खंडित नहीं करना चाहता या लेखकों से गड़गड़ाहट चोरी नहीं करना चाहता।

हालाँकि, यह जानते हुए कि वे प्रस्ताव प्रगति पर हैं और उन पर कौन काम कर रहा है, ऐसा लगा कि इसके तैयार होने की घोषणा उन प्रतिस्पर्धी राय को दबाने का एक सक्रिय प्रयास था। मैंने इन चिंताओं को उठाने के लिए मजबूर महसूस किया क्योंकि मैंने अपने वर्षों में गोफर के रूप में देखे गए पैटर्न को देखा है। मैं वास्तव में भाषा, पारिस्थितिकी तंत्र और समुदाय को सफल बनाना चाहता हूं, और इन्हें पूरी तरह से उस लक्ष्य को ध्यान में रखकर उठाया जा रहा है।

संपादित करें: स्पष्ट करने के लिए, संक्षिप्त प्रवास से मेरा मतलब दो महीने या ऐसा कुछ भी नहीं है। मेरा मतलब है कुछ हफ़्ते।

@ngrilly क्षमा करें, मेरा मतलब आपकी टिप्पणी को अनदेखा करना नहीं था। मैंने इसे पहले वाले को संबोधित करने की योजना बनाई, लेकिन मैं जितना चाहता था उससे अधिक क्रियात्मक हो गया।

मुझे लगता है कि दो मुद्दे हैं। जबकि मुझे लगता है कि इन निर्णयों को कैसे किया जाता है, इस बारे में एक अलग मंच पर चर्चा की जानी है, यही कारण है कि मैंने इसके आसपास कुछ संदर्भ जोड़ा है, मैं वास्तव में इस प्रस्ताव की स्वीकृति पर एक अस्थायी विराम लगाने पर ध्यान केंद्रित करना चाहता हूं जब तक कि उन अन्य प्रस्तावों सार्वजनिक होने का मौका मिला।

मुझे पता है कि वैकल्पिक प्रस्ताव आ रहे हैं, और मेरा कहना था कि किबोश को इसे तब तक स्वीकार करना चाहिए जब तक कि उनके पास दिन का समय न हो। ... [के] अब उन प्रस्तावों पर काम चल रहा है और उन पर कौन काम कर रहा है, ऐसा लगा कि इसके तैयार होने की घोषणा उन प्रतिस्पर्धी राय को दबाने का एक सक्रिय प्रयास था।

मैं आपको विश्वास दिलाता हूं कि ऐसा नहीं था। मैं यहाँ समयरेखा के बारे में बहुत स्पष्ट हूँ। फरवरी के मध्य से मेरी पहली पोस्ट कहती है कि लक्ष्य vgo प्रस्ताव को गो 1.11 में एकीकृत करना है; विकास फ्रीज दृष्टिकोण। मुझे किसी अन्य प्रगति पर प्रस्ताव या उन पर कौन काम कर रहा है, के बारे में कुछ नहीं पता। यह मेरे लिए खबर है। अगर लोग इस प्रस्ताव के साथ जुड़ना चाहते हैं या प्रति-प्रस्ताव करना चाहते हैं, तो यह प्रस्ताव डेढ़ महीने से खुला है, इसलिए इसमें थोड़ी देर हो रही है।

स्पष्ट होने के लिए, गोलंग वीकली और शायद अन्य ने जो रिपोर्ट की थी, उसके बावजूद मैंने स्वीकार किए गए प्रस्ताव को चिह्नित नहीं किया। मैंने केवल इतना कहा कि मुझे लगता है कि ऐसा करने का समय आ गया है। यानी, मैंने प्रस्ताव-स्वीकृत लेबल लागू नहीं किया, ठीक इसलिए कि मैं यह जांचना चाहता था कि पहले ऐसा करने के लिए आम सहमति थी। और आम सहमति स्वीकृति के पक्ष में प्रतीत होती है, कम से कम यहां समग्र चर्चा के साथ-साथ https://github.com/golang/go/issues/24301#issuecomment -384349642 पर इमोजी काउंटरों को देखते हुए।

मुझे पता है कि वैकल्पिक प्रस्ताव आ रहे हैं

@theckman , अगर आप इस तरह कुछ के बारे में जानते हैं, तो शायद आप अकेले ही इसे जानते हैं। आज तक, मैंने अब तक किसी को भी इस मुद्दे को उठाते हुए नहीं देखा है। मुझे लगता है कि गो 1.11 के लिए इसे आजमाने की इच्छा के बारे में रस के बयान शुरू से ही बहुत स्पष्ट थे, इसलिए यदि कोई वैकल्पिक प्रस्तावों पर काम कर रहा है, तो उनके पास उन्हें आगे बढ़ाने के लिए लगभग 2 महीने का समय था, यहां तक ​​​​कि एक हेड-अप के रूप में भी।

मुझे यह भी लगता है कि हम इस तथ्य को स्वीकार कर सकते हैं कि गो टीम के पास निर्णय नहीं लेने का एक अच्छा ट्रैक रिकॉर्ड है, और अगर हम देखें कि कैसे उन्होंने अंतिम क्षण में गो 1.8 से उपनाम खींच लिया क्योंकि यह सही नहीं था उस समय क्या करना है, तो हमें शायद उन्हें कम से कम उन्हें अपना प्रयोग/समाधान बनाने की अनुमति देने का शिष्टाचार देना चाहिए।

दिन के अंत में, प्रस्ताव निर्भरता के किस संस्करण का उपयोग करने के तरीके का चयन करने के तरीके पर केवल एक एल्गोरिदम से कहीं अधिक लाता है। अगर कोई इसे सुधारने का कोई तरीका ढूंढता है, तो दो विकल्प हैं: इसे नियमित सीएल प्रक्रिया के माध्यम से सबमिट करें या अपना स्वयं का टूल बनाएं और समुदाय को इसका उपयोग करने दें, अगर वे ऐसा करना चुनते हैं। गो टीम अभी भी उपकरण इम्हो का अपना संस्करण प्रदान कर सकती है, इसलिए मुझे नहीं लगता कि इसमें कोई बंद समस्या है।

हालांकि, कृपया ध्यान रखें कि अधिकांश विभाजनकारी कार्रवाई जहां अब तक समुदाय द्वारा की गई है, गो टीम नहीं। आइए गो टीम को एक टूल बनाने का मौका दें, और फिर इसका मूल्यांकन करें, जब ऐसा करने के लिए व्यवहार्य हो, तो तालिका में तर्क दें कि इसे कैसे सुधारें और यह कितना खराब है, इसके बारे में लिखने के बजाय आगे बढ़ें।

कृपया इसे एक अलग तरह की अनुभव रिपोर्ट के हिस्से के रूप में मानें: वह जहां मैं उर्फ ​​​​प्रस्ताव का _very_ मुखर विरोधी था, तब प्रस्ताव को समझने और अब कार्रवाई में देखने के लिए।

संपादित करें: मूल संदेश में एक बहुत ही दुर्भाग्यपूर्ण चूक record of *not* making decisions on a whim पाठ होना चाहिए था, दुर्भाग्य से "नहीं" भाग गायब था। इसके लिए मुझे खेद है।

मेरे पास प्रस्ताव के साथ मूलभूत चिंताओं का विस्तृत विवरण है। मैं इस लेखन को समाप्त करने की कोशिश कर रहा हूं ताकि मैं उन सभी को एक साथ पेश कर सकूं - यह एक जटिल, सूक्ष्म डोमेन है और इस तरह, इन मुद्दों को समग्रता से निपटाया जाना चाहिए - लेकिन जीवन और काम ने इसे मुश्किल बना दिया है।

जबकि मैंने स्लैक में इस राइटअप का उल्लेख किया है, साथ ही इसके कुछ हिस्सों पर सीधे @rsc के साथ चर्चा की है, मैंने अब तक इनका उल्लेख नहीं करने का विकल्प चुना है। मुझे ऐसा लग रहा था कि पूरी तरह से रिलीज होने के लिए तैयार होने से पहले इस राइटअप का विज्ञापन करना बहुत रचनात्मक नहीं होगा। लेकिन, जैसा कि बताया गया है, दो महीने हो गए हैं, इसलिए मैं अगले सप्ताह श्रृंखला की शुरुआत करने के लिए एक बड़ा प्रयास करने जा रहा हूं।

(संपादित करें: यह "विकल्प" है जिसका @theckman जिक्र कर रहा था)

@sdboyer आपने उल्लेख किया है कि आपको कई चिंताएँ हैं। क्या आप कृपया कम से कम उनकी सूची अभी प्रकाशित कर सकते हैं?
मैं कई प्रणालियों के साथ काम कर रहा हूं जो निर्भरता नरक को दूसरे स्तर पर ले जाती हैं (शेफ, गो, एनपीएम, कंपोजर) और अनुभव से यह प्रस्ताव उन सभी के लिए समाधान है।

@theckman , क्या आप पुष्टि कर सकते हैं कि आप केवल @sdboyer की प्रतिक्रिया का जिक्र कर रहे थे? यह कोई रहस्य नहीं है। सैम ने इसका शाब्दिक रूप से पहले दिन वीगो जारी किया था ("मैं अपनी चिंताओं के बारे में अधिक विस्तृत दस्तावेज लिख रहा हूं" - https://sdboyer.io/blog/vgo-and-dep/)। लेकिन यह प्रतिक्रिया है, प्रस्ताव नहीं है, और आपने कई बार "अन्य प्रस्तावों", बहुवचन का उल्लेख किया है। क्या आप और भी कुछ जानते हैं?

go/type API उपयोगकर्ताओं के लिए vgo के निहितार्थ क्या हैं? go/types समर्थन की वर्तमान स्थिति क्या है?

मुझे एक vgo-aware go/types.Importer कार्यान्वयन जोड़ने के लिए एक PR mdempsky/gocode#26 प्राप्त हुआ, लेकिन यह मेरे लिए स्पष्ट नहीं है कि क्या/क्यों यह आवश्यक है।

यह मानते हुए कि यह आवश्यक है, क्या हम एक विहित vgo-aware go/types.Importer कहीं और जोड़ सकते हैं (जैसे, x/vgo या x/tools रेपो) ताकि go/type-आधारित टूल को प्रत्येक को इस समर्थन को फिर से लागू करने की आवश्यकता न हो ?

मैंने वास्तव में वीजीओ विवरण का पालन नहीं किया है, इसलिए शायद यह "कोई प्रभाव नहीं" है, लेकिन मुझे ऊपर जाने/प्रकारों का कोई उल्लेख नहीं दिख रहा है। "vgo go/types golang" के लिए Google की खोज भी इसी तरह गैर-सूचनात्मक हैं।

धन्यवाद।

@mdempsky , योजना एक vgo- जागरूक (और उस मामले के लिए कैश-जागरूक बनाने के लिए) पैकेज लोडर है, शायद golang.org/x/tools/go/packages, लेकिन यह अभी तक अस्तित्व में नहीं है। लोगों को कोड लिखने के बजाय उस पैकेज की प्रतीक्षा करनी चाहिए जिसे फेंकने की आवश्यकता होगी। पीआर को मर्ज न करें। मैंने उस पर टिप्पणी की।

@mdempsky https://github.com/mdempsky/gocode/pull/26 में जवाब देने जा रहा था, लेकिन मैं अभी के लिए यहां जवाब दूंगा।

https://github.com/mdempsky/gocode/pull/26 पूरी तरह से फेंका हुआ है; केवल एक सबूत की अवधारणा जो vgo के विरुद्ध अब छोड़े गए सीएल का उपयोग करती है।

मैंने अभी-अभी @rsc उत्तर देखा है, इसलिए मैं केवल यह बताऊंगा कि https://github.com/golang/go/issues/14120#issuecomment -383994980 में भी चर्चा चल रही है।

सारांश: संस्करणों के साथ कुछ वर्षों के अनुभव के बाद, अंतिम सर्वोत्तम प्रयास एक बहुत ही जटिल एल्गोरिथम, एक सैट सॉल्वर था। लेकिन अगर आप इनपुट डेटा में कुछ सरल संशोधन करते हैं, तो एनपी-पूर्ण निर्णय समस्या न केवल प्रबंधनीय हो जाती है, बल्कि बहुत तेज़ हो जाती है।

एनपीएम का उपयोग करने के बहुत सारे अनुभव के साथ गो के एक छोटे-टीम उपयोगकर्ता के रूप में, मुझे वीजीओ प्रस्ताव बहुत पसंद है। एफडब्ल्यूआईडब्ल्यू, मैं go में उचित रूप से लागू होने वाले वीगो की प्रतीक्षा कर रहा हूं और यह जितनी जल्दी हो सके मेरी टीम और मेरे लिए बेहतर होगा।

ऐसा नहीं है कि मैं कोई खास हूं, बस जब से मैंने छोटी टीम की समस्याओं के बारे में चर्चा देखी, मैंने सोचा कि मैं इसमें शामिल हो जाऊंगा।

यहाँ मेरी समीक्षा है।

सतह पर, प्रस्ताव दस्तावेज़ के अंतिम संशोधन का _प्रस्ताव_ खंड ठीक लगता है, यदि बहुत विशिष्ट नहीं है (उदाहरण के लिए यह स्पष्ट नहीं है कि किस हद तक तोड़फोड़ का समर्थन किया जा सकता है)। एक अपवाद यह है कि "एक सीमित उपयोग को छोड़कर, विक्रेता निर्देशिकाओं के उपयोग को अस्वीकार करें" ऐसा लगता है कि विक्रेता निर्देशिका गैर-मॉड्यूल पैकेजों में बिल्कुल भी समर्थित नहीं होगी; क्या ऐसा है?

दूसरी ओर, प्रस्ताव में कुछ डिज़ाइन और कार्यान्वयन निर्णय शामिल हैं जो वर्तमान go get के विभिन्न लाभों को कमजोर करते हैं। नुकसान स्वीकार्य हो सकते हैं, कुछ को टाला जा सकता है, लेकिन अगर vgo get को go get को बदलना है, तो उन्हें डिजाइन विचारों के रूप में संबोधित किया जाना चाहिए और चर्चा की जानी चाहिए, क्योंकि अन्यथा हम एक उपकरण के साथ समाप्त हो सकते हैं जो है पर्याप्त प्रतिस्थापन नहीं है, और या तो vgo को go में विलय नहीं किया जाएगा या go get को तीसरे पक्ष के उपकरण के रूप में पुनर्जीवित करना होगा।

_कार्यान्वयन_ अनुभाग कहता है: "बाद की रिलीज़ में (जैसे, गो 1.13), हम गैर-मॉड्यूल के गो गेट के लिए समर्थन समाप्त कर देंगे। गोपथ में काम करने के लिए समर्थन अनिश्चित काल तक जारी रहेगा।” यह परेशानी भरा है. सबसे पहले, बहुत सारी अच्छी परियोजनाएं हैं जिन्हें वर्षों में अद्यतन नहीं किया गया है। वे अभी भी गो 1 संगतता वादे के लिए धन्यवाद काम करते हैं, लेकिन कई go.mod फ़ाइलें नहीं जोड़ेंगे। दूसरा, यह बिना निर्भरता वाली परियोजनाओं के डेवलपर्स को या जो संस्करणों की परवाह नहीं करते हैं उन्हें मॉड्यूल फ़ाइलों को जोड़ने या नए go get पारिस्थितिकी तंत्र से दूर रहने के लिए मजबूर करता है। हो सकता है कि आपको ऐसा करना उचित लगे, लेकिन कृपया इसका कारण बताएं। (मेरे लिए यह अनावश्यक रूप से बोझिल लगता है; मैं पुराने go get के कांटे का उपयोग करना चाहूंगा। मैं मानता हूं कि अन्य भाषाओं के लिए पैकेज मैनेजर और भी बोझिल हैं, और मुझे यकीन है कि vgo उनसे बेहतर है, लेकिन यह मेरे उपयोग के मामलों को वर्तमान go get से बेहतर तरीके से हैंडल नहीं करता है, कभी-कभी govendor की मदद से)।

वीजीओ बनाम गो के बारे में मेरी मुख्य चिंता उनके द्वारा समर्थित वर्कफ़्लो के साथ है। मैंने इसे vgo-intro पोस्ट पर व्यक्त किया था। यह मोटे तौर पर प्रस्ताव के खंड _संगतता_ के अंतर्गत हो सकता है, या यह इसके दायरे से बाहर हो सकता है, लेकिन यह यहां उठाए गए अन्य प्रश्नों और मुद्दों से मेल खाता है।

कुछ बाद की रिलीज़ में, हम पुराने, अनवर्जन गो गेट के लिए समर्थन हटा देंगे।

जबकि प्रस्ताव के अन्य पहलू ठीक लगते हैं, यह दुर्भाग्यपूर्ण है। (इतना है कि अगर मुझे गो टूलचेन में वर्जनिंग को शामिल करने और वर्जन कंट्रोल टूल्स के साथ काम करने के बीच चयन करना था, तो मैं बाद वाले को चुनूंगा।) वीजीओ का लाभ यह है कि यह प्रतिलिपि प्रस्तुत करने योग्य बिल्ड की सुविधा देता है और आपके प्रोजेक्ट के टूटने में देरी करता है। असंगत अद्यतनों के कारण जब तक आप परियोजना के लेखक के रूप में (go.mod फ़ाइल के साथ) इसका सामना नहीं करना चाहते; लेकिन गो गेट का लाभ यह है कि यह बहु-भंडार दुनिया के लिए एक मोनोरेपो के लाभ लाता है: निर्भरताओं के पूर्ण क्लोन के कारण, आप उनके साथ अपने स्वयं के प्रोजेक्ट के साथ आसानी से काम कर सकते हैं (इतिहास का निरीक्षण करें, संपादित करें, परिवर्तनों को अलग करें; किसी भी चीज की परिभाषा पर जाएं और उसे दोष दें), यह सहयोग की सुविधा देता है (आप बस अपने परिवर्तनों को आगे बढ़ाते हैं और प्रस्तावित करते हैं) और आम तौर पर यह विचार थोपते हैं कि किसी भी समय दुनिया की सिर्फ एक वर्तमान स्थिति है - प्रत्येक परियोजना की नोक - और सब कुछ अन्य इतिहास है। मुझे लगता है कि यह अनूठा दृष्टिकोण (वास्तविक मोनोरपोस के बाहर) गो पारिस्थितिकी तंत्र का एक विशिष्ट वरदान है जिसने बुरे से ज्यादा अच्छा किया है, और इसे छोड़ा नहीं जाना चाहिए।

प्रस्ताव का एक अधिक सूक्ष्म नकारात्मक परिणाम यह है कि यह वर्जनिंग को लाइलाज और इनहेरिट करने योग्य बनाता है: एक बार जब कोई प्रोजेक्ट किसी वर्जन को टैग कर देता है, तो यह नए वर्जन को टैग किए बिना यूजर्स तक पहुंचने के लिए भविष्य के बदलावों की उम्मीद नहीं कर सकता है। यहां तक ​​​​कि अगर मूल लेखक टैगिंग जारी रखने के लिए दृढ़ रहता है, तो कांटे के लेखकों को अब उन्हें भी टैग करने के लिए मजबूर किया जाता है (जो विशेष रूप से अजीब है अगर स्रोत प्रोजेक्ट अभी भी सक्रिय है), या पुराने टैग को हटाने के लिए।

कुल मिलाकर मैं इस बात पर जोर देना चाहता हूं कि निर्भरता प्रबंधन के लिए वर्तमान गो दृष्टिकोण संस्करण से बेहतर है। यह आधुनिक, गतिशील और सहयोगी ओपन सोर्स के साथ बेहतर रूप से संरेखित करता है जो उम्मीद करता है कि सभी कमिट्स दिखाई दे रहे हैं, और केवल रिलीज के स्रोतों को प्रकाशित करना (या विशाल गैर-वर्णनात्मक प्रतिबद्धताओं में "आंतरिक परिवर्तनों को एकीकृत करना") पर्याप्त नहीं है (क्योंकि यह दृश्यता, सहयोग को गंभीर रूप से कम कर देता है और गतिशीलता)। यह मोनोरेपो और वर्तमान गो पारिस्थितिकी तंत्र दोनों में देखा जा सकता है कि अधिकांश परियोजनाओं को संस्करणों की आवश्यकता नहीं होती है। बेशक यह दृष्टिकोण अंतिम नहीं है, इसमें कमियां हैं, और संस्करण वाली परियोजनाओं का भी समर्थन करना महत्वपूर्ण है, लेकिन यह संस्करणहीन की हानि के लिए नहीं किया जाना चाहिए।

संक्षेप में, वर्तमान go get (सहायक उपकरणों के साथ, जैसे godef ) कार्यप्रवाह का समर्थन करता है जिसमें विशेषताएं हैं:

• निर्भरता का संपादन योग्य स्रोत कोड
• उनके वीसीएस के तहत निर्भरताओं का स्रोत कोड
• निर्भरता के नवीनतम संशोधन

मुझे लगता है कि मैं मान सकता हूं कि निर्भरताओं का स्रोत कोड संपादन योग्य रहेगा, यानी godef _files_ से लिंक होगा जो कि _नहीं लिखते हैं संरक्षित_ और _build_ के दौरान उपयोग किए जाते हैं। हालांकि, vgo अन्य दो बिंदुओं से पीछे हटने वाला है। दूसरे बिंदु के संबंध में, #24915 ने वीसीएस उपकरणों के लिए समर्थन बढ़ाया है, लेकिन यह अभी भी इसे छोड़ने के लक्ष्य की घोषणा करता है; और वर्कफ़्लो के लिए न केवल वीसीएस से निर्भरता की जांच की जानी चाहिए, बल्कि यह भी कि चेकआउट डेवलपर्स के लिए उपयोगी है (उदाहरण के लिए उथला गिट चेकआउट नहीं, .git हटाए गए गिट चेकआउट नहीं) और निर्माण के दौरान उपयोग किया जाता है , लेकिन vgo इस आवश्यकता को पूरा नहीं कर सकता है। तीसरे बिंदु के संबंध में, मैंने vgo-intro टिप्पणी में इसके मूल्य को उचित ठहराया है, लेकिन vgo इसे पूरी तरह से छोड़ रहा है।

एक गो संस्करण उपकरण को वर्तमान वर्कफ़्लो के लिए समर्थन छोड़ना नहीं पड़ता है, और इसे गो पारिस्थितिकी तंत्र में काम करने के अनूठे लाभों को बनाए रखने के लिए इसे छोड़ना नहीं चाहिए और go get के लिए पर्याप्त प्रतिस्थापन होना चाहिए। vgo का डिज़ाइन इसे चुनौतीपूर्ण बनाता है, लेकिन स्पष्ट रूप से अक्षम्य नहीं है। दूसरी ओर, प्रस्ताव का _प्रस्ताव_ खंड वर्तमान कार्यप्रवाह के साथ लगभग संगत प्रतीत होता है। तीसरे बिंदु (नवीनतम संशोधन की जाँच) का समर्थन करने के लिए यह एकमात्र चुनौती पेश करता है - और यह एक बड़ा है - यह मॉड्यूल ≥v2.0.0 के लिए तय करना मुश्किल बनाता है कि क्या उन्हें master पर चेक आउट किया जा सकता है master एक अन्य प्रमुख संस्करण पर है। यह gopkg.in के साथ वर्तमान go get के लिए कोई चुनौती नहीं है क्योंकि डिफ़ॉल्ट रूप से सब कुछ master पर चेक किया जाता है, और gopkg.in पर सामान को मिलान टैग या शाखा पर चेक आउट किया जाता है; लेकिन vgo इस अंतर को धुंधला कर देता है और सभी पैकेजों पर gopkg.in मॉडल को फैला देता है। (इसके अलावा, यह शाखाओं का मिलान करना बंद कर देता है।) वास्तव में यह निश्चित रूप से बताना असंभव हो जाता है और यह अनुमान लगाना आवश्यक है कि निर्दिष्ट प्रमुख संस्करण का नवीनतम संशोधन कैसे प्राप्त किया जाए।

हो सकता है कि मैंने इसे याद किया हो, लेकिन इस परिदृश्य में vgo कैसे काम करेगा?

• मैं सेवा ए और सेवा बी दोनों पर काम करता हूं जो कि लिब एक्स पर निर्भर करता है (जिस पर मैं भी काम करता हूं)
• मुझे lib X . में एक बड़े बदलाव की जरूरत है

करने के मौजूदा तरीकों के साथ मैं बस अपने परिवर्तन करता हूं, सेवा ए और सेवा बी संकलित करता हूं, वे lib एक्स के लिए मेरे $ GOPATH में जो कुछ भी लेते हैं, मैं सामान ठीक करता हूं, फिर मैं एक प्रमुख सेवर टक्कर के साथ lib X को धक्का देता हूं, फिर दोनों सेवाओं को धक्का देता हूं A और B उन्हें अपने Gopkg.toml में lib X के नए प्रमुख का उपयोग करने के लिए कह रहे हैं।

अब जब vgo कार्यभार संभालेगा, go build मेरी सेवाओं पर github से lib X के गैर-मौजूदा नए संस्करण को खोजने का प्रयास करेगा, और मैं सभी प्रकार की परेशानियों का पूर्वाभास कर सकता हूं।

तो, क्या मुझे कुछ स्पष्ट याद आ रहा है?

आप इस प्रकार की चीज़ के लिए बदलें निर्देश का उपयोग कर सकते हैं।

सोम, अप्रैल 30, 2018, 12:15 पर एंटोनी नोटिफिकेशन @github.com ने लिखा:

हो सकता है कि मैंने इसे याद किया हो, लेकिन इस परिदृश्य में vgo कैसे काम करेगा?

• मैं सेवा ए और सेवा बी दोनों पर काम करता हूं, जो कि लिब एक्स पर निर्भर करता है (कि I
  पर भी काम करते हैं)
• मुझे lib X . में एक बड़े बदलाव की जरूरत है

करने के मौजूदा तरीकों के साथ मैं बस अपने परिवर्तन करता हूं, सेवा ए संकलित करता हूं और
सेवा बी, वे मेरे $GOPATH में lib X के लिए जो कुछ भी है उसे उठाते हैं, मैं सामान ठीक करता हूं,
फिर मैं एक प्रमुख सेवर टक्कर के साथ lib एक्स को धक्का देता हूं, फिर दोनों सेवाओं ए और बी को धक्का देता हूं
उन्हें अपने Gopkg.toml में lib X के नए प्रमुख का उपयोग करने के लिए कह रहे हैं।

अब जब vgo कार्यभार संभालेगा, तो मेरी सेवाओं पर निर्माण करें गैर खोजने का प्रयास करेंगे
जीथब से लिब एक्स का मौजूदा नया संस्करण, और मैं सभी प्रकार की भविष्यवाणी कर सकता हूं
मुसीबतें

तो, क्या मुझे कुछ स्पष्ट याद आ रहा है?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/24301#issuecomment-385499702 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAuFsfnD8_kbUj8fSXvGgeN77ki6KYM6ks5tt2LLgaJpZM4Sg3bp
.

@kardianos हाँ, लेकिन इसका अभी भी मतलब है कि कोशिश करने के लिए मुझे अपने lib परिवर्तनों को धक्का देना है?

संपादित करें: ऐसा लगता है कि आप प्रतिस्थापित करने के लिए पथ का उपयोग कर सकते हैं (https://github.com/golang/go/issues/24110), जो अच्छा है। लेकिन मैं यह भी भविष्यवाणी कर सकता हूं कि यह कई बार प्रतिबद्ध होगा।

कोई अतिरिक्त फ़ाइल बनाने में सक्षम होने की कोई योजना, जैसे go.mod.replace या ऐसा कुछ, ताकि हम देव वातावरण में ओवरराइड को परिभाषित कर सकें और उन्हें gitignore कर सकें?

@primalmotion खराब कामों को रोकने के लिए आपको शायद एक गिट हुक का उपयोग करना चाहिए।

लेकिन मुझे लगता है कि सही उत्तर यह है कि ऐसा न करें (स्थानीय पथ की जगह) अक्सर। यदि आपकी लाइब्रेरी इतनी कसकर युग्मित है तो उसे अलग रेपो में नहीं रहना चाहिए (और इस प्रकार यह दिखावा करता है कि यह कम से कम युग्मित है)। सामान्य स्थिति में आप इन सेवाओं के वर्तमान कार्यान्वयन को ध्यान में रखे बिना उस lib को ठीक करने, परीक्षण करने और जारी करने में सक्षम होना चाहिए। विशेष रूप से vgo के साथ, जो गारंटी देता है कि दोनों सेवाएं पुराने lib संस्करण (जिसे वे पहले उपयोग कर रहे थे) का उपयोग करना जारी रखेंगे जब तक कि आप उन्हें उस lib के नए संस्करण में मैन्युअल रूप से अपडेट नहीं करेंगे। यदि आप कभी-कभी प्रति वर्ष एक बार स्थानीय पथों को बदलने के लिए प्रतिबद्ध होते हैं - यह कोई बड़ी बात नहीं है, सीआई आपको इसे एक मिनट में नोटिस करने और ठीक करने में मदद करेगा।

@primalmotion एक go.mod.replace के साथ संस्करणित नहीं है, आप एक ऐसी परियोजना कर सकते हैं जो प्रतिलिपि प्रस्तुत करने योग्य नहीं होगी। इसके बजाय, go.mod में बदलें के साथ आप सुनिश्चित हैं कि आप ठीक वही करते हैं जो आप वर्तमान में उपयोग करते हैं और परीक्षण करते हैं।
एक प्रतिस्थापन के साथ करने में गलती हो सकती है लेकिन आप इसे नोटिस करेंगे और इसे ठीक करेंगे।
या यह स्वैच्छिक हो सकता है, मैं इसे सबमॉड्यूल के साथ करता हूं, यह ठीक है जब आप किसी प्रोजेक्ट पर काम करते हैं और एक साथ काम करते हैं और यदि आप सबमॉड्यूल करते हैं तो यह प्रतिलिपि प्रस्तुत करने योग्य है। मैंने इसे अक्सर पायथन में किया और इसे गो के साथ याद किया। vgo के साथ मुझे खुशी है कि मैं फिर से उसी तरह काम कर सकता हूं। _(आशा है कि मेरी खराब अंग्रेजी के साथ स्पष्ट हो, क्षमा करें)।_

ठीक है, समस्या यह है कि जब तक हम यह तय नहीं कर लेते कि हम परवाह करते हैं (यानी जब हम रिलीज़ तैयार करते हैं) तब तक हम प्रतिलिपि प्रस्तुत करने योग्य बिल्ड की परवाह नहीं करते हैं। हमारे पास एक बहुत ही फुर्तीला देव वातावरण है जहां एक लिब को अपडेट करना सिर्फ चेकआउट, पुनर्निर्माण, परीक्षण चलाना है। हम अपनी सेवाओं की मास्टर शाखाओं में Gopkg.lock को प्रतिबद्ध नहीं करते हैं, केवल बाहरी कामों के लिए निश्चित संस्करणों के साथ टॉमल, और हमारे लिए प्रमुख बाधाएं। एक बार जब हम एक रिलीज शाखा बनाते हैं, तो हम Gopkg.lock करते हैं और उसके बाद ही हमारे पास प्रतिलिपि प्रस्तुत करने योग्य बिल्ड होते हैं (यह हमारे सीआई द्वारा किया जाता है)।

Vgo मूल रूप से उन सभी वर्कफ़्लो को तोड़ता है जो हमने वर्षों में बनाए हैं। अब बस एक lib में एक छोटे से प्रिंट डिबगिंग के रूप में गूंगा के रूप में कुछ कोशिश करने के लिए (क्योंकि हम सभी ऐसा करते हैं, झूठ मत बोलो :)), या थोड़ा अनुकूलन, हमें दर्जनों सेवाओं पर जाना होगा, replace जोड़ें

vgo हमारे लिए क्या काम कर सकता है:

• एक ओवरराइड सिस्टम जैसा कि मैंने उल्लेख किया है
• इसका बिल्कुल भी उपयोग न करने और विकास के लिए अच्छे पुराने GOPATH पर वापस जाने का एक तरीका।

और हम वास्तव में चाहते हैं कि यह हमारे लिए काम करे, क्योंकि यह बहुत बढ़िया है।

क्या हमारे पास 1.11 में परीक्षण करने के लिए कुछ हो सकता है (यह अभी फ्रीज में है) या शायद 1.12 पर जाएं?
यह पहले से ही प्रयोगात्मक के रूप में चिह्नित है। और मुझे लगता है कि जितने अधिक लोग वास्तविक विकास में इसका परीक्षण करेंगे, प्रतिक्रिया उतनी ही अधिक मूल्यवान होगी।

मैंने संस्करण वाले पैकेजों के संबंध में समस्या के बारे में पढ़ा। एक साधारण परिदृश्य के लिए, यदि मैं एक पुस्तकालय लिखता हूं जो कहता है कि foo-plist नामक प्लिस्ट को पार्स करने के लिए एक डीपी का उपयोग करें। पार्सिंग के परिणाम के लिए, वह प्लिस्ट लाइब्रेरी अपने स्वयं के कुछ प्रकारों को उजागर करती है। अब वह पुस्तकालय v2 में अपग्रेड हो गया है, और मेरी लाइब्रेरी को v2 में अपग्रेड करने के लिए मजबूर किया गया है यदि मैं उन प्लिस्ट प्रकारों की किसी भी वस्तु को वापस करने के लिए हुआ हूं।

यह हल करना काफी कठिन प्रतीत होता है, उदाहरण के लिए, यदि मैं चाहता हूं कि मेरी लाइब्रेरी इस प्रस्ताव की छाप के तहत उक्त प्लिस्ट लाइब्रेरी के v1 और v2 दोनों का समर्थन करे।

एनपीएम के तहत, उदाहरण के लिए, मेरी लाइब्रेरी केवल >=1.0.0|>=2.0.0 कहने के लिए एक सहकर्मी निर्भरता निर्दिष्ट कर सकती है और यह मेरी लाइब्रेरी के उपयोगकर्ता पर निर्भर है कि वह प्लिस्ट के किस संस्करण का उपयोग करे। इसलिए यदि मेरे पुस्तकालय का उपयोगकर्ता foo-plist किसी अन्य पुस्तकालय का भी उपयोग करता है जो plist पर निर्भर करता है, तो यदि दोनों पुस्तकालय प्लिस्ट के v1 और v2 से खुश हैं, तो उपयोगकर्ता चुन सकता है कि कौन से पुस्तकालय हैं वास्तव में आयात। इससे भी महत्वपूर्ण बात यह है कि यदि दोनों पुस्तकालय प्लिस्ट प्रकारों का निर्यात करते हैं, तो वे प्रकार वास्तव में संगत होते हैं।

यदि वे अलग-अलग आयात पथ होते हैं तो मुझे नहीं लगता कि इसका समर्थन करने के कोई तरीके हैं।

@itsnotvalid foo-plist.2 foo-plist आयात कर सकता है और टाइप उपनामों का उपयोग करके इसके प्रकारों को पुनः निर्यात कर सकता है। इस तकनीक का अच्छा विवरण यहां पाया जा सकता है https://github.com/dtolnay/semver-trick

पिछली रिलीज शाखाओं (या निर्देशिका) में बैक-पोर्टिंग परिवर्तनों की कठिनाई के बारे में अराम ने यहां एक बिंदु बनाया। चूंकि एक ही मॉड्यूल के भीतर स्रोतों के "स्वयं" संदर्भ में आयात पथ में संस्करण भी शामिल है, या तो पैच स्पष्ट रूप से आयात नहीं करेंगे या कोई अनजाने में क्रॉस-वर्जन आयात पेश कर सकता है।

विचार?

स्पष्ट होने के लिए, मैं आयात पथ में संस्करणों का उपयोग करके क्रॉस-मॉड्यूल आयात के साथ पूरी तरह से सहज हूं; मुझे लगता है कि Russ के तर्क बहुत ठोस रहे हैं। मैं मॉड्यूल के भीतर आयात के लिए उनके बारे में कम स्पष्ट हूं। मैं एक बिल्ड में दिए गए पैकेज के लिए एकल आयात पथ रखने के लक्ष्य को समझता हूं (चाहे वह क्रॉस-मॉड्यूल आयात किया जा रहा हो या अपने मॉड्यूल के भीतर), लेकिन अगर मुझे चुनना होता, तो मेरे पास इसका समाधान होता इस संपत्ति को बनाए रखने की तुलना में अराम की समस्या। (साथ ही, मुझे लगता है कि बिल्ड सिस्टम शीर्ष-स्तरीय मॉड्यूल बनाते समय मॉड फ़ाइल से संस्करण को इंजेक्ट कर सकता है, और मॉड्यूल निर्भरता डाउनलोड करने के बाद इसे सचमुच स्रोत में इंजेक्ट कर सकता है)

@rsc क्या कोई मौका है कि हम इसे आगे बढ़ा सकें? मुझे इसे वापस पकड़े हुए कुछ भी बड़ा नहीं दिख रहा है।

मुझे खेद है कि अगर मैं इसके बारे में अधीर लग रहा हूं, लेकिन वीजीओ के समर्थन पर अधिक से अधिक उपकरण काम कर रहे हैं और जितना अधिक हम इसमें देरी करेंगे, उतना ही यह हमारे लिए, उपकरण अनुरक्षकों के लिए, इस पर आगे और पीछे जाने के लिए एक गड़बड़ करने वाला है। .

@sdboyer इस सप्ताह अपने लेखन को प्रकाशित करने की योजना बना रहा है। मैं कहूंगा कि उनका इंतजार करना उचित है।

मुझे लगता है कि कौन से निर्भरता संस्करणों को चुनने के लिए समाधान एल्गोरिदम पूरे प्रस्ताव को अवरुद्ध करने का कारण नहीं होना चाहिए, जिसमें मॉड्यूल, प्रॉक्सी समर्थन, संस्करण आदि जैसी चीजें भी शामिल हैं।

और अगर हम बाद में इन निर्भरताओं को डाउनलोड करने के लिए एल्गोरिदम को सुधारने/बदलने का निर्णय लेते हैं, तो हम किसी और चीज को प्रभावित किए बिना ऐसा कर सकते हैं।

मैं @dlsniper से सहमत हूं - हम पहले से ही फ्रीज में हैं, और लगभग तीन महीने हो गए हैं जब से vgo डिजाइन पेश किया गया था। अगर 1.11 पर इसके काम में और देरी होती है, तो मुझे चिंता है कि यह 1.12 पर वापस धकेल दिया जाएगा।

एक श्रृंखला क्या होगी में पहली पोस्ट अंत में लाइव है। मुझे खेद है कि इसे प्रकाशित होने में इतना समय लगा है, और यह कि श्रृंखला समाप्त होने में अभी और समय लगेगा। लेकिन, पहली पोस्ट उन विषयों का व्यापक अवलोकन प्रदान करती है जिन्हें मैं पूरी श्रृंखला में कवर करने का इरादा रखता हूं, इसलिए लोगों को कम से कम गुंजाइश की भावना प्राप्त करने में सक्षम होना चाहिए।

संक्षेप में: vgo के बारे में बहुत सी अच्छी चीजें हैं, जिनमें से कई हम एक समुदाय के रूप में लंबे समय से चाहते हैं। हालांकि, मेरा मानना ​​है कि एमवीएस उद्देश्य के लिए अनुपयुक्त है, और इसे उत्पादन के लिए नहीं बनाना चाहिए। यह शर्म की बात है कि इनमें से बहुत सी चीजें जो हम चाहते हैं, एमवीएस के इर्द-गिर्द लिपटी हुई हैं, खासकर जब उनमें से कुछ इसके लिए विशिष्ट हैं। मैं एक वैकल्पिक दृष्टिकोण पर काम कर रहा हूं, जिसे संपूर्ण ब्लॉग श्रृंखला में तुलनात्मक उद्देश्यों के लिए संदर्भित किया गया है, और अंतिम पोस्ट में व्यक्त किया जाएगा।

मैं जिस वैकल्पिक कोर एल्गोरिदम पर काम कर रहा हूं, वह संभवतः go.mod पर माइग्रेट करने के लिए बहुत सरल होगा, इसलिए मुझे यह अनुमान नहीं है कि हमें समस्याएं होंगी, शायद इसे आगे बढ़ने देना संभव होगा, यदि एक अलग लॉक फ़ाइल जोड़ी गई थी जिसमें निर्भरता का संक्रमणीय बंद होना शामिल है, और _that_ वह होना चाहिए जो कंपाइलर पढ़ता है, न कि बिल्ड लिस्ट एल्गोरिथम से। (लॉक फ़ाइल के अन्य कारण भी हैं, हालांकि यह 5 के बाद होगा।) कम से कम, यह हमें एक एस्केप वाल्व देता है।

हालांकि, अगर हम कहते हैं कि एमवीएस ठीक है, यहां तक ​​​​कि स्टॉपगैप के रूप में, तो यह अंदर जाता है और जड़ता का लाभ प्राप्त करता है। उस बिंदु पर, हमें इसे @rsc के लिए अपर्याप्त साबित करना होगा (हालांकि वास्तव में, उन्होंने इसे विलय से पहले ही मानक के रूप में सेट कर दिया है), और उनका मानना ​​​​है कि यह go get के बारे में एक सही बयान है, अभी:

आज, कई प्रोग्रामर ज्यादातर वर्जनिंग पर ध्यान नहीं देते हैं, और सब कुछ ज्यादातर ठीक काम करता है।

उपरोक्त सभी को देखते हुए, मेरा डर यह है कि इसे आगे बढ़ने देने से "जेनेरिक, राउंड टू" बन जाएगा - इस समय को छोड़कर यह नियमों के आसपास है जो नियंत्रित करते हैं कि हम एक दूसरे के साथ कैसे बातचीत करते हैं, मशीनों के साथ नहीं।

हालांकि, अगर हम कहते हैं कि एमवीएस ठीक है, यहां तक ​​​​कि स्टॉपगैप के रूप में, तो यह अंदर जाता है और जड़ता का लाभ प्राप्त करता है।

ध्यान दें, कि अभी , dep को जड़ता का लाभ है (दोनों अन्य भाषा के संस्करण प्रबंधकों के समान परिसर में और व्यापक सामुदायिक समर्थन के साथ लंबे समय तक विद्यमान रहने के द्वारा)। कम से कम मेरे लिए, vgo प्रस्ताव अभी भी इस जड़ता को दूर करने के लिए एक अच्छा डिजाइन, अच्छे तर्कों द्वारा समर्थित होने में कामयाब रहा।

मुझे व्यक्तिगत रूप से कोई आपत्ति नहीं है अगर गो में संस्करण बनाने में देरी हो जाती है, तो मैं जल्दी के बजाय कुछ सही करने के पक्ष में हूं। लेकिन कम से कम फिलहाल, वीजीओ अभी भी मेरे लिए सही समाधान की तरह दिखता है (और एआईयूआई समुदाय के कई लोग इसे एक जरूरी समस्या के रूप में देखते हैं)।

@mvdan यह परिवर्तन इसके नतीजों के बिना नहीं है। हम सभी यह चाहते हैं, लेकिन मुझे लगता है कि संदेह को दूर करने के लिए अतिरिक्त समय निकालना भी बुद्धिमानी है, खासकर जब उन संदेहों को उठाने वाले व्यक्ति ने स्पष्ट रूप से समस्या पर बहुत विचार किया है।

मैं vgo में 1.11 का पूर्वावलोकन प्राप्त करने पर फ़्रीज़ और उसके प्रभाव का उल्लेख सुनता रहता हूँ। इस बिंदु पर आधिकारिक लाइन क्या है कि क्या इसे 1.11 के लिए एकीकृत किया जाएगा? संभावित प्रभाव को देखते हुए यह मुद्दा मुझे आश्चर्यजनक रूप से शांत प्रतीत होता है।

@sdboyer इस पर आपकी क्या स्थिति है कि क्या इसे 1.11 में विलय कर दिया जाना चाहिए, यह देखते हुए कि आपके पास केवल _just_ आधिकारिक तौर पर, सार्वजनिक रूप से, MVS पर आपकी स्थिति है?

यदि यह इसे 1.11 में नहीं बनाता है, तो हमारे पास यह आधिकारिक तौर पर फरवरी 2019 में 1.12 तक पूर्वावलोकन के लिए उपलब्ध नहीं होगा और अगस्त में कम से कम 1.13 तक आधिकारिक रूप से जारी नहीं किया जाएगा। 2019 @rsc द्वारा पहली बार इस पर चर्चा शुरू करने के 18 महीने बाद यह जल्द से जल्द संभावित रिलीज़ रखता है। बेशक हमें इसे अनावश्यक रूप से जल्दी नहीं करना चाहिए, लेकिन जैसा कि @Merovius ने ऊपर कहा है, कई लोग, जिनमें स्वयं शामिल हैं, निर्भरता प्रबंधन के लिए एक आधिकारिक प्रतिक्रिया को एक "तत्काल" मुद्दा मानते हैं। 18 महीने का इंतजार ज्यादा लगता है।

यह निश्चित रूप से लग रहा था कि dep आधिकारिक प्रतिक्रिया होने वाली थी और हमने अपनी रिपॉजिटरी को इसमें बदल दिया है (और इसके परिणामों से प्रसन्न हैं)। इस प्रस्ताव के साथ लंबे समय तक उपयोग के लिए dep को प्रभावी ढंग से हटा दिया गया है, फिर भी vgo को एकीकृत करना शुरू करने का कोई आधिकारिक तरीका नहीं है (कम से कम #25069 विलय होने तक), हमें मजबूर होने की असंतोषजनक स्थिति में छोड़ दिया गया है एक उपकरण का उपयोग करें ( dep के साथ) जिसे हम जानते हैं कि इसकी शेल्फ लाइफ बहुत सीमित है।

एफडब्ल्यूआईडब्ल्यू, मुझे पूरी तरह से लगता है कि हमें vgo 1.11 एक प्रस्ताव के रूप में एकीकृत करके और 1.11 में #25069 को शामिल करके (और पैच रिलीज के रूप में 1.9 के साथ आगे बढ़ना चाहिए) 1.10 के रिलीज होने पर 1.11 )।

मैं ईमानदारी से एमवीएस के पूर्ण प्रभावों और @ एसडीबॉयर की चिंताओं को इसके बारे में नहीं समझता। हालांकि, इस क्षेत्र में उनके अनुभव को देखते हुए, मुझे लगता है कि उन चिंताओं पर गंभीरता से विचार किया जाना चाहिए। उस ने कहा, अगर वह vgo को एमवीएस के साथ 1.11 में एकीकृत करने के साथ जहाज पर है (यह समझते हुए कि उसका [अभी भी विकसित हो रहा है] प्रस्ताव, अगर स्वीकार किया जाता है [ 1.12 के लिए], मॉड्यूल को तोड़ना नहीं चाहिए मूल रूप से एमवीएस के लिए डिज़ाइन किया गया), तो मुझे आगे बढ़ने का कोई कारण नहीं दिखता है।

मैं इस प्रस्ताव के लिए @rsc को भी धन्यवाद देना चाहता हूं। मैं सराहना करता हूं कि गो ने किसी अन्य टूल के दृष्टिकोण की प्रतिलिपि नहीं बनाई और इस मुद्दे को इस तरह से संबोधित करने की कोशिश कर रहा है जो मूर्खतापूर्ण लगता है। जबकि निर्भरता प्रबंधन कभी मज़ेदार नहीं होता है, यह निश्चित रूप से लगता है कि, इस प्रस्ताव के साथ, गो में उद्योग को आगे बढ़ाने की क्षमता है और संभवतः यहां तक ​​​​कि लीपफ्रॉग सिस्टम भी हैं जिन्हें वर्तमान में सबसे अच्छी नस्ल माना जाता है।

बस मेरा $.02 जोड़ने के लिए, मेरी राय है कि एमवीएस निर्भरता प्रबंधन के लिए एक "आह हा" क्षण है। मैं इस बात की सराहना करता हूं कि लोगों ने इसके प्रति कितना सोचा है, लेकिन मैं आश्वस्त हूं कि एमवीएस वह जगह है जहां इसे जाने की जरूरत है।

मैं विशेष रूप से उन बिंदुओं से सहमत हूं जो दूसरों ने उठाए हैं: "स्वचालित सुरक्षा सुधार" सबसे अच्छा एक पाइप सपना है और सबसे खराब कीड़े का एक बड़ा कैन है।

इसके अतिरिक्त, मैं @joshuarubin के साथ हूं: निर्भरता प्रबंधन के लिए एक आधिकारिक प्रतिक्रिया एक जरूरी मुद्दा है। दूसरों ने टिप्पणी की है कि हम अभी एमवीएस के साथ आगे बढ़ सकते हैं और बाद में जरूरत पड़ने पर अन्य समाधानों में बदलाव कर सकते हैं; अगर यह वास्तव में संभव है तो मुझे लगता है कि यह जाने का बेहतर तरीका है।

मैं प्रमुख संस्करणों को आयात पथ से निम्नलिखित तरीके से अलग करने का प्रस्ताव करता हूं। (मेरा मानना ​​​​है कि मैंने vgo-import में तर्क के लिए जिम्मेदार ठहराया है और मैं वहां बताई गई vgo उपलब्धियों को नीचा नहीं करता हूं।) यह #25069 से इस विचार से प्रेरित है कि go build में Go 1.9 और 1.10 को सीखना चाहिए आयात पथों की रचनात्मक रूप से व्याख्या करें (संस्करण भाग को छोड़कर); मेरे प्रस्ताव में पुराना go build नहीं बदलता है, लेकिन vgo एक समान चाल सीखता है।

सिंटैक्टिक रूप से, केवल परिवर्तन ही हैं:

1. .go फाइलों में, import "repo/v2/pkg" import "repo/v2/pkg" $ रहता है यदि v2 एक निर्देशिका है, लेकिन अन्यथा import "repo/pkg" बन जाता है। यह वर्तमान go get के साथ संगतता रखता है।
2. go.mod फाइलों में, module "repo/v2" वही रहता है यदि वह v2 उपनिर्देशिका में है, लेकिन यदि यह शीर्ष स्तर पर है तो module "repo" बन जाता है। (यह विहित आयात उपसर्ग है।)
3. go.mod फाइलों में, आप require repo v2.3.4 as repo2 भी लिख सकते हैं। फिर .go फाइलों में आप import "repo2/pkg" (या import "repo2/v2/pkg" अगर v2 एक निर्देशिका है) का उपयोग करेंगे। यह वर्तमान go get द्वारा आयात योग्य नहीं होगा (जब तक कि आप require github.com/owner/project v2.3.4 as gopkg.in/owner/project.v2 जैसी किसी चीज़ का उपयोग नहीं करते हैं), लेकिन यह केवल तभी आवश्यक है जब आप एक ही मॉड्यूल में कई प्रमुख संस्करणों का उपयोग करना चाहते हैं और निर्भरता नहीं है उपनिर्देशिकाओं में प्रमुख संस्करणों को स्टोर करें, जो कि वर्तमान go get द्वारा समर्थित नहीं हो सकता है।

तकनीकी रूप से यह आपको go.mod के साथ लिखने की अनुमति देता है:

require repo v1.0.0
require repo v1.1.1 as repo1
require repo v2.2.2 as repo2
require repo v2.3.3 as repo3

लेकिन न्यूनतम संस्करण चयन इसे इस तरह हल करेगा कि repo और repo1 दोनों रेपो को v1.1.1 पर देखें, और repo2 और repo3 v2.3.3 पर। मुझे नहीं पता कि इस एलियासिंग की अनुमति दी जानी चाहिए या प्रतिबंधित।

लाभ:

• मॉड्यूल-जागरूक कोड वर्तमान go get के साथ संगत होगा, यहां तक ​​कि पिछले v2.0.0 के साथ भी; फलस्वरूप:
  
  
  
  • go get कम से कम मॉड्यूल जागरूक करने की कोई आवश्यकता नहीं है (#25069)
  
  
  • v2.0.0 के पिछले प्रोजेक्ट्स को मॉड्यूल-अनभिज्ञ go get . के साथ संगतता नहीं तोड़नी पड़ेगी
  
  
• परियोजनाओं को स्वयं मॉड्यूल बनने से पहले अपनी निर्भरता के मॉड्यूल बनने की प्रतीक्षा नहीं करनी पड़ेगी [1]
• मॉड्यूल-अनजान परियोजनाओं को हटाने या लेखकों को नए मॉड्यूल-अनभिज्ञ परियोजनाओं को शुरू करने से हतोत्साहित करने की कोई आवश्यकता नहीं है
• वर्तमान go get के संस्करणहीन कार्यप्रवाह के लिए समर्थन रखना आसान है ( यहां और ऊपर समझाया गया है)

नुकसान:

• वादा निभाने के लिए असुविधाजनक हो सकता है कि पहले से ही लिखी गई go.mod फाइलें काम करती रहेंगी (जब तक कि नई मॉड्यूल फ़ाइल को go.mod से अलग नाम नहीं दिया जाता है)

महत्वाकांक्षाएं:

• विभिन्न मॉड्यूल में एक ही आयात पथ विभिन्न प्रमुख संस्करणों को संदर्भित कर सकता है
  
  
  
  • अच्छा: पिछले v2.0.0 और प्रमुख संस्करण परिवर्तन पर बनाए रखना आसान है
  
  
  • खराब: आप go.mod . को देखे बिना नहीं जानते कि आप किस प्रमुख संस्करण का उपयोग करते हैं
  
  
• मॉड्यूल अपने कोड के भीतर उपयोग के लिए मनमाने ढंग से आयात उपसर्गों को परिभाषित कर सकते हैं
  
  
  
  • कुछ उपयोगकर्ता संक्षिप्त नाम से सब कुछ आयात करना चुनेंगे (उदाहरण के लिए import "yaml" साथ में require gopkg.in/yaml.v2 v2.2.1 as yaml )
  
  

[1] वर्तमान में vgo गैर-मॉड्यूलर निर्भरताओं का ठीक से समर्थन कर सकता है, जब तक कि मॉड्यूल की कोई गैर-मॉड्यूलर ट्रांजिटिव निर्भरता v2.0.0 से अधिक न हो। अन्यथा परियोजना को उन सभी निर्भरताओं के लिए इंतजार करना पड़ता है जो अप्रत्यक्ष रूप से मॉड्यूल बनने के लिए v2.0.0 से पहले की परियोजना पर निर्भर करती हैं।

मैंने Gopkg.toml फ़ाइलों का विश्लेषण किया है जिन्हें मैं https://github.com/rsc/corpus में पैकेज से ढूंढने में सक्षम था और https://github.com/zeebo/dep-analysis पर एक सारांश लिखा था । वहां के आंकड़ों के आधार पर, ऐसा लगता है कि इस बात के अधिक प्रमाण नहीं हैं कि vgo लगभग हर पहचाने गए उपयोग के मामले को संभालने में सक्षम नहीं होगा।

मुझे वास्तव में उम्मीद है कि इससे समुदाय में डर कम करने में मदद मिलेगी, और एक समझौते पर आने में मदद मिलेगी कि हमें प्रस्ताव के साथ आगे बढ़ना चाहिए, यह याद रखना कि उपकरण के साथ वास्तविक अनुभव प्राप्त करने के लिए अतिरिक्त 6 महीने होंगे, और उत्पन्न होने वाली किसी भी समस्या को ठीक करने के लिए कोई भी आवश्यक परिवर्तन।

अगर मैं आपको उद्धृत करता हूं:

सभी बाधाओं में से लगभग आधे वास्तव में बिल्कुल भी बाधा नहीं हैं: वे मास्टर शाखा की ओर इशारा करते हैं।

यह शायद इसलिए है क्योंकि केवल मास्टर में कोई टैग नहीं है या "नाम वाली शाखाएं जैसे v2, v3" मौजूद हैं यदि ऐसा है तो तुलना उचित नहीं है क्योंकि आपके पास कोई विकल्प नहीं है!

@mvrhov मुझे यकीन नहीं है कि "निष्पक्ष" से आपका क्या मतलब है। यह मुझे प्रतीत होगा, कि vgo और dep उस मामले को ठीक से संभाल लेंगे। या यों कहें, किसी भी यथार्थवादी विकल्प को उस मामले को ठीक से संभालना होगा। विशेष रूप से: यदि अभी तक कोई जारी संस्करण नहीं है, तो एक vgo दुनिया में उन्हें केवल v1.0/v0.x टैग किया जा सकता है और किसी भी आयात पथ (vgo का मुख्य स्वभाव) में कोई बदलाव आवश्यक नहीं होगा।

जहां तक ​​​​मैं कह सकता हूं, विश्लेषण का मुद्दा विभिन्न दृष्टिकोणों के कारण वास्तविक दुनिया के दर्द का प्रयास करना और अनुमान लगाना है। मैं नहीं देखता कि यह मामला किसी के लिए वास्तविक दर्द कैसे पेश करता है।

यह प्रस्ताव दो महीने से अधिक समय से सक्रिय चर्चाओं के साथ खुला है: @rsc & @spf13 ने फीडबैक सत्र आयोजित किए हैं और समुदाय से मूल्यवान इनपुट एकत्र किए हैं जिसके परिणामस्वरूप प्रस्ताव में संशोधन हुआ है। @rsc ने आगे की प्रतिक्रिया प्राप्त करने के लिए @sdboyer के साथ साप्ताहिक बैठकें भी की हैं। प्रस्ताव पर बहुमूल्य फीडबैक प्रदान किया गया है जिसके परिणामस्वरूप अतिरिक्त संशोधन हुए हैं। तेजी से यह प्रतिक्रिया प्रस्ताव के बजाय साथ के कार्यान्वयन पर है। काफी समीक्षा के बाद हमें लगता है कि इस प्रस्ताव को स्वीकार करने का समय आ गया है और टूल कार्यान्वयनकर्ताओं के गो के व्यापक पारिस्थितिकी तंत्र को महत्वपूर्ण समायोजन करने दें ताकि हमारे उपयोगकर्ता आधार को सर्वोत्तम संभव अनुभव हो सके।

इस प्रस्ताव पर दो आपत्तियां आई हैं जिनके बारे में हमें लगता है कि हमें इस पर बात करनी चाहिए:

1. प्रस्ताव के लिए लोगों को पुस्तकालयों का उपयोग करने और जारी करने के आसपास अपनी कुछ प्रथाओं को बदलने की आवश्यकता होगी।
2. प्रस्ताव उन सभी संभावित परिदृश्यों के लिए तकनीकी समाधान प्रदान करने में विफल रहता है जो असंगति से उत्पन्न हो सकते हैं।

ये उनके अवलोकन में सटीक हैं लेकिन इरादे से काम कर रहे हैं। कोड _will_ के लेखकों और उपयोगकर्ताओं को पुस्तकालयों का उपयोग करने और जारी करने के आसपास अपनी कुछ प्रथाओं को बदलना होगा, जैसे कि डेवलपर्स ने गो के अन्य विवरणों के लिए अनुकूलित किया है, जैसे कि gofmt चलाना। सर्वोत्तम प्रथाओं को स्थानांतरित करना कभी-कभी सही समाधान होता है। इसी तरह, vgo को असंगतताओं वाली सभी संभावित स्थितियों को संभालने की आवश्यकता नहीं है। जैसा कि रस ने गोफरकॉन सिंगापुर में अपनी हालिया बातचीत में बताया, असंगति का एकमात्र स्थायी समाधान असंगति को ठीक करने और गो पैकेज पारिस्थितिकी तंत्र को बनाए रखने के लिए मिलकर काम करना है। vgo या dep जैसे टूल में अस्थायी वर्कअराउंड केवल डेवलपर्स को वास्तविक समस्या को हल करने के लिए समय देने के लिए पर्याप्त समय तक काम करने की आवश्यकता होती है, और vgo इस काम को अच्छी तरह से करता है।

हम इस महत्वपूर्ण मुद्दे पर आपके द्वारा लाए गए सभी फीडबैक और जुनून की सराहना करते हैं। प्रस्ताव को स्वीकार कर लिया गया है।

- गो प्रस्ताव समीक्षा समिति

रिकॉर्ड में कुछ रंग जोड़ने के लिए, @sdboyer के साथ साप्ताहिक बैठकों को समर्थन के रूप में नहीं देखा जाना चाहिए। सैम ने हाल ही में एमवीएस के साथ समस्याओं के साथ-साथ उन चीजों के बारे में लिखना शुरू किया जो उसे vgo के बारे में पसंद हैं । मैं इसे यह सुनिश्चित करने के लिए जोड़ रहा हूं कि किसी और के साथ कुछ गलत संचार न हो जो साथ आता है। अगर आप उनकी राय चाहते हैं तो कृपया उनके शब्दों को पढ़ें। मेरा मानना ​​है कि उनमें वर्तमान इच्छित दृष्टिकोण से काफी हद तक असहमति है।

@mattfarina FWIW, मैंने उस वाक्य को और अधिक पढ़ा "हम उनकी आलोचना से अवगत हैं (जैसा कि उन्होंने इसे निजी तौर पर व्यक्त किया है) और इससे हमारी राय नहीं बदली"। यह खेदजनक है कि उनकी राय और तर्क इस बिंदु तक सार्वजनिक नहीं हैं, हालांकि।

यह एक प्रस्ताव को स्वीकार करने के लिए गैर-जिम्मेदाराना महसूस करता है, जबकि दृष्टिकोण पर अभी भी मूलभूत चिंताएं बकाया हैं। लेखक और समुदाय डोमेन विशेषज्ञ @sdboyer के बीच सहमति प्रस्ताव को स्वीकार किए जाने से पहले पहुंचने के लिए एक उचित न्यूनतम मानक की तरह लगता है।

@merovius हम में से कई लोगों ने सार्वजनिक और निजी तौर पर राय साझा की है। बहुत से लोगों को लगता है कि उठाए गए मुद्दों को पर्याप्त समाधान दिए जाने के बजाय स्टीमरोल (कभी-कभी अशिष्टता से) किया गया था। मैं व्यावहारिक समस्याओं को सार्वजनिक रूप से साझा करना शुरू कर रहा हूं ताकि हम उन्हें हल करने का प्रयास कर सकें। उदाहरण के लिए, आज ही मैं यहां एक व्यावहारिक समस्या के बारे में कुछ विवरण साझा कर रहा हूं। मजेदार साइड नोट, यह हैकर समाचार के पहले पन्ने पर था उसी समय इसे स्वीकृत के रूप में चिह्नित किया गया था।

@peterbourgon एक ऐसे व्यक्ति के रूप में जिसने गो डिपेंडेंसी मैनेजमेंट सर्वे किया और जिसने ग्लाइड पर काम किया, जहां मैंने लोगों की जरूरतों को सुना और उस काम को करने की कोशिश की, मैं व्यावहारिक समस्याएं दिखा सकता हूं (सिर्फ राय के बजाय)। यानी मैं उन समस्याओं के समाधान के लिए उपयोगकर्ताओं की इच्छाओं, जरूरतों और अपेक्षाओं का मिलान कर सकता हूं। मेरी चिंता यह है कि vgo के वर्तमान पथ के लिए बेमेल है। लोग निर्भरता प्रबंधन कैसे करते हैं, इसमें अंतर के कारण अधूरी जरूरतें और व्यावहारिक समस्याएं हैं।

मेरी चिंताओं को कम करने का एक आसान तरीका है कि कुबेरनेट्स के लिए टिम हॉकिन्स की संतुष्टि के लिए वीजीओ काम किया जाए।

मेरी चिंताओं को कम करने का एक आसान तरीका है कि कुबेरनेट्स के लिए टिम हॉकिन्स की संतुष्टि के लिए वीजीओ काम किया जाए।

आज कुबेरनेट्स के लिए वीजीओ कार्य करें या आने वाले वर्षों में कुबेरनेट्स के लिए वीजीओ कार्य करें? जैसा कि मैं इसे समझता हूं, vgo और dep के बीच मौलिक डिजाइन असहमति में से एक यह है कि क्या हमें पारिस्थितिकी तंत्र के साथ काम करने की आवश्यकता है क्योंकि यह आज मौजूद है (डिप की धारणा) या क्या हम समुदाय को टैग की गई रिलीज़ करने और संगतता बनाए रखने की ओर स्थानांतरित कर सकते हैं (vgo की धारणा) .

इसलिए यह संभव है कि कुछ समय के लिए vgo कई-निर्भरता-कुबेरनेट्स का उपयोग करने के लिए काम न करे, जब तक कि गो समुदाय के मानदंडों में बदलाव न हो जाए।

@mattfarina ज़रूर। निजी तौर पर, मुझे इसे "स्टीमरोल" के रूप में चित्रित करने में बहुत निराशा होती है, हालांकि। @sdboyer ने महीनों तक सार्वजनिक चर्चा से काफी हद तक परहेज किया है और अभी भी उनकी ओर से कोई वास्तविक, ठोस तर्क नहीं है। उसके अपने कारण थे और यह उचित है। लेकिन आम सहमति के लिए अभी भी चर्चा की आवश्यकता है और कम से कम जहां तक ​​​​सार्वजनिक रिकॉर्ड का संबंध है, मैं व्यक्तिगत रूप से ऐसे किसी भी मुद्दे से अवगत नहीं हूं जहां लाया गया और स्पष्ट रूप से अनदेखा किया गया (हालांकि अभी तक आपकी पोस्ट नहीं पढ़ी गई है)।

जहां तक ​​मेरा सवाल है, कोई भी चर्चा बंद दरवाजों के पीछे चलती थी। और यह देखते हुए कि हमारे पास किसी भी तरह से कोई जानकारी नहीं है, मैं यह मान लेना उचित समझूंगा कि दोनों पक्षों ने जहां उचित विचार किया है।

@bradfitz SemVer का उपयोग आज Go pacakges द्वारा किया जाता है, आमतौर पर PHP में, node.js में, रस्ट में, और कई अन्य भाषाओं में। यह काफी सामान्य बात है। मुझे इन भाषाओं में समस्याओं का सामना करना पड़ा है और अधिक जहां संकुल SemVer संगतता मुद्दों से टूट गया है। कभी जानबूझकर तो कभी दुर्घटनावश। इन सभी अन्य भाषाओं में मौजूद समस्या से बचने के लिए गो अलग तरीके से क्या करेगा क्योंकि लोग गलत हैं?

अगर हम यह स्पष्ट नहीं कर सकते हैं कि यह एक बुरी धारणा है कि संगतता हमेशा बनी रहेगी और डेवलपर्स के पास उन्हें ट्यून करने के लिए सुलभ नहीं होना चाहिए और उस जानकारी को निर्भरता पेड़ तक पहुंचाना चाहिए।

मुझे लगता है कि हर कोई सहमत होगा: निर्भरता प्रबंधन के साथ वर्तमान स्थिति किसी भी भाषा/मंच में भयानक है। मेरा मानना ​​​​है कि @bradfitz ने संघर्ष के मुख्य बिंदु को सही ढंग से समझाया। हो सकता है कि vgo सफल न हो, लेकिन मेरे लिए यह स्पष्ट है कि हमें कुछ बदलना होगा (मेरा मतलब न केवल गो में है, बल्कि सामान्य रूप से है), और vgo इसे आज़माने के लिए बहुत आशाजनक लगता है।

@mattfarina हम एक ऐसी सेवा को लागू करने का प्रयास करने की योजना बना रहे हैं जो स्वचालित रूप से नियंत्रित होगी संगतता वास्तव में बनाए रखी जाती है। इसे godoc.org के साथ एकीकृत करना, README के ​​लिए बैज प्रदान करना, इसे गो गेट के लिए प्रॉक्सी के रूप में उपयोग करना - ऐसे कई तरीके हैं जिनसे हम इसे पर्याप्त रूप से काम करने का प्रयास कर सकते हैं। निश्चित रूप से, @sdboyer एपीआई संगतता के बारे में सही है, वास्तविक संगतता की गारंटी नहीं देता है, लेकिन यह एक अच्छी शुरुआत है और ज्यादातर मामलों में काफी अच्छा काम करना चाहिए।

इसलिए यह संभव है कि कुछ समय के लिए vgo कई-निर्भरता-कुबेरनेट्स का उपयोग करने के लिए काम न करे, जब तक कि गो समुदाय के मानदंडों में बदलाव न हो जाए।

आशा कोई रणनीति नहीं है, खासकर जब मौजूदा व्यवहार और अपेक्षाएं पहले से ही अच्छी तरह से स्थापित हो चुकी हों। अगर हम पांच साल पहले यह चर्चा कर रहे थे, तो गो के पास यहां खर्च करने के लिए नवाचार टोकन हो सकते थे, और चीजें प्रभावित करने के लिए अधिक उत्तरदायी थीं। लेकिन इस मुद्दे को इतने लंबे समय तक अनदेखा करने के परिणामस्वरूप, मुझे यह स्पष्ट लगता है कि अब प्रस्तावित किसी भी टूलिंग को उपयोगकर्ताओं से मिलना चाहिए जहां वे हैं।

इन सभी अन्य भाषाओं में मौजूद समस्या से बचने के लिए गो अलग तरीके से क्या करेगा क्योंकि लोग गलत हैं?

हम किसी प्रकार के go release कमांड पर चर्चा कर रहे हैं जो दोनों रिलीज/टैगिंग को आसान बनाता है, लेकिन एपीआई संगतता की भी जांच करता है (जैसे गो-आंतरिक go tool api चेकर जिसे मैंने गो रिलीज के लिए लिखा था)। यह किसी भी टैग को पुश करने से पहले godoc.org को क्वेरी करने और आपके पैकेज के कॉलर्स को खोजने और रिलीज से पहले के समय पर आपके नए संस्करण के खिलाफ उनके परीक्षण चलाने में भी सक्षम हो सकता है। आदि।

अपने पैकेज के कॉलर ढूंढें और किसी भी टैग को पुश करने से पहले, रिलीज से पहले के समय पर अपने नए संस्करण के खिलाफ उनके परीक्षण चलाएं। आदि।

यह वास्तव में किसी के लिए भी व्यावहारिक नहीं है जो Google नहीं है।

यह वास्तव में किसी के लिए भी व्यावहारिक नहीं है जो Google नहीं है।

सभी क्लाउड प्रदाताओं के साथ-साथ-एक-सेवा के रूप में भुगतान-दर-सेकंड की पेशकश शुरू करने के साथ, मुझे कोई कारण नहीं दिखता कि हम इसे एक ओपन सोर्स टूल के रूप में प्रदान नहीं कर सके जिसे कोई भी चला सकता है और $0.57 या $ 1.34 का भुगतान कर सकता है जिसकी उन्हें आवश्यकता है कुछ मिनटों के लिए मेजबानों के एक समूह पर एक अरब परीक्षण चलाने के लिए।

जब परीक्षण चलाने की बात आती है तो बहुत अधिक Google गुप्त सॉस नहीं होता है।

सभी क्लाउड प्रदाताओं के साथ-साथ-एक-सेवा के रूप में भुगतान-दर-सेकंड की पेशकश शुरू करने के साथ, मुझे कोई कारण नहीं दिखता कि हम इसे एक ओपन सोर्स टूल के रूप में प्रदान नहीं कर सके जिसे कोई भी चला सकता है और $0.57 या $ 1.34 का भुगतान कर सकता है जिसकी उन्हें आवश्यकता है कुछ मिनटों के लिए मेजबानों के एक समूह पर एक अरब परीक्षण चलाने के लिए।

इसके लिए एक विशिष्ट क्लाउड प्रदाता के साथ एक खाते की आवश्यकता होती है, इसके लिए आवश्यक है कि आप एक विशिष्ट क्लाउड प्रदाता सेवा की शर्तों को स्वीकार करें (जो आप कानूनी कारणों से करने में सक्षम हो सकते हैं या नहीं भी कर सकते हैं, भले ही अधिकांश दुनिया इसे ऐसा मानती है जैसे कि यह नहीं है) मामला), यह आवश्यक है कि आप ऐसे क्षेत्र में रहते हैं जहां क्लाउड प्रदाता सेवाएं (उदाहरण के लिए, यदि आप ईरान में हैं और क्लाउड प्रदाता संयुक्त राज्य में हैं तो आप निर्यात कानूनों के कारण इसका उपयोग करने में सक्षम नहीं हो सकते हैं), और इसकी आवश्यकता है आपके पास क्लाउड प्रदाता को भुगतान करने के लिए खर्च करने के लिए पैसा है (संभवतः हर बार जब आप कोई रिलीज करते हैं)। यह ज्यादा पैसा नहीं हो सकता है, लेकिन इसका मतलब यह नहीं है कि हर कोई इसका भुगतान करने में सक्षम होगा। यदि हम चाहते हैं कि गो समावेशी और विविध दर्शकों द्वारा प्रयोग करने योग्य हो तो यह एक अच्छा समाधान नहीं लगता है।

/दो सेंट

@SamWhite MeteorJS ने आकाशगंगा के साथ काम किया था, एक क्लाउड प्रदाता में आपकी परियोजना को चलाने के लिए meteor publish कमांड में बनाया गया था। हो सकता है कि मैं उत्पन्न समस्या को गलत समझ रहा हूं, लेकिन इस पर उनका स्विंग ठीक लग रहा था।

@bradfitz क्या होगा यदि एपीआई नहीं बदलता है लेकिन इसके पीछे व्यवहार करता है? यह एक ऐसा मामला है जो SemVer से टूटता है और इसे आयात करने वालों को प्रभावित करता है। आप इस स्थिति का पता कैसे लगाते हैं? मैं पूछता हूं क्योंकि मैंने इसे एक से अधिक अवसरों पर अनुभव किया है।

ओपन सोर्स टूल जिसे कोई भी चला सकता है और $0.57 या $ 1.34 का भुगतान कर सकता है, उन्हें कुछ मिनटों के लिए मेजबानों के एक समूह पर एक अरब परीक्षण चलाने की आवश्यकता होती है।

यह अब लागत को छूता है। यह अमेरिका के एक टेक सिटी के लोगों को अच्छा लग सकता है। अफ्रीका, मध्य अमेरिका, या अन्य स्थानों के लोगों के बारे में जो विश्व स्तर पर वितरित हैं। इस तरह के उपकरण आम तौर पर "तकनीकी अभिजात वर्ग" मंडलियों के बाहर कैसे पहुंच योग्य होते हैं?

और, सार्वजनिक क्लाउड कार्य न करने के सभी मामलों का क्या? ऑन-प्रिमाइसेस (बहुत से लोग इसे करते हैं) या मालिकाना और भरोसे के मुद्दे। यह सामान उनके लिए कैसे काम करेगा? यदि आपके पास इन-हाउस टूल है तो आप सार्वजनिक सेवाओं को लीक नहीं करना चाहेंगे जो आप उपयोग कर रहे हैं। मान लें कि आपको अपना आयात GitHub से मिलता है लेकिन यह सेवा Google में चलती है। क्या लोग अपने निर्भरता वृक्ष को Google को सौंपना ठीक समझते हैं? एक गुच्छा नहीं होगा।

यह किसी भी टैग को पुश करने से पहले, godoc.org को क्वेरी करने और आपके पैकेज के कॉलर्स को खोजने और आपके नए संस्करण के खिलाफ उनके परीक्षण भी पूर्व-रिलीज़ समय पर चलाने में सक्षम हो सकता है। आदि।

आइए इसके उदाहरण के रूप में कुबेरनेट्स को लें। कोई एक पैकेज लिखता है जिसे कुबेरनेट्स में आयात किया जाता है। तो एक उपकरण को इसे प्राप्त करना होगा और सभी परीक्षण चलाना होगा। इसके कुछ हिस्सों को विंडोज़ और पॉज़िक्स पर चलने के लिए डिज़ाइन किया गया है। क्या हम मल्टी-ओएस/मल्टी-आर्क के लिए परीक्षण कर सकते हैं (क्योंकि गो इसे संभालता है)। वह वास्तव में कैसा दिखने वाला है (और लागत)?

--

मुझे लगता है कि इस तरह के उपकरण उपयोगी हो सकते हैं। मेरा मतलब यह नहीं है कि लोग अन्यथा सोचें। मैं यह नहीं देखता कि वे कितने लोगों की समस्या का समाधान करते हैं। वे पर्याप्त व्यावहारिक नहीं हैं या हर सेटअप में फिट नहीं होते हैं।

ऐसा लगता है कि हम ज्ञात और नियंत्रित बाधाओं के साथ गणितीय समस्या को हल करने का प्रयास कर रहे हैं। लेकिन, लोग गड़बड़ हैं इसलिए हमें दोष सहिष्णु समाधान की आवश्यकता है।

आज से पहले @technosophos को उद्धृत करने के लिए:

"संस्करण प्रबंधक वास्तव में संकलक या लिंकर्स या किसी भी चीज़ के लिए उपकरण नहीं हैं ... संस्करण प्रबंधक सहयोग करने वाले लोगों के लिए हैं।"

इसके लायक क्या है, उन्होंने एक से अधिक निर्भरता प्रबंधक लिखे हैं, दूसरों का अध्ययन किया है, और उन लोगों के साथ बात की है जिन्होंने और भी लिखा है।

यह एक प्रस्ताव को स्वीकार करने के लिए गैर-जिम्मेदाराना महसूस करता है, जबकि दृष्टिकोण पर अभी भी मूलभूत चिंताएं बकाया हैं। लेखक और समुदाय डोमेन विशेषज्ञ @sdboyer के बीच सहमति प्रस्ताव को स्वीकार किए जाने से पहले पहुंचने के लिए एक उचित न्यूनतम मानक की तरह लगता है।

बस यहाँ थोड़ा सा ढेर करने के लिए: हमारे पास पैकेजिंग के आसपास एक इतिहास है जो गैर-मानक और उप-इष्टतम ( go get पारिस्थितिकी तंत्र) दोनों है। एक और go get जारी करने की तुलना में केवल एक मानक पैकेज प्रबंधक को छोड़ देना बेहतर होगा जो लोगों को "मानक" टूल के साथ संगतता के नाम पर बुरे व्यवहार की ओर धकेलता है। सार्वजनिक रिलीज के बाद से गो का उपयोग कर रहे किसी व्यक्ति के रूप में मुझे यह वार्तालाप निराशाजनक और निराशाजनक लगता है क्योंकि ऐसा लगता है कि गो टीम के नेतृत्व ने go get (nee goinstall ) से की गई गलतियों से सबक नहीं सीखा है।

इस प्रस्ताव के बारे में उचित और व्यावहारिक समस्याएं हैं जिन्होंने आवाज उठाई है। हमें उन्हें संबोधित करने के प्रस्ताव को केवल यह नहीं कहना चाहिए: "इच्छित के अनुसार काम करना।" अगर हम इसे 1.11 या 1.12 या 1.13 के लिए सही नहीं कर सकते हैं तो हमें तब तक इंतजार करना चाहिए जब तक कि यह सही न हो जाए। यह प्रस्ताव एक ऐसी प्रणाली का प्रस्ताव करता है जो अधिकांश अन्य प्रणालियों की तुलना में काफी अलग व्यवहार करती है और अच्छे तरीके से नहीं।

एमवीएस के पीछे प्रेरक कारण यह प्रतीत होता है कि पारंपरिक दृष्टिकोण एनपी-पूर्ण है। मुझे लगता है कि यह एक बहुत ही खराब प्रेरणा है। एनपी-पूर्ण समस्याओं से निपटने के दौरान मुख्य प्रश्न यह है: "कितनी बार कठिन उदाहरण उत्पन्न होते हैं।" पैकेज प्रबंधन के साथ उत्तर "बहुत ही कम" प्रतीत होता है। हमें केवल समस्या पर एनपी-हार्ड लेबल से बचने के लिए अपूर्ण और अनुपयोगी समस्या फॉर्मूलेशन के लिए समझौता नहीं करना चाहिए।

अधिकांश ठोस बिंदुओं को इस मुद्दे के करीब अन्य लोगों द्वारा आवाज दी गई है ( @sdboyer @peterbourgon @mattfarina आदि...)। मेरी मुख्य शिकायत यह है कि हम इस प्रस्ताव को स्वीकार कर रहे हैं जब इन ठोस बिंदुओं पर पर्याप्त रूप से ध्यान नहीं दिया गया है।

@SamWhited , आप एक काल्पनिक डिज़ाइन की वैकल्पिक विशेषता पर समस्या उठा रहे हैं। काल्पनिक उपयोगकर्ता जो किसी क्लाउड प्रदाता पर भरोसा नहीं करता है या अपने देश के फ़ायरवॉल के अंदर किसी भी क्लाउड प्रदाता का उपयोग नहीं कर सकता है या भुगतान नहीं करना चाहता है, वह हमेशा रात में अपनी मशीन पर परीक्षण (या उसका एक अंश) चला सकता है। या केवल go release हस्ताक्षर जांच का उपयोग करें, जो आपको वहां का 95% मुफ्त में मिलता है।

@mattfarina , @SamWhited , आइए चर्चा को https://github.com/golang/go/issues/25483 पर ले जाएं।

@mattfarina

मुझे इन भाषाओं में समस्याओं का सामना करना पड़ा है और अधिक जहां संकुल SemVer संगतता मुद्दों से टूट गया है। कभी जानबूझकर तो कभी दुर्घटनावश। इन सभी अन्य भाषाओं में मौजूद समस्या से बचने के लिए गो अलग तरीके से क्या करेगा क्योंकि लोग गलत हैं?

यह अभी भी मेरे लिए स्पष्ट नहीं है, क्यों vgo को इन मामलों में dep से भी बदतर प्रदर्शन करने के लिए माना जाता है। इसके विपरीत, मुझे ऐसा लगता है कि vgo सख्ती से बेहतर प्रदर्शन करता है। अपने ब्लॉगपोस्ट में आप एक विशिष्ट समस्या का उल्लेख करते हैं, जो कि vgo मॉडल की विफलता के प्रमाण के रूप में है। हालाँकि, vgo की दुनिया में, दो परिदृश्य हैं कि vgo ने grpc के लिए v1.4.0 का उपयोग करने के लिए क्यों चुना होगा:

1. हेलम के डेवलपर्स ने आवश्यकता के रूप में grpc >= v1.4.0 में go.mod निर्दिष्ट करना चुना। उस स्थिति में, वे बस इस आवश्यकता को वापस ला सकते हैं और इस प्रकार grpc के पिछले संस्करण में वापस रोल कर सकते हैं जो उनके लिए काम करता है।
2. हेलम की निर्भरता के डेवलपर्स ने grpc >= v1.4.0 निर्दिष्ट करना चुना। उस स्थिति में, डिपो ने उसे भी स्थापित कर दिया होगा और यदि हेल्म grpc < v1.4.0 को प्रतिबंधित करके वापस रोल करने का प्रयास करेगा तो विरोधाभासी आवश्यकताओं के कारण dep को क्रॉक करना होगा।

तो मुझे ऐसा लगता है, कि vgo इस समस्या को कम से कम उतना ही हल करता है जितना कि dep करेगा। इस बीच, एक डीपी दुनिया में, एक और विकल्प है:

1. हेल्म की ट्रांजिटिव निर्भरता के लिए grpc >= v1.x.0 की आवश्यकता होती है, कुछ x < 4 के साथ, फिर grpc ने v1.4.0 $ जारी किया और डिप ने बिना पूछे इंस्टॉल पर नए संस्करण का उपयोग करने का निर्णय लिया। . इस मामले में, पतवार टूट जाएगी और एक बगफिक्स रिलीज (जैसा कि आपकी पोस्ट के माध्यम से वर्णित है) करने के लिए मेहनत करने की जरूरत है, शौचालय बनाना। इस बीच, vgo ने नए संस्करण को अनदेखा कर दिया होगा और चीजें ठीक काम करती रहेंगी।

मैं स्पष्ट रूप से कुछ बुनियादी देख रहा हूँ। लेकिन पिछली बार जब मैंने स्लैक पर इस बारे में स्पष्टीकरण मांगा, तो मुझे एक काल्पनिक भविष्य के ब्लॉग पोस्ट के लिए टाल दिया गया। इसलिए मेरी हताशा, क्योंकि मैं वास्तव में यह नहीं समझ पा रहा हूं कि विचार कहां से आ रहा है, किसी भी तरह से लोगों के साथ उनके संस्करणों के शब्दार्थ को तोड़ने की तुलना में अधिक समस्याएं हैं।

स्पष्ट करने के लिए, यह लगभग dep नहीं है। यह इस बात का विश्लेषण है कि एमवीएस (वीजीओ) अन्य सैट-सॉल्वर आधारित पैकेज प्रबंधन समाधानों (डीप शामिल) की तुलना में कैसे व्यवहार करता है।

मैट द्वारा एक और उदाहरण निम्नलिखित बताता है:

आप मॉड्यूल app के डेवलपर हैं और आपकी दो निर्भरताएं हैं:

• grpc [>= 1.8 ]
• helm , जो निम्नलिखित निर्भरता है:
  
  
  
  • grpc [>= 1.0, <1.4] (क्योंकि grpc ने 1.4 में एक महत्वपूर्ण बदलाव पेश किया)।
  
  

अधिकांश लोगों को सकर्मक निर्भरता आवश्यकताओं के बारे में पता नहीं होगा ( helm -> grpc [>= 1.0, <1.4]) क्योंकि इसके लिए जागरूक होने की आवश्यकता होगी कि helm कब टूटता है grpc >= 1.4 का उपयोग करना। मुझे लगता है कि ऐसा कुछ नहीं है जिसके बारे में अधिकांश लोग इसकी परवाह करेंगे या इसकी जांच करने में समय और ऊर्जा खर्च करेंगे।

यदि आप vgo (विशेष रूप से MVS पर निर्भर) का उपयोग कर रहे हैं, तो आप प्राप्त करने जा रहे हैं:

• helm
• grpc [>= 1.8 ]

यह एक अमान्य संयोजन होना चाहिए (चूंकि helm आवश्यकताएं पूरी नहीं होती हैं) और अधिकांश डीपी प्रबंधक आपको यह बताते हुए एक त्रुटि संदेश देंगे कि आपका विरोध है (यह देखते हुए कि helm ने कुछ में अपनी आवश्यकताओं को बताया है प्रारूप)।

यह एमवीएस और वीजीओ की आलोचना का एक महत्वपूर्ण बिंदु है। यह निर्भरताओं को यह बताने की अनुमति नहीं देना चाहता है कि उन्हें पूर्ण-सैट समाधान की आवश्यकता से बचने के लिए किसी विशिष्ट संस्करण के साथ कोई समस्या है। अधिक स्पष्टीकरण के लिए आप एमवीएस आलेख में Theory और Excluding Modules अनुभागों का उल्लेख कर सकते हैं।

एमवीएस इस संभावना को स्वीकार नहीं करना चाहता (या कम से कम इसे वर्तमान मॉड्यूल को निर्देशित करने की क्षमता को प्रतिबंधित करना चाहता है) इस धारणा के तहत कि सेमवर का हमेशा सम्मान किया जाता है और इसलिए इसकी आवश्यकता नहीं होती है, जो व्यावहारिक रूप से हमेशा ऐसा नहीं होता है। मैं आपके लेख को पश्चगामी संगतता के बारे में यह दिखाने के लिए संदर्भित करता हूं कि पिछड़े संगतता का पालन करना कठिन क्यों है और जब वीगो तरीके से मजबूर किया जाता है तो यह अव्यावहारिक है।

एमवीएस समाधान मॉड्यूल डेवलपर से यह निर्दिष्ट करने के लिए है कि इन असंगतताओं के बारे में निर्भरता के लेखकों द्वारा साझा किए जा सकने वाले ज्ञान को अनदेखा करते हुए कौन से संस्करणों को बाहर करना है। इस प्रकार डेवलपर को जिम्मेदारी हस्तांतरित करने के लिए जटिल तर्क को जानने और करने के लिए कि अधिकांश डीईपी प्रबंधक यह पता लगाने के लिए जाते हैं कि कौन से संस्करण एक दूसरे के साथ संगत हैं (यानी, एक एसएटी हल)।

जब तक लोग जादुई रूप से SemVer के अनुरूप होना शुरू नहीं करते हैं, मैं कल्पना करता हूं कि एक सनकी अभ्यास में बदलने के लिए vgo का उपयोग करते समय एक निर्भरता स्थापित करना, जहां एक मॉड्यूल आयात करने के बाद आपको उन संस्करणों की सूची की प्रतिलिपि बनाने के लिए एक README फ़ाइल की जांच करनी होगी जो शामिल करने के लिए संगत नहीं हैं उन्हें आपकी go.mod फ़ाइल में। ध्यान रखें कि exclude कथन वर्तमान में केवल एक संस्करण लेता है।

@मेरोवियस

@mattfarina के ब्लॉग पोस्ट में, वे हेलम को जीआरपीसी v1.4.0 में जानबूझकर अपग्रेड करने का वर्णन करते हैं, जो कि go.mod को अपडेट करने के बराबर है। सवाल यह नहीं है कि डीपी या वीजीओ इस समस्या से कैसे बचते हैं, बल्कि यह है कि वे पुस्तकालय के लेखक को इससे कैसे उबरने में सक्षम बनाते हैं। डिपो के मामले में, वे एक पैच जारी कर सकते हैं जो grpc<v1.4.0 बाधा का विज्ञापन करता है। उन उपयोगकर्ताओं के लिए जिनके पास जीआरपीसी पर कोई अन्य निर्भरता नहीं है, यह सिर्फ काम करेगा। यदि कोई उपयोगकर्ता पहले से ही हेलम के नवीनतम संस्करण में अपडेट हो चुका है और grpc>=v1.4.0 पर एक और निर्भरता रखता है, तो यह बाधा उनके निर्माण को विफल कर देगी; आदर्श नहीं है, लेकिन सूक्ष्म रूप से टूटे हुए रनटाइम व्यवहार से बेहतर है।

vgo के साथ, क्या हेल्म अनुरक्षकों के पास कोई समकक्ष विकल्प उपलब्ध है? यदि किसी उपयोगकर्ता ने किसी भी कारण से जीआरपीसी को v1.4.0 में अपग्रेड किया है, तो एमवीएस हमेशा [email protected] चुनेंगे , हेल्म टूट जाएगा, और हेल्म अनुरक्षक इसके बारे में कुछ भी नहीं कर सकते हैं (बदले हुए व्यवहार के लिए समायोजन के बिना, जो अक्सर होता है बहुत समय लगेगा)। मैं @mattfarina के लिए बात नहीं कर सकता, लेकिन इस तरह मैंने उठाई गई चिंता को पढ़ा और यह एक है जिसे मैं साझा करता हूं। dep और इसी तरह की प्रणालियों के साथ, मध्यवर्ती पुस्तकालय ऊपरी सीमा बाधाओं के साथ संगतता उल्लंघनों से बचाव कर सकते हैं (या अधिक बार, इससे उबर सकते हैं)।

@ibrasho @mattfarina

ऐसा लगता है कि GopherconSG टॉक में Russ के उदाहरण में से एक बहुत समान (शायद समान?) परिदृश्य को कवर करता है।

उपरोक्त पोस्ट में, आप कहते हैं कि पतवार "grpc [>= 1.0, <1.4]" पर निर्भर करता है। लेकिन यह कड़ाई से सटीक नहीं है। मुझे लगता है कि आपका मतलब यह है कि पतवार का कुछ विशिष्ट संस्करण "grpc [> = 1.0, <1.4]" पर निर्भर करता है। मान लें कि पतवार का संस्करण 2.1.3 है; संभवतः पतवार का यह संस्करण जीआरपीसी 1.4 के बाद जारी किया गया था (अन्यथा यह खुद को जीआरपीसी 1.4 के साथ असंगत चिह्नित करने के लिए नहीं जाना जाता)। उस वार्ता में Russ की बात यह है कि पतवार के पूर्व संस्करण (2.1.2 कहते हैं), संभवतः (अभी तक) खुद को जीआरपीसी 1.4 के साथ असंगत के रूप में चिह्नित नहीं किया होगा।

दूसरे शब्दों में, एक संतोषजनक असाइनमेंट (डिप के अनुसार) हेलम = 2.1.2, जीआरपीसी = 1.8 होता। Dep बिना किसी त्रुटि के इस संस्करण असाइनमेंट को सही ढंग से चुन सकता है, क्योंकि यह दिए गए संस्करणों में सभी बाधाओं को पूरा करता है।

@बालासंजय

हेल्म का संस्करण मूल रूप से उदाहरण को नहीं बदलता है। हेल्म@2.1.2 [email protected] पर निर्भरता की घोषणा कर सकता है और हेलम का उपयोगकर्ता सीधे या किसी अन्य पैकेज के माध्यम से [email protected] पर निर्भरता हो सकता है। इस परिदृश्य में, MVS विफल रहता है और [email protected] और [email protected] स्थापित करता है। इसके अलावा, यह उदाहरण मानता है कि समस्या का खुलासा होने से पहले उपयोगकर्ता जानबूझकर [email protected] (और इस प्रकार [email protected]) और शायद [email protected] , [email protected] , आदि को भी अपडेट करता है।

एमवीएस जानबूझकर अपने सैद्धांतिक लक्ष्यों को प्राप्त करने के लिए मध्यवर्ती निर्भरताओं से बहिष्करण को अस्वीकार करता है:

नकारात्मक प्रभाव (एक्स → ¬ वाई, समकक्ष ¬ एक्स ∨ वाई: यदि एक्स स्थापित है, तो वाई स्थापित नहीं होना चाहिए) जोड़ा नहीं जा सकता ...

इस उदाहरण के लिए, हमें व्यक्त करने की आवश्यकता है, यदि X= helm>= 2.1.3 स्थापित है तो Y= grpc>=1.4.0 स्थापित नहीं होना चाहिए, जिसे हम डिज़ाइन द्वारा नहीं कर सकते।

वास्तव में, केवल शीर्ष-स्तरीय पैकेज (टूटने को ठीक करके) और निचले स्तर के उपयोगकर्ताओं (मैन्युअल रूप से बहिष्कृत जोड़कर) के पास संगतता नियम टूटने पर कोई सहारा होता है। हेल्म जैसे इंटरमीडिएट को किसी भी निर्भरता के भविष्य के सभी संस्करणों के साथ काम करना चाहिए, जो मेरे लिए, ऐसे पुस्तकालयों के मूल्य प्रस्ताव को काफी कम कर देता है।

शायद यह grpc और aws-sdk-go जैसे भारी उपयोग वाले पुस्तकालयों में बेहतर व्यवहार को प्रोत्साहित करेगा क्योंकि किसी भी टूट-फूट का पूरा खामियाजा सभी पक्षों को महसूस होगा और इसके आसपास काम करना अधिक कठिन होगा। हालाँकि, यह हमेशा इतना आसान नहीं होता है। क्या होगा यदि "टूटना" वास्तव में टूटना नहीं है, लेकिन व्यवहार में एक वैध परिवर्तन है जिसके कुछ उपयोगकर्ता के लिए अनपेक्षित परिणाम हैं, लेकिन दूसरों के लिए सहायक है? उस प्रकार की बात असामान्य नहीं है और अपस्ट्रीम लेखक उस परिदृश्य में बदलाव को वापस लाने में हिचकिचाएंगे।

मुझे नहीं लगता कि मैं लगभग Russ जितना स्पष्ट था। मुझे दोबारा प्रयास करने दें।

शुरुआत में डिपो की स्थिति कुछ इस तरह दिखती है।
पतवार 2.1.2: जीआरपीसी>= 1.0

फिर, जीआरपीसी 1.4 जारी किया जाता है। हेल्म के डेवलपर्स का एहसास है कि एक असंगति है, और इसलिए हेल्म के एक नए संस्करण को आगे बढ़ाएं:
पतवार 2.1.3: जीआरपीसी>= 1.0, <1.4

मैं एक नया ऐप शुरू करता हूं जो हेल्म और जीआरपीसी की कुछ नई सुविधा (तर्क के लिए) पर निर्भर करता है। मैं निम्नलिखित डीपी सूचीबद्ध करता हूं:
पतवार>= 2.0.0
जीआरपीसी>= 1.4

उपरोक्त दावा यह था कि डीपी अंतर्निहित संघर्ष को नोटिस करेगा, और एक त्रुटि की रिपोर्ट करेगा।

लेकिन रस ने बताया कि यह सच नहीं है, क्योंकि एक संस्करण असाइनमेंट है जिसमें कोई विरोध नहीं है। विशेष रूप से, डीपी हेल्म 2.1.2 और जीआरपीसी 1.4 का उपयोग करना चुन सकता है। डिप के अनुसार, यह एक वैध असाइनमेंट है, क्योंकि हेल्म 2.1। 3 वह है जो जीआरपीसी 1.4 के साथ असंगत है, जबकि 2.1। 2 सभी जीआरपीसी>= 1.0 के साथ संगत है।

दूसरे शब्दों में, dep _validly_ एक विरोध को "ठीक" करने के लिए चुन सकता है, एक ऐसे संस्करण में डाउनग्रेड करके जिसने अभी तक विरोध दर्ज नहीं किया था। यदि आपके पास अपरिवर्तनीय संस्करण हैं, तो यह अपरिहार्य लगता है। इसलिए, ऐसा लगता है कि विभाग https://codeengineered.com/blog/2018/golang-vgo-broken-dep-tree/ को भी गलत तरीके से हैंडल करेगा।

@balasanjay ज़रूर, लेकिन अंततः हेल्म 2.2.0 को एक नई नई सुविधा के साथ रखता है जिसे आप चाहते हैं, और आप अपग्रेड करने का प्रयास करते हैं, और फिर समस्या आती है।

(मैं सावधानीपूर्वक आशावादी हूं कि यह ठीक काम करेगा यदि वीजीओ के पास लोगों को जागरूक करने के लिए एक अच्छी तरह से डिज़ाइन किया गया यूएक्स है कि उनके एमवीएस परिणाम में इस फॉर्म का "संघर्ष" है। "अच्छी तरह से डिजाइन" से मेरा मतलब है कि यह लोगों को इससे निपटने के लिए प्रोत्साहित करता है हर समय बहुत सारी चेतावनियों के साथ ठीक होने की बजाय समस्या।)

मैं निश्चित रूप से सहमत हूं कि ऐसी स्थितियां हैं जहां डीपी एक संघर्ष का पता लगाएगा, लेकिन सिर्फ यह स्पष्ट करना चाहता था कि यह उस ब्लॉग पोस्ट में प्रस्तुत किया गया _not_ है (या कम से कम, वर्तमान में प्रस्तुत संस्करण आवश्यकताओं के साथ नहीं)।

और एफडब्ल्यूआईडब्ल्यू, मुझे लगता है कि सुरक्षा की प्रभावशीलता पर सवाल उठाना उचित है यदि यह एक संघर्ष के अपेक्षाकृत सरल उदाहरण पर टूट जाता है।

रिकॉर्ड के लिए, मैंने रसेल के उदाहरण को ट्रैक किया (यह एक प्रभावशाली डिग्री के लिए काफी समान है): https://youtu.be/F8nrpe0XWRg?t=31m28s

पुन: न्यूनतम संस्करण चयन, मुझे यह पता लगाने में परेशानी हो रही है कि निम्न स्थिति को कैसे हल किया जाए:

maitenence मोड में एक लोकप्रिय पुस्तकालय की कल्पना करें, उदाहरण के लिए v1.2.3 बिना किसी बदलाव के एक साल से अधिक समय से बाहर है। कई अन्य पुस्तकालय इस पर निर्भर हैं।
एक डेवलपर साथ आता है और v1.2.3.1 में बनाने के लिए एक गति अनुकूलन का एहसास करता है। यह बिना किसी एपीआई परिवर्तन के पुस्तकालय के मुख्य कार्य को 10x तक गति देता है! इसे v1.3.0 के रूप में जारी किया गया है। अगले वर्ष के लिए इस पैकेज में कोई और बग नहीं पाए गए।

आश्रितों को यह अद्यतन कैसे प्राप्त होता है? वे v1.2.3 के साथ काम कर सकते हैं, लेकिन v1.3.0 जाहिर तौर पर बेहतर है।

@dournimator

आश्रितों को यह अद्यतन कैसे प्राप्त होता है?

प्रत्येक एप्लिकेशन को उपयोग करने के लिए न्यूनतम संस्करण के रूप में 1.3.0 सेट करना होगा।

अच्छा, आज क्या मूर्खता का दिन है! मैं

यह प्रस्ताव दो महीने से अधिक समय से सक्रिय चर्चाओं के साथ खुला है

यह समस्या वर्षों से खुली हुई है, और इस सब के लिए निर्धारित समयरेखा आरएससी काफी कृत्रिम रूप से कम थी, सभी बातों पर विचार किया गया।

इस प्रस्ताव पर दो आपत्तियां आई हैं जिनके बारे में हमें लगता है कि हमें इस पर बात करनी चाहिए:

1. प्रस्ताव उन सभी संभावित परिदृश्यों के लिए तकनीकी समाधान प्रदान करने में विफल रहता है जो असंगति से उत्पन्न हो सकते हैं।

यदि यह उन पदों के लिए एक संकेत है जो मैंने रस को रेखांकित किया है, तो यह एक भ्रामक कैरिकेचर है। इस विषय पर अपने विचार रखने में मुझे इतना समय क्यों लगा, इसका एक कारण यह है कि भ्रामक तर्कों और बयानों का बार-बार उपयोग... स्पष्ट रूप से, अस्थिर करने वाला है।

वस्तुतः कोई नहीं सोचता कि सभी संभावित परिदृश्यों को कवर किया जा सकता है। समस्या यह है, और हमेशा रही है, कि एमवीएस केवल एक _illusory_ समस्या को हल करता है (SAT से बचना), इसके स्थान पर _new_ समस्याएं पैदा करता है जो व्यवहार में बहुत अधिक मायने रखता है, और एक मध्यवर्ती परत के रूप में प्रभावी ढंग से कार्य नहीं कर सकता है जिस पर हम उचित रूप से काम कर सकते हैं।

ये उनके अवलोकन में सटीक हैं लेकिन इरादे से काम कर रहे हैं। कोड के लेखकों और उपयोगकर्ताओं को पुस्तकालयों का उपयोग करने और जारी करने के आसपास अपनी कुछ प्रथाओं को बदलना होगा, जैसे डेवलपर्स ने गो के अन्य विवरणों को अनुकूलित किया है, जैसे कि gofmt चलाना।

चल रहे gofmt के साथ तुलना करके यहां प्रस्तावित परिवर्तनों की डिग्री को छोटा करके कुछ भी मदद नहीं की जाती है - संभवत: गो डेवलपर्स के रूप में हम सबसे अधिक नासमझ गतिविधि करते हैं।

जैसा कि रस ने गोफरकॉन सिंगापुर में अपनी हालिया बातचीत में बताया, असंगति का एकमात्र स्थायी समाधान असंगति को ठीक करने और गो पैकेज पारिस्थितिकी तंत्र को बनाए रखने के लिए मिलकर काम करना है। vgo या dep जैसे टूल में अस्थायी वर्कअराउंड केवल डेवलपर्स को वास्तविक समस्या को हल करने के लिए समय देने के लिए पर्याप्त समय तक काम करने की आवश्यकता होती है, और vgo इस काम को अच्छी तरह से करता है।

आइए स्पष्ट करें - _समुदाय_ क्या मायने रखता है। हम। सॉफ्टवेयर पारिस्थितिकी तंत्र का उत्पादन करने वाले लोग। हम ऐसे उपकरण बनाकर बेहतर पारिस्थितिकी तंत्र प्राप्त करते हैं जो उपयोगी सहयोग पर हमारे सीमित टोकन खर्च करने में हमारी सहायता करते हैं - न कि भंगुर उपकरण बनाकर जो हमें पहली जगह में भाग लेने के लिए दंडित करते हैं।

@मेरोवियस :

मुझे एक काल्पनिक भविष्य के ब्लॉग पोस्ट के लिए टाल दिया गया। इसलिए मेरी हताशा, क्योंकि मैं वास्तव में यह नहीं समझ पा रहा हूं कि विचार कहां से आ रहा है, किसी भी तरह से लोगों के साथ उनके संस्करणों के शब्दार्थ को तोड़ने की तुलना में अधिक समस्याएं हैं।

इन सभी तर्कों को एक साथ मिलाने में समय लगता है, और यह मेरा दिन का काम नहीं है। मैं आज रात समाप्त करने का लक्ष्य बना रहा था, लेकिन मैं अभी भी अपने अंतिम संपादन पास पर हूं। कल सुबह...? पत्थर में कुछ भी सेट नहीं है!

समस्या यह है, और हमेशा रही है, कि एमवीएस केवल एक भ्रामक समस्या (सैट से परहेज) को हल करता है, ...

सम्मान से, आईएमएचओ एसएटी समाधान एक गैर-समाधान है, इसलिए मेरे लिए, एमवीएस एक बहुत ही वास्तविक समस्या हल करता है।

आईएमएचओ एसएटी समाधान एक गैर-समाधान है, इसलिए मेरे लिए, एमवीएस एक बहुत ही वास्तविक समस्या हल करता है।

यदि संभव हो तो इसके पीछे के तर्क को समझना चाहेंगे?

यह समस्या वर्षों से खुली हुई है, और इस सब के लिए निर्धारित समयरेखा आरएससी काफी कृत्रिम रूप से कम थी, सभी बातों पर विचार किया गया।

मुझे यहां दो स्पष्ट रूप से परस्पर विरोधी विचार दिखाई दे रहे हैं। सर्वेक्षणों ने बार-बार दिखाया है कि निर्भरता प्रबंधन को जल्द से जल्द समाधान की आवश्यकता है। फिर भी किसी प्रस्ताव की समीक्षा और अनुमोदन के लिए छह महीने की समय-सीमा पर्याप्त नहीं है।

मैं समझता हूं कि हमें लागू किए जाने वाले पहले समाधान को नहीं चुनना चाहिए। लेकिन समय कारकों में से एक है। vgo के प्रति-प्रस्ताव को अभी तक अच्छी तरह से परिभाषित नहीं किया गया है, और इसके अस्तित्व में आने में कई साल लग सकते हैं। मैं किसी भी दिन गो 1.14 में एक सुपर-भयानक सैट-आधारित समाधान पर गो 1.11 में vgo चुनूंगा।

यह भी माना जा रहा है कि पत्थर में कौन सा वीगो उपकरण स्थापित है। हम सभी जानते हैं कि 1.12 और 1.13 विंडो के दौरान vgo काफी बदल सकता है।

यदि संभव हो तो इसके पीछे के तर्क को समझना चाहेंगे?

यह वही तर्क है जो पीसीआरई को गो के रेगेक्सपी को प्राथमिकता देने के पीछे है, यानी। द्विघात/घातीय सबसे खराब स्थिति जटिलता वाले एल्गोरिदम पर निर्भर होने के लिए किसी प्रोग्राम को अनुमति नहीं देना।

हमें यह ध्यान रखना चाहिए कि vgo बस go get की जगह लेगा और कुछ नहीं। हमें vgo go get करनी चाहिए न कि vgo की किसी ऐसी चीज से जो मौजूद नहीं है। "बदतर बेहतर है"! आइए अब कार्यान्वयन विवरण पर ध्यान दें।

एफडब्ल्यूआईडब्ल्यू, एक पूर्ण एसएटी सॉल्वर के बिना ऊपरी सीमाओं को पेश करना आईएमओ पूरी तरह से संभव है - जेनरेट किए गए समाधान को इष्टतम होना या मौजूदा समाधान मिलने की गारंटी देना संभव नहीं है। यदि आवश्यक हो, तो आप कर सकते हैं

1. ऊपरी सीमा निर्दिष्ट करना संभव बनाएं
2. एमवीएस के माध्यम से हल करते समय उन्हें अनदेखा करें
3. सभी सीमाओं के खिलाफ पाए गए समाधान की जांच करें और अगर यह फिट नहीं होता है (यह महत्वपूर्ण अंतर है: पारंपरिक दृष्टिकोण इसके बजाय एक अलग समाधान खोजने की कोशिश करेंगे)

इसका मतलब यह होगा कि आपको एमवीएस (पैथोलॉजिकल रनटाइम के बिना एक साधारण एल्गोरिदम) के फायदे मिलते हैं, जो असंगतताओं को चिह्नित करने और उन्हें स्थिर रूप से पहचानने की संभावना को संरक्षित करते हैं लेकिन यदि कोई मौजूद है तो आप हमेशा समाधान खोजने की गारंटी छोड़ रहे हैं। हालांकि यह तर्क दिया जा सकता है कि जो समाधान आप पाएंगे , वह वास्तव में वैसे भी कोई समाधान नहीं है, क्योंकि असंगति अभी भी है, एल्गोरिथ्म के लिए बस अज्ञात है।

तो कम से कम मेरे लिए, ऐसा लगता है कि एमवीएस तक ऊपरी सीमा प्राप्त करने के लिए किसी तरह से फिर से निकालना संभव है। मैं अभी भी आश्वस्त नहीं हूं कि वास्तव में इसकी आवश्यकता है, लेकिन क्या ऐसा होना चाहिए, इसे बाद में हमेशा जोड़ा जा सकता है। "एमवीएस मौलिक रूप से अनुपयुक्त है" दावे को समस्याग्रस्त बनाना। लेकिन मैं अभी भी समस्या को गलत समझ सकता हूं। और इसे बेहतर ढंग से दर्शाने वाला एक विफलता परिदृश्य हो सकता है?

@sdboyer कोई चिंता नहीं। जैसा कि मैंने कहा, मैं पूरी तरह से समझता हूं कि यह आपका दिन का काम नहीं है और आप भाग लेने के लिए जो समय ले रहे हैं उसकी मैं सराहना करता हूं। यह अभी भी एक व्यावहारिक मुद्दा है "अगर हम तर्कों को नहीं जानते हैं, तो हम उनके बारे में बात नहीं कर सकते"। मैं कल्पना कर सकता हूं कि आप पूरी स्थिति से उतने ही निराश हैं जितना कि मैं :)

यह वही तर्क है जो पीसीआरई को गो के रेगेक्सपी को प्राथमिकता देने के पीछे है, यानी। द्विघात/घातीय सबसे खराब स्थिति जटिलता वाले एल्गोरिदम पर निर्भर होने के लिए किसी प्रोग्राम को अनुमति नहीं देना।

@cznic मेरी राय है कि निर्भरता प्रबंधन केवल एक तकनीकी समस्या नहीं है, यह सामाजिक बाधाओं और विचारों से जुड़ा हुआ है। इसलिए मुझे यकीन नहीं है कि इसकी नियमित अभिव्यक्तियों (एक विशुद्ध रूप से तकनीकी कार्यान्वयन समस्या) से तुलना करना और मूल रूप से समय की जटिलता के आधार पर एक एल्गोरिथ्म का पक्ष लेना एक उचित दृष्टिकोण है।

मैं देखता हूं कि कुछ लोग एमवीएस का पक्ष लेते हैं क्योंकि यह तर्क करना आसान और आसान है और अगर यह समस्या के अन्य पहलुओं को हल करता है तो यह समझने योग्य विचार है।

मैं सोच रहा था कि क्या लोगों के पास एसएटी-आधारित एल्गोरिदम पर इसे पसंद करने के अन्य कारण हैं।

मैं सोच रहा था कि क्या लोगों के पास एसएटी-आधारित एल्गोरिदम पर इसे पसंद करने के अन्य कारण हैं।

@ibrasho MVS को लॉक फ़ाइल की आवश्यकता नहीं है।

मैं सोच रहा था कि क्या लोगों के पास एसएटी-आधारित एल्गोरिदम पर इसे पसंद करने के अन्य कारण हैं।

व्यक्तिगत रूप से, मेरे कारण हैं

1. यह लॉक-फाइल को एकीकृत करता है और एक फाइल में प्रकट होता है, जिसे बड़े पैमाने पर कंप्यूटर-संपादित किया जा सकता है। मतलब कम शोर जबकि अभी भी प्रतिलिपि प्रस्तुत करने योग्य (या "उच्च-निष्ठा") सामान्य मामले में बनता है। AFAICT यह एमवीएस के लिए कुछ अनोखा है। जैसा कि अन्य पैकेज प्रबंधकों के साथ मेरी मुख्य कुंठाओं में से एक है मैनिफेस्ट फाइलों को संपादित करने का परिश्रम, यह मेरे लिए बहुत बड़ा है।
2. धीरे-धीरे मरम्मत आसान/संभव हो जाएगी। चूंकि मैं वितरित विकास समस्या को हल करने के लिए इस दृष्टिकोण में दृढ़ विश्वास रखता हूं, यह मेरे लिए भी महत्वपूर्ण है।
3. यह अधिकांश पुस्तकालयों के लिए पारिस्थितिकी तंत्र को सामूहिक रूप से HEAD के करीब रहने में मदद कर सकता है। यह काफी हद तक अटकलबाजी है और उपलब्ध टूलिंग पर कुछ हद तक निर्भर करता है। लेकिन अगर "सब कुछ नवीनतम संस्करण में खींचें" पर्याप्त रूप से सरल है, तो यह उस ताल को बढ़ा सकता है जिसके साथ उत्पादन में पुस्तकालयों के नए संस्करणों का एक दूसरे के खिलाफ परीक्षण किया जाता है।
4. यह अन्य दृष्टिकोणों, AFAICT के वांछनीय गुणों को संरक्षित या पार करते हुए यह सब प्राप्त करता है। उन्नयन केवल वांछित होने पर ही होता है। और बाइनरी पैकेज का निर्माण जारी रहेगा, भले ही उनकी कुछ निर्भरता का निर्माण एक नए संस्करण में टूट जाए, जिससे लेखक को एक फिक्स पर काम करने का समय मिल सके।

विशेष रूप से यह अंतिम भाग विडंबनापूर्ण है। क्योंकि इस सटीक गुणवत्ता को @sdboyer की अंतिम पोस्ट में अत्यंत महत्वपूर्ण के रूप में चित्रित किया गया था - लेकिन इस बिंदु पर, मैं अभी भी मानता हूं कि पारंपरिक दृष्टिकोणों की तुलना में इस संबंध में vgo सख्ती से बेहतर है।

@मेरोवियस
"यह लॉक-फाइल को एकीकृत करता है और एक फाइल में प्रकट होता है"

• यह पूरी तरह से सच नहीं है क्योंकि मैनिफेस्ट आपकी सभी फाइलों में प्रभावी रूप से बिखरे हुए हैं। आयात विवरण प्रभावी रूप से प्रकट के रूप में कार्य करते हैं।

@docmerlin जब मैंने "मैनिफेस्ट" कहा, तो मेरा मतलब उन सभी मॉड्यूल को सूचीबद्ध करने वाली फ़ाइल से था, जिन पर आप उनके उपयुक्त संस्करणों के आधार पर हैं (विशेष रूप से, इसमें आयात विवरणों की तुलना में सख्ती से अधिक जानकारी है, अन्यथा आपको इसकी आवश्यकता नहीं होगी)। vgo के मामले में यह go.mod होगा, dep के मामले में यह Gopkg.toml होगा। आप यह भी कह सकते हैं कि निर्भरता सॉल्वर के लिए कॉन्फ़िगरेशन फ़ाइल। यदि आप एक अलग शब्द को अधिक उपयुक्त मानते हैं, तो बेझिझक इसे मैनिफेस्ट के लिए स्थानापन्न करें, जब आप मेरी टिप्पणी पढ़ रहे हों।

ध्यान दें, कि सभी निर्भरताओं को सूचीबद्ध करने वाली फ़ाइल और प्रति फ़ाइल स्पष्ट आयात (जो निर्भरताओं का संभावित रूप से सख्त सबसेट हैं) की सूची दोनों के लिए यह बहुत सामान्य है। विशेष रूप से, सभी गो निर्भरता प्रबंधक जिनके बारे में मुझे पता है, वे ऐसा करते हैं। अन्य दृष्टिकोण भी लॉक-फाइल का उपयोग करते हैं जो प्रतिलिपि प्रस्तुत करने योग्य निर्माण सुनिश्चित करने के लिए उपयोग करने के लिए विशिष्ट, सटीक संस्करणों का वर्णन करता है। और जिस एमवीएस की मैं बात कर रहा था, उसकी विशिष्ट विशेषता यह है कि इस फ़ाइल की आवश्यकता नहीं है, क्योंकि यह विशिष्ट रूप से मेनिफेस्ट/निर्भरता-सॉल्वर-कॉन्फ़िगरेशन/go.mod फ़ाइल से प्राप्त की जा सकती है।

(मेरे व्यक्तिगत खाते से हटा दिया गया + पुनः पोस्ट किया गया)

@cznic अलगाव में एक एसएटी-आधारित दृष्टिकोण बनाम एमवीसी की जटिलता वर्गों पर ध्यान केंद्रित करने का कोई मतलब नहीं है (जैसा कि मुझे लगता है कि @sdboyer कहीं लिखता है - हम इसके बारे में बात करते हुए पकड़े जाते हैं क्योंकि यह उन कुछ चीजों में से एक है जो हम कर सकते हैं नाम / पहचान)।

@bradfitz के सुझाव #25483 में vgo के साथ कुछ चिंताओं को दूर करने के लिए (जो मुझे लगता है कि एक प्रारंभिक पागल लेकिन शायद महान व्यावहारिक समाधान है) में रिलीज से पहले आपके एपीआई के मनमानी उपयोगकर्ताओं से परीक्षण चलाना शामिल है। यह सामान्य रूप से एक एनपी-पूर्ण समस्या है, लेकिन व्यवहार में यह एक अच्छा समाधान हो सकता है (ठीक जीपीएस 2 की तरह)।

तो एक तरफ हमारे पास एसएटी-आधारित पैकेज प्रबंधन एल्गोरिदम है, और दूसरी तरफ हमारे पास एनएल में एक एल्गोरिदम है जो हमें बाद में एनपी-पूर्ण कार्य करने के लिए मजबूर करता है (या टाइम आउट, जो कि कोई भी व्यावहारिक एसएटी सॉल्वर करेगा प्रतिकूल लॉक फ़ाइलों के लिए)।

अलगाव में एमवीसी बनाम एसएटी-आधारित दृष्टिकोण की जटिलता वर्गों पर ध्यान केंद्रित करने का कोई मतलब नहीं है ...

मुझे यकीन नहीं है कि 'फोकस' शब्द कहां से आया है। यह सिर्फ इतना है कि यदि दो एल्गोरिदम उपलब्ध हैं, तो सबसे खराब स्थिति द्विघात या बदतर है और दूसरा रैखिक ओडी बेहतर है, मैंने बाद को चुना और पूर्व से बचें। मैं इसे सिद्धांत कहूंगा, फोकस नहीं।

... #25483 में सुझाव vgo के साथ कुछ चिंताओं को दूर करने के लिए ...

ऐसा लगता है कि मुद्दा #25483 vgo से संबंधित नहीं है। टाइपो?

यह सिर्फ इतना है कि अगर दो एल्गोरिदम उपलब्ध हैं, तो सबसे खराब स्थिति द्विघात या बदतर है और दूसरी रैखिक या बेहतर है, मैंने बाद वाले को चुना और पूर्व से बचें।

@cznic निश्चित रूप से, आमतौर पर यदि दो एल्गोरिदम आपको वही परिणाम देते हैं जो आप कम जटिलता वाले चाहते हैं (हालांकि यह हमेशा इतना कट और सूखा नहीं होता है - पायथन छोटे इनपुट के लिए सम्मिलन प्रकार का उपयोग करता है क्योंकि बदतर जटिलता सीमा होने के बावजूद, यह बेहतर है स्थिरांक + एक बिंदु तक रनटाइम)।

इस मामले में (एमवीएस बनाम एसएटी-आधारित एल्गोरिदम), परिणाम उद्देश्य पर भिन्न होते हैं और व्यापक परिणाम होते हैं। मैं सुझाव दे रहा हूं कि इस वजह से आप केवल एल्गोरिथम जटिलता की तुलना नहीं कर सकते हैं, आपको उनके व्यापक प्रभावों पर विचार करने की आवश्यकता है।

ऐसा लगता है कि मुद्दा #25483 vgo . से संबंधित नहीं है

उस अंक की पहली पंक्ति इस अंक में ब्रैड की टिप्पणी की एक कड़ी है: https://github.com/golang/go/issues/24301#issuecomment -390788506। हालांकि यह उपकरण वीजीओ के बाहर उपयोगी होगा, ऐसा लगता है कि एमवीएस (मेरी राय/समझ में) के कुछ डाउनसाइड्स को कम करने के लिए इसे बड़े पैमाने पर माना जा रहा है।

ओह, इतनी सारी टिप्पणियाँ। मैं मदद करने के लिए कुछ विवरण और इतिहास जोड़ने की कोशिश करूंगा।

कुछ साल पहले कई अलग-अलग निर्भरता प्रबंधन समाधान थे (उदाहरण के लिए, गोडेप, ग्लाइड, आदि)। आगे का रास्ता निकालने के लिए कुछ चीजें हुईं:

1. एक समिति में निवेशित और जानकार लोगों का समूह एक साथ आया । ध्यान दें, Google में गो टीम का एक सदस्य इस समूह का हिस्सा था।
2. निर्भरता प्रबंधकों को लिखने वाले या उनके बारे में जानकारी रखने वाले लोगों के दूसरे समूह ने इस पहले समूह का समर्थन किया।
3. मौजूदा उपकरणों (गो और गो के बाहर) पर जरूरतों और विचारों पर समुदाय का एक सर्वेक्षण किया गया था । ध्यान दें, कुछ परिणाम केवल समिति की नजर के लिए निजी थे।
4. उत्पादन के लिए गो का उपयोग करने वाली कंपनियों का साक्षात्कार लिया गया ताकि उनकी जरूरतों के बारे में विवरण प्राप्त किया जा सके। इसका विवरण सार्वजनिक नहीं है इसलिए लोग खुलकर बोल सकते हैं।

सर्वेक्षण और साक्षात्कार डेटा सभी को समिति में वापस फीड किया गया था। डेटा को देखने और उस पर बहस करने के बाद उन्होंने फैसला किया कि हमें कुछ विशेषताओं के साथ एक समाधान की आवश्यकता है और एक युक्ति बनाई। उसके बाद डेप पर विकास उन जरूरतों को पूरा करने लगा।

पिछले साल गोफरकॉन में एक योगदानकर्ता शिखर सम्मेलन था जिसमें वे लोग शामिल थे जिन्होंने इसके बारे में बात करते हुए निर्भरता प्रबंधन में निवेश किया था। उन बातचीत के अंत के करीब, रस मेज पर आया और कुछ ऐसा कहा, मैं बेहतर कर सकता हूं अगर मैं अपने आप से निकल जाऊं और कुछ बनाऊं। उसने ऐसा किया और vgo के साथ आया। यह समुदाय से अलग किया गया था।

क्या वीजीओ सर्वेक्षण और साक्षात्कार में व्यक्त लोगों की जरूरतों को पूरा करता है? मैं Russ से जो कुछ भी इकट्ठा करता हूं, उसने परिणाम नहीं पढ़ा है, लेकिन उसने इस प्रक्रिया की आलोचना की है। मैपिंग करने वाले किसी के लायक हो सकता है।

ओह, शिखर सम्मेलन में रस ने एक कारण साझा किया, उस समय, उन्हें सैट सॉल्वर पसंद नहीं था। वह कोड की कम पंक्तियों के साथ एक समाधान चाहता था क्योंकि वह नहीं चाहता था कि Google पर गो टीम इतना कोड बनाए रखने के लिए हुक पर हो। मुझे याद है कि विशेष रूप से क्योंकि मैंने अंतर की बेहतर तस्वीर प्राप्त करने के लिए उसके बाद डिपो, ग्लाइड और अन्य उपकरणों के बीच कुछ एलओसी तुलना की थी।

गो एक Google स्वामित्व वाली और चलाने वाली परियोजना है। यदि समस्या संसाधनों में से एक है, तो क्या गो एक नींव के अधीन होना चाहिए और अन्य संगठनों के लोग इसके स्वामित्व में शामिल हो जाते हैं? टूलचेन को बनाए रखने के लिए संसाधन जोड़ने का यह एक और तरीका है।

नहीं, #25483 vgo से संबंधित नहीं है। मैंने इसे एक अन्य प्रकार की चीज़ के रूप में ऑफहैंड सूचीबद्ध किया है जो एक काल्पनिक go release हेल्पर कमांड कर सकता है। लेकिन यह किसी भी समय उपयोगी होगा।

मेरा बड़ा मुद्दा यह था कि गो ने कभी भी गो पैकेजों को रिलीज करना इतना आसान नहीं बनाया है। पिछले जीवन में मैंने पर्ल सीपीएएन पैकेजों के रिलीज को स्वचालित करने के लिए http://search.cpan.org/dist/ShipIt/ लिखा था और जब आप इस तरह की चीजों के आसपास टूलिंग करते हैं तो इसे हाथ से करने से बहुत फर्क पड़ता है।

मैंने केवल एक काल्पनिक go release उल्लेख किया क्योंकि मुझसे पूछा गया था कि मनुष्यों को गलतियाँ न करने में मदद करने के लिए गो अलग तरीके से क्या कर सकता है।

एक वास्तविक समस्या जो मैं vgo के साथ देखता हूं वह ठीक करने के लिए तुच्छ लगती है .... अधिकतम संस्करण समस्या। यदि एक पुस्तकालय एक डीपी के v1.7 के साथ टूट जाता है, तो यह निर्दिष्ट करने का कोई तरीका नहीं है कि एक बहिष्कृत के अलावा ... जो केवल v1.8 के बाहर आने तक मदद करता है, जो अभी भी ठीक उसी तरह टूटा हुआ है।

ऐसा लगता है कि दो पुस्तकालयों के असंगत होने पर vgo को निर्धारित करने में मदद करने के तरीके के रूप में vgo में अधिकतम संस्करण जोड़ना तुच्छ होगा। यदि एक पुस्तकालय कहता है कि उसे कम से कम v1.7 की आवश्यकता है और एक पुस्तकालय कहता है कि उसे इसकी आवश्यकता है

इसके बिना, vgo केवल 1.7 का उपयोग करेगा, और पुस्तकालयों में से एक टूट जाएगा। यदि आप भाग्यशाली हैं, तो एक कंपाइलर त्रुटि है .. अधिक संभावना है कि केवल एक सूक्ष्म व्यवहार बग है जो सड़क के नीचे तक ध्यान नहीं दिया जा सकता है। और जो कपटी है वह यह है कि यह शायद कुछ सकर्मक निर्भरता है जिसे आप सीधे कॉल भी नहीं कर रहे हैं।

@natefinch अधिकतम संस्करण प्रतिबंध एमवीएस को अपने बहुत चालाक टालने वाले-एसएमटी-सॉल्वर क्षेत्र से बाहर निकालते हैं।

मुझे लगता है कि @natefinch का अर्थ अंतिम चेक/फ़िल्टर के रूप में अधिकतम संस्करण है। एक बार एमवीएस ने अपना काम कर लिया है, अगर इनमें से कोई भी अधिकतम-संस्करण प्रतिबंध संतुष्ट नहीं होता है तो वीजीओ त्रुटि करेगा। वह अभी भी हमें SAT सॉल्वर क्षेत्र में नहीं लाता है।

बिल्कुल। कोई हल नहीं है। बस "vgo कहता है कि 1.7 उपयोग करने के लिए सही चीज़ है, लेकिन मॉड्यूल X कहता है कि यह उस संस्करण के साथ काम नहीं करता है"। यह पहले से ही कुछ है जो आज vgo के साथ हो सकता है यदि आपके पास कुछ ऐसा है जो require foo 1.7 कहता है और कुछ और कहता है exclude foo 1.7 , यदि कोई उच्च foo संस्करण नहीं है।

और फिर आपको क्या करना है?

आप समाधान निकालने के लिए अपने मानव मस्तिष्क का उपयोग करते हैं, क्योंकि कोई यांत्रिक समाधान नहीं है। आप दो पुस्तकालयों का उपयोग करने की कोशिश कर रहे हैं जो स्पष्ट रूप से बताते हैं कि उन्हें पुस्तकालय के असंगत संस्करणों की आवश्यकता है। A 1.6 से टूटेगा, B 1.7 से टूटेगा। समाप्त।

आपको या तो निर्भरता लेखक को बग को ठीक करने के लिए मनाने की जरूरत है (यदि यह एक बग है), पुस्तकालय लेखकों में से एक को एक नया संस्करण जारी करने के लिए मनाएं जो नए निर्भरता संस्करण के साथ संगत है, या सामान का एक पूरा गुच्छा फोर्क करें और इसे स्वयं ठीक करें .

कोई अच्छा जवाब नहीं है। लेकिन दुनिया में ऐसा कोई टूल नहीं है जो आपके लिए इसे ठीक कर सके।

@sdboyer

समस्या यह है, और हमेशा रही है, कि एमवीएस केवल एक भ्रामक समस्या का समाधान करता है (सैट से बचना),

मैं Russ के साथ आपकी निजी बातचीत पर बात नहीं कर सकता, लेकिन "SAT से बचना" मेरे लिए एक स्ट्रॉमैन तर्क की तरह लगता है। "सैट से बचना" "सैट का उपयोग करने" से अधिक कोई लक्ष्य नहीं है: न ही इसका उपयोगकर्ताओं पर कोई ठोस प्रभाव पड़ता है।

जैसा कि मैंने देखा, एमवीएस द्वारा हल की जाने वाली ठोस समस्याएं हैं:

• डिफ़ॉल्ट रूप से प्रतिलिपि प्रस्तुत करने योग्य बनाता है,
• संभव के रूप में परीक्षण किए गए संस्करणों के करीब निर्माण, और
• नकली अस्वीकृति से बचना।

हम ऐसे उपकरण बनाकर बेहतर पारिस्थितिकी तंत्र प्राप्त करते हैं जो उपयोगी सहयोग पर हमारे सीमित टोकन खर्च करने में हमारी सहायता करते हैं - न कि भंगुर उपकरण बनाकर जो हमें पहली जगह में भाग लेने के लिए दंडित करते हैं।

मैं सहमत हूँ। लेकिन मैं आपकी धारणाओं पर करीब से नज़र डालना चाहता हूं: कौन से उपकरण भागीदारी को "दंडित" करते हैं और क्यों?

आपके द्वारा अपनी पोस्ट में दिए गए उदाहरणों में से एक था, "हमारा प्रोजेक्ट अभी [email protected] पर निर्भर करता है, लेकिन यह [email protected] या नए के साथ काम नहीं करता है। हम अच्छे नागरिक बनना चाहते हैं और अनुकूलन करना चाहते हैं, लेकिन अभी हमारे पास बैंडविड्थ नहीं है।"

आप जो पहली (अंतर्निहित) धारणा बना रहे हैं, वह यह है कि आपके (या आपके उपयोगकर्ताओं) के पास अपनी परियोजना को उसकी निर्भरता के सभी रिलीज के खिलाफ पूरी तरह से परीक्षण करने के लिए समय और बैंडविड्थ है। कुछ परियोजनाओं के लिए, यह धारणा अपने आप में नहीं हो सकती है : इस अपेक्षा को स्थापित करके कि जब वे असंगतताओं की खोज करते हैं तो हर कोई ऊपरी सीमा को टैग करता है, आप "दंडित" अनुरक्षकों को समाप्त करते हैं जिनके पास रिग्रेशन के परीक्षण के लिए बैंडविड्थ नहीं है और संभावित रूप से उनकी सभी रिलीज पर सीमा अपडेट करते हैं।

इसके विपरीत, एमवीएस के तहत, अनुरक्षकों को केवल एक चीज घोषित करने के लिए बाध्य किया जाता है: "हमने [email protected] के खिलाफ पूरी तरह से परीक्षण किया और यह काम किया।" यदि आपके उपयोगकर्ता इसे बाधित करने के लिए कुछ नहीं करते हैं, तो वे [email protected] के विरुद्ध निर्माण करते हैं और सब कुछ पहले की तरह काम करना जारी रखता है।

एमवीएस के तहत, _ब्रेकेज केवल एक स्पष्ट अपग्रेड के समय होता है। यह एक महत्वपूर्ण लाभ है: यदि आपका उपयोगकर्ता किसी अन्य निर्भरता को अपग्रेड करता है ताकि यह [email protected] में खींच ले और आपके पैकेज के उपयोग को तोड़ दे, तो वे आसानी से कर सकते हैं जब तक आपके पास इसे ठीक करने का समय न हो, तब तक उस अपग्रेड को वापस कर दें, _या जब तक X के अनुरक्षक के पास असंगति को ठीक करने का समय न हो। और सही उम्मीदों को देखते हुए, बाद वाला पूर्व की तुलना में बहुत अधिक हो सकता है: ध्यान देना [email protected] अगर [email protected] अनुकूलता बहाल कर देता है तो यह अनावश्यक व्यस्त काम बन सकता है।

आप जो दूसरी धारणा बना रहे हैं, वह यह है कि आपके मॉड्यूल के _any part_ को प्रभावित करने वाली प्रत्येक असंगति आपके मॉड्यूल के _all users_ को प्रभावित करती है। यदि आपके पैकेज का वह भाग जो [email protected] के अंतर्गत आता है, एक कम उपयोग किया जाने वाला फ़ंक्शन है, तो अपने उपयोगकर्ताओं को अपने प्रोग्राम में X अपग्रेड करने से क्यों रोकें जो इसे कॉल भी नहीं करता है?

आप तर्क दे सकते हैं कि यदि मॉड्यूल के कुछ हिस्से अन्य भागों पर निर्भर नहीं हैं, तो उन्हें अलग मॉड्यूल होना चाहिए, लेकिन यह फिर से पैकेज अनुरक्षकों पर अतिरिक्त काम करने के लिए मजबूर करता है: यदि मेरे पास केवल समय-समय पर परीक्षण और अपग्रेड करने के लिए बैंडविड्थ है, तो मेरे पास केवल हो सकता है एक मॉड्यूल को बनाए रखने के लिए बैंडविड्थ, बारीक-बारीक निर्भरताओं के साथ बारीक-बारीक मॉड्यूल का पूरा परिसर नहीं।

¹ आम तौर पर, निर्भरताओं के साथ असंगतताओं का पता लगाने के लिए आपको उन निर्भरताओं के सभी रिलीज के क्रॉस उत्पाद_ के खिलाफ परीक्षण करने की आवश्यकता होती है: यह संभव है कि [email protected] का आपका विशेष उपयोग ठीक हो, लेकिन यह आपके द्वारा निर्भर किसी अन्य पैकेज के संयोजन में टूट जाता है पर। उदाहरण के लिए, शायद आपको और आपकी निर्भरता को वैश्विक कॉन्फ़िगरेशन में असंगत विकल्पों की आवश्यकता है।

वे बस उस अपग्रेड को वापस कर सकते हैं

यह मानता है कि यह एक कंपाइलर त्रुटि है या कुछ इसी तरह अत्यधिक दिखाई देता है। यह एक सूक्ष्म व्यवहार बग होने की बहुत अधिक संभावना है जो तुरंत स्पष्ट नहीं होता है। आप अपडेट करते हैं, अपने परीक्षण चलाते हैं, और सब कुछ अच्छा दिखता है। हो सकता है कि एक टाइमआउट जो 10 सेकंड का था अब 30 है, और जो लोड के तहत आपके बाकी स्टैक में टाइमआउट को फेंक देता है। आप तब तक ध्यान नहीं देंगे जब तक यह उत्पादन में नहीं चल रहा है (कुछ ऐसा ही कुछ साल पहले एमजीओ में बदलाव के साथ हुआ था)।

यदि आपके पैकेज का वह भाग जो [email protected] के अंतर्गत टूटता है, एक कम उपयोग किया जाने वाला फ़ंक्शन है, तो अपने उपयोगकर्ताओं को अपने प्रोग्राम में X को अपग्रेड करने से क्यों रोकें जो इसे कॉल भी नहीं करता है?

क्योंकि वे शायद यह नहीं जान पाएंगे कि क्या वे उस फ़ंक्शन का उपयोग कर रहे हैं या नहीं कर रहे हैं यदि यह एक सकर्मक निर्भरता है, और कौन कहता है कि जब आप अपना कोड बदलते हैं तो कुछ अप्रयुक्त कोडपथ अचानक सड़क पर सक्रिय नहीं होंगे? तो वह टूटा हुआ कार्य अब बुलाया जा रहा है। लाइब्रेरी मेंटेनर पर भरोसा करना कहीं बेहतर है जो अपनी लाइब्रेरी को समझने में विशेषज्ञ है, अगर वे कहते हैं कि यह 1.7 के साथ काम नहीं करता है, तो 1.7 के साथ निर्माण न करें।

यह मानता है कि यह एक कंपाइलर त्रुटि है या कुछ इसी तरह अत्यधिक दिखाई देता है। यह एक सूक्ष्म व्यवहार बग होने की बहुत अधिक संभावना है जो तुरंत स्पष्ट नहीं होता है।

लगभग हर सॉफ्टवेयर पैकेज के लगभग हर संस्करण में सूक्ष्म बग छिपे हुए हैं। हम आम तौर पर रिलीज को पूरी तरह से अनुपयोगी के रूप में चिह्नित नहीं करते हैं क्योंकि हमें ऐसा एक बग मिल गया है; इसके बजाय, हम इसे बाद के बिंदु रिलीज़ में ठीक करते हैं।

बग के इस विशेष वर्ग को क्या खास बनाता है?

कौन कहता है कि जब आप अपना कोड बदलते हैं तो कुछ अप्रयुक्त कोडपथ अचानक सड़क पर सक्रिय नहीं होंगे?

यह बिल्कुल एमवीएस तर्क है: यदि आप अपना कोड बदलते हैं, तो आप उस संशोधन पर ब्रेकेज _at का पता लगाते हैं, और आप उस संशोधन पर संस्करण बाधा को भी अपडेट कर सकते हैं।

इसका मतलब यह है कि, एक उपयोगकर्ता के रूप में, विफलताओं को विभाजित करना आसान है यदि आप अपनी निर्भरताओं को एक-एक करके थोक के बजाय अपग्रेड करते हैं, लेकिन यह सामान्य रूप से परिवर्तनों के बारे में सच है: आपके परिवर्तन जितने छोटे होंगे, आप उतनी ही सटीक रूप से कर सकते हैं उन्हें समद्विभाजित करें, भले ही वे आपके कोड या उसकी निर्भरता में परिवर्तन हों।

बग के इस विशेष वर्ग को क्या खास बनाता है?

यह सिर्फ एक बग नहीं है। यह उससे बड़ा है। पुस्तकालय के लेखक, जो अपने कोड के सबसे प्रमुख विशेषज्ञ हैं, ने दुनिया को बताया है "यो, एक्स का संस्करण 1.7 मेरे सामान को इस तरह से तोड़ता है जो इतने खराब हैं, बस इसके साथ निर्माण भी न करें"।

जाहिर है, जब तक कि यह एक कंपाइलर त्रुटि न हो, यह एक निर्णय कॉल है। यदि आपके 99 कार्यों में घबराहट होती है, लेकिन कोई नहीं... क्या यह सिर्फ एक बग है? या यह पूरी तरह से असंगति है? क्या होगा अगर यह सिर्फ एक समारोह है जो घबराहट करता है?

किसी बिंदु पर, मनुष्य को वह निर्णय लेना पड़ता है। उत्पादन में एक अघोषित बड़ी समस्या के बारे में चिंता करने के बजाय, मैं निर्माण-समय पर होने वाली पूर्व-खाली घोषित असंगतता से बहुत अधिक निपटूंगा।

यह सिर्फ एक बग नहीं है। यह उससे बड़ा है। पुस्तकालय के लेखक, जो अपने कोड के सबसे प्रमुख विशेषज्ञ हैं, ने दुनिया को बताया है "यो, एक्स का संस्करण 1.7 मेरे सामान को इस तरह से तोड़ता है जो इतने खराब हैं, बस इसके साथ निर्माण भी न करें"।

एक पुस्तकालय लेखक के लिए इसे व्यक्त करने का एक और तरीका है: एक परीक्षण लिखें जो विफल हो जाता है जब एक्स के असंगत संस्करण के साथ प्रयोग किया जाता है। इसका लाभ यह होगा कि यदि एक्स एक निश्चित संस्करण जारी करता है, तो पुस्तकालय में कोई बदलाव नहीं करना पड़ता है, साथ ही साथ किसी भी भविष्य के प्रतिगमन।

एक परीक्षण लिखें जो X के असंगत संस्करण के साथ उपयोग किए जाने पर विफल हो जाता है।

हां, मैंने इस बारे में सोचा था। लेकिन फिर आप प्रत्येक शीर्ष-स्तरीय बाइनरी को सभी संक्रमणीय निर्भरताओं के लिए सभी परीक्षण चलाने के लिए कह रहे हैं, ऐसे परीक्षण जिनके लिए बुनियादी ढांचे की आवश्यकता हो सकती है जो आपके पास नहीं है। सभी परीक्षण सूट 100% पृथक नहीं हैं।

एक कारण है कि go test ./... विक्रेता निर्देशिका में परीक्षण नहीं चलाता है।

संक्षेप में (संभावित रूप से खराब) ऐसा लगता है कि वीजीओ के खिलाफ मुख्य तकनीकी तर्क यह है कि पुस्तकालयों को अपनी निर्भरताओं पर विश्व स्तर पर सम्मानित बाधाओं को घोषित करने का एक तरीका होना चाहिए।

क्यों नहीं दोनों पक्ष एक प्रतिस्पर्धी प्रस्ताव को मंजूरी देने के लिए सहमत हैं जो यह पता लगाता है कि GPS2 दोनों पक्षों की तरह vgo के हिस्सों के साथ कैसे फिट हो सकता है। फिर, इस बीच vgo प्रयोग को मर्ज करें और vgo मेनलाइन को मर्ज करने से पहले GPS2 प्रस्ताव पर फिर से विचार करें?

अतीत में कई निर्भरता उपकरणों के साथ संघर्ष करने वाले व्यक्ति के रूप में मैं vgo के लिए उत्साहित हूं। FWIW, एक "समुदाय" सदस्य के रूप में, मुझे लगता है कि अब तक vgo समाधान द्वारा अच्छी तरह से प्रतिनिधित्व किया गया है। हालाँकि, मैं वैश्विक संस्करण बाधाओं को जोड़ने के पक्ष में तर्कों पर विचार करने के लिए खुला रहता हूँ और उस तर्क के आगे विकसित होने की आशा करता हूँ।

बस इसे वहां फेंक दो:

यह मानता है कि यह एक कंपाइलर त्रुटि है या कुछ इसी तरह अत्यधिक दिखाई देता है। यह एक सूक्ष्म व्यवहार बग होने की बहुत अधिक संभावना है जो तुरंत स्पष्ट नहीं है। आप अपडेट करते हैं, अपने परीक्षण चलाते हैं, और सब कुछ अच्छा दिखता है। हो सकता है कि एक टाइमआउट जो 10 सेकंड का था अब 30 है, और जो लोड के तहत आपके बाकी स्टैक में टाइमआउट को फेंक देता है।

यह सामान्य रूप से सॉफ्टवेयर में एक मुद्दा है। एनपीएम (अन्य संस्करण उपकरण जिसके साथ मैं व्यक्तिगत रूप से सबसे अधिक परिचित हूं) एक एसएटी सॉल्वर का उपयोग उस समुदाय के साथ करता है जिसने दृढ़ता से सेवर को गले लगा लिया है, और यह समस्या अभी भी मौजूद है।

जहां तक ​​​​सकर्मक निर्भरता चर्चा है, वास्तविकता यह है कि कोई जादू की छड़ी नहीं है: किसी बिंदु पर डेवलपर को उन निर्भरताओं के बारे में पता होना चाहिए जो वे उपयोग करते हैं और कोड को ठीक से परीक्षण करने के लिए समय लगाते हैं जिसके लिए वे अंततः जिम्मेदार होते हैं। मेरा नियोक्ता केवल एक ही नहीं हो सकता है जहां हमें कानूनी और अन्य कारणों से ट्रांजिटिव लाइब्रेरी समेत हमारे द्वारा उपयोग की जाने वाली प्रत्येक लाइब्रेरी को उचित ठहराने की आवश्यकता होती है।

ईमानदारी से, मेरी नज़र में, vgo के प्रति बहुत सी शिकायतें "यह सही नहीं है, इसलिए यह काम नहीं करेगी" प्रतीत होती है। आइए एक संपूर्ण समाधान के अभाव में एक अच्छे समाधान को लागू करने में असफल न हों।

मेरे लिए, ऐसा लगता है कि कोर टीम के लिए समग्र गो दर्शन के साथ एक ऐसा उपकरण प्रदान करना है जो ज्यादातर स्थितियों में अच्छा है, इसे समुदाय को और अधिक उन्नत और/या विशिष्ट टूलिंग प्रदान करने के लिए छोड़ देता है।

@malexdev इस तर्क में आपके अभिनेताओं के साथ समस्या हो सकती है कि:

आइए एक संपूर्ण समाधान के अभाव में एक अच्छे समाधान को लागू करने में असफल न हों।

dep आज एक अच्छा समाधान है। एक जो एक साथ काम करने वाले समुदाय द्वारा बनाया गया था। vgo, जैसा कि पहले शुरू किया गया था, कुछ धारणाएँ बनाता है:

1. कि कोई दुर्घटनावश भी कभी सीवर से नहीं टूटेगा
2. कि हमें मौजूदा पारिस्थितिकी तंत्र में मौजूदा कोडबेस को फिर से काम करना होगा

vgo एक "परफेक्ट वर्ल्ड" में "परफेक्ट सॉल्यूशन" पर आधारित है, जबकि डिप आज काम करता है जो पहले से ही अन्य प्रोग्रामिंग लैंग्वेज इकोसिस्टम में काम करता है, जबकि फॉल्ट टॉलरेंट होता है।

आप इसे पैकेज प्रबंधन समस्या स्थान के इतिहास में देख सकते हैं जिसे मैंने अभी लिखा है ।

संक्षेप में (संभावित रूप से खराब) ऐसा लगता है कि वीजीओ के खिलाफ मुख्य तकनीकी तर्क यह है कि पुस्तकालयों को अपनी निर्भरताओं पर विश्व स्तर पर सम्मानित बाधाओं को घोषित करने का एक तरीका होना चाहिए।

मैं इस सारांश से सहमत हूं।

क्यों नहीं दोनों पक्ष एक प्रतिस्पर्धी प्रस्ताव को मंजूरी देने के लिए सहमत हैं जो यह पता लगाता है कि GPS2 दोनों पक्षों की तरह vgo के हिस्सों के साथ कैसे फिट हो सकता है।

इस बिंदु पर, मैं असंबद्ध हूं कि GPS2 एक आवश्यकता है या एक अच्छा विचार भी है। आपके द्वारा ऊपर दी गई क्षमता को एमवीएस (जैसे यह या यह ) के शीर्ष पर वीजीओ में फिर से लगाया जा सकता है। व्यक्तिगत रूप से, मैं उम्मीद कर रहा हूं कि @sdboyer के अगले ब्लॉग पोस्ट में स्वयं MVS के खिलाफ अच्छे तर्क होंगे, लेकिन अभी, मुझे वास्तव में एक अलग एल्गोरिथ्म के लिए कोई कारण नहीं दिख रहा है - विशेष रूप से एक जिसके लिए vgo के महत्वपूर्ण UX फायदे खर्च होंगे।

हालांकि, निष्पक्ष होने के लिए, मुझे इसके साथ प्रयोग करने का कोई कारण नहीं दिखता है।

dep आज एक अच्छा समाधान है।

मुझे यकीन नहीं है कि मैं सहमत हूं। मैंने इसे स्वयं उपयोग नहीं किया है, लेकिन वहां सुस्त पर जहां कई लोग उन मुद्दों के बारे में शिकायत करते हैं जो सीधे इसके एसएटी समाधान दृष्टिकोण के लिए पता लगाने योग्य लगते हैं। और मुझे पता है कि मैं समग्र डिजाइन के बारे में बहुत नाखुश हूं (निर्भरता सॉल्वर के सवाल को छोड़कर, इसलिए सामान्य वर्कफ़्लो और यूएक्स)।

1. कि कोई दुर्घटनावश भी कभी सीवर से नहीं टूटेगा

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

मुझे लगता है कि सामान्य तौर पर यह समझ में आता है कि हम किस बारे में बात कर रहे हैं, उसके विभिन्न टुकड़ों के बीच अंतर करना है। कुछ शिकायतें SIV, कुछ MVS और कुछ सामान्य vgo-shell से संबंधित हैं। उदाहरण के लिए, यह सच है कि एमवीएस ऊपरी संस्करण सीमाओं को संभाल नहीं सकता है, लेकिन इसका मतलब यह नहीं है कि वीजीओ ऊपरी संस्करण सीमाओं को संभाल नहीं सकता है। SIV को बहुत सारे कोड बदलने की आवश्यकता है (आयात विवरणों को फिर से लिखकर), लेकिन फिर से, इसका मतलब यह भी नहीं है कि vgo को इसकी आवश्यकता होगी। हालांकि स्पष्ट होने के बावजूद, मुझे यह भी नहीं लगता कि यह कोई बड़ी बात है, जब तक हम माइग्रेट कर सकते हैं। हम कौन सा AFAICT कर सकते हैं।

मैंने अभी-अभी @rsc के GopherConSG को वर्जनिंग के बारे में ओपनिंग कीनोट देखा। उन्होंने उस परिदृश्य को संबोधित किया जहां एक निर्भरता एक ब्रेकिंग परिवर्तन का परिचय देती है, और तुलना की कि कैसे vgo और dep इसे संभालेंगे, जो यहां मुख्य चिंता का विषय है। (यह एक अच्छी घड़ी है।)

अगर मैं उसकी बात को सही ढंग से समझ गया, तो डिप बिल्ड को भी तोड़ सकता है यदि खराब संस्करण से बचने के लिए अधिकतम संस्करण सीमा का उपयोग किया जाता है । मुझे यहां उन लोगों द्वारा संबोधित इस बिंदु को देखने में बहुत दिलचस्पी होगी जो चिंतित हैं कि इस संबंध में vgo कम हो जाता है।

@willfaught हमारे लिए, खराब संस्करण से बचने के लिए अधिकतम संस्करण सीमा का उपयोग किए जाने पर बिल्ड को तोड़ना सफल माना जाता है! हम यही होना चाहते हैं। Russ सही ढंग से नोट करता है कि यह समस्या स्वचालित रूप से हल नहीं होती है। Helm>2.0.0 पर एक बाधा उपयोगकर्ता को स्वचालित रूप से " हेल्म@2.1.4 " में अपग्रेड नहीं करने वाली है, लेकिन यह सफलतापूर्वक काम करेगा (यदि यह असंभव है तो जीआरपीसी को डाउनग्रेड करें या बिल्ड विफलता को ट्रिगर करें) यदि उपयोगकर्ता स्पष्ट रूप से "हेल्म" पर निर्भर करता है == 2.1.4"। निजी तौर पर, लाइब्रेरी के साथ किसी समस्या का सामना करते समय मैं आमतौर पर कोशिश करता हूं कि नवीनतम संस्करण में अपडेट को मजबूर कर रहा है। Dep के साथ, यह मुझे GRPC 1.4.0 द्वारा शुरू की गई विफलता के बारे में सूचित करेगा। vgo के साथ, हेल्म के लिए मुझसे यह संवाद करने का एकमात्र तरीका दस्तावेज़ीकरण के माध्यम से है।

बिंदु को दोहराने के लिए क्योंकि यह समझ में नहीं आता है: न तो dep और न ही vgo इस समस्या को होने से रोक सकते हैं या एक मूर्खतापूर्ण समाधान प्रदान कर सकते हैं। बल्कि, dep हेल्म को यह संवाद करने की अनुमति देता है कि समस्या मौजूद है, जबकि vgo नहीं है।

संक्षेप में (संभावित रूप से खराब) ऐसा लगता है कि वीजीओ के खिलाफ मुख्य तकनीकी तर्क यह है कि पुस्तकालयों को अपनी निर्भरताओं पर विश्व स्तर पर सम्मानित बाधाओं को घोषित करने का एक तरीका होना चाहिए।

मैं इस सारांश में कुछ रंग जोड़ूंगा कि अनुकूलता नियमों का उल्लंघन होने पर दुखी पथ से निपटने के लिए इन बाधाओं की आवश्यकता होती है। vgo आयात संगतता नियम स्थापित करता है और फिर यह मानकर एक समाधान विकसित करने के लिए आगे बढ़ता है कि नियम का हमेशा पालन किया जाता है। इस आदर्श दुनिया में, ऊपरी सीमा की आवश्यकता सीमित है या यहां तक ​​​​कि न के बराबर है। वास्तविक दुनिया में, ऐसा नहीं होगा: डेवलपर्स अपडेट जारी करेंगे जो संगतता को तोड़ते हैं, या तो जानबूझकर या अन्यथा।

मुझे लगता है कि @Merovius एक व्यावहारिक समाधान पर है। एमवीएस निर्दिष्ट के रूप में आगे बढ़ेगा, फिर संकल्प पूरा होने के बाद, वीजीओ बहिष्करण के लिए प्रत्येक हल किए गए पैकेज की जांच करेगा। यदि कोई पाया जाता है, तो उन्हें अंतिम उपयोगकर्ता को सूचित किया जाता है, जो इन बाधाओं को पूरा करने के लिए या तो अपनी निर्भरता को बदलने का विकल्प चुन सकते हैं या बाधाओं को ओवरराइड और अनदेखा करना चुन सकते हैं। मैं इसके दूसरी तरफ भी रहा हूं और कभी-कभी आप मेंटेनर से बेहतर जानते हैं; यह आपके आवेदन के लिए काम करता है और आप इसकी परवाह करते हैं।

यह मध्यस्थ पुस्तकालयों के लिए अंतिम उपयोगकर्ताओं के लिए एक असंगति को संप्रेषित करने के लिए एक पथ को पुनर्स्थापित करता है। पतवार उदाहरण को फिर से दोहराने के लिए:

उपयोगकर्ता@1.1 : हेल्म @ 2.1.2
हेल्म@2.1.2 : जीआरपीसी @1.3.5

==> उपयोगकर्ता जानबूझकर [email protected] में अपग्रेड करता है।

उपयोगकर्ता: हेल्म @ 2.1.3, [email protected] ("हेल्म अपडेट किया गया, इसलिए मैं अंततः जीआरपीसी 1.4 का उपयोग कर सकता हूं!")
पतवार: जीआरपीसी @1.4.0

==> बग का पता चला! उपयोगकर्ता को हेल्म के साथ कुछ समस्याएं दिखाई दे रही हैं, इसलिए नए संस्करण की जांच करें।

उपयोगकर्ता: हेल्म@2.1.4 , जीआरपीसी@1.4.0
पतवार: जीआरपीसी @ 1.3.5, कमजोर जीआरपीसी <1.4.0

उपयोगकर्ता एक चेतावनी देखता है कि जीआरपीसी 1.4.0 को हेल्म@2.1.4.1 की स्थापना से खारिज कर दिया गया है । चूंकि हेल्म मेरे लिए टूटा हुआ है और यही मैं ठीक करने की कोशिश कर रहा हूं, मैं जीआरपीसी 1.4.0 पर अपनी निर्भरता को हटा देता हूं (दुख की बात है कि कुछ उपयोगी कार्यक्षमता खो रहा है) और एमवीएस को फिर से चलाएं। इस बार, एमवीएस जीआरपीसी को 1.3.5 और हेल्म को 2.1.4 पर हल करता है, सभी कमजोर बाधाओं को फिर से जांचता है, पाता है कि वे पकड़ में हैं, और मैं कर चुका हूं।

मैं किसी भी उपकरण से इन समस्याओं को जादुई रूप से हल करने की उम्मीद नहीं करता लेकिन मुझे मिडलवेयर लाइब्रेरी के रूप में कुछ सहारा की उम्मीद है। जहां तक ​​​​मैं कह सकता हूं, vgo में एकमात्र विकल्प मेरी सभी अपस्ट्रीम निर्भरताओं को फोर्क करना और उनका नाम बदलना है (या समकक्ष, उन्हें मेरी परियोजना में कॉपी करें) यदि मैं अपने उपयोगकर्ताओं को इन निर्भरताओं के साथ संगतता मुद्दों से अलग करना चाहता हूं। मुझे नहीं लगता कि कोई ऐसा चाहता है।

@willfaught हमारे लिए, खराब संस्करण से बचने के लिए अधिकतम संस्करण सीमा का उपयोग किए जाने पर बिल्ड को तोड़ना सफल माना जाता है! हम यही होना चाहते हैं।

चर्चा में बात यह है कि इस परिदृश्य में vgo dep से भी बदतर नहीं है। उनके उदाहरण में, निर्माण इस अर्थ में नहीं टूटा है कि डीपी समाधान नहीं ढूंढ सकता है; यह इस अर्थ में टूटा हुआ है कि डीपी समाधान ढूंढता है , और उस समाधान में खराब संस्करण शामिल है, जिसके परिणामस्वरूप वही खराब स्थिति होती है जिसे हम टालना चाहते थे।

आपको वास्तव में वीडियो देखना चाहिए, जो एक उत्कृष्ट उदाहरण के माध्यम से चलता है, लेकिन यहाँ सार है जैसा कि मैंने इसे समझा/याद किया:

• पैकेज संस्करण (उनकी निर्भरता आवश्यकताओं सहित) अपरिवर्तनीय हैं
• अपने पैकेज के लिए मौजूदा निर्भरता में अधिकतम संस्करण सीमा जोड़ने के लिए, आपको अपने पैकेज का एक नया संस्करण प्रकाशित करना होगा।
• यह संभव है कि डीपी सभी आवश्यकताओं को पूरा करने के लिए आपके पैकेज के पिछले संस्करण का चयन करेगा, इस स्थिति में आपकी नई अधिकतम संस्करण सीमा मौजूद नहीं होगी। यह खराब संस्करण का उपयोग करने की अनुमति देता है।

मैं ज्यादातर अधिकतम संस्करण बहिष्करण जोड़ने के प्रस्ताव से सहमत हूं, लेकिन मुझे यह चिंता है: मान लीजिए कि मैंने अपनी लाइब्रेरी में "gRPC> 1.4, <1.8" का उपयोग किया है, फिर जीआरपीसी 1.9 में, लेखक तय करते हैं, "आप जानते हैं कि, हेल्म था ठीक है, हमने 1.8 में एक महत्वपूर्ण बदलाव किया है, हम 1.9.0 में अपने पिछले व्यवहार पर वापस जा रहे हैं।" अब हेल्म + जीआरपीसी आयात करने की कोशिश करने वाले लोग 1.9 का उपयोग नहीं कर पाएंगे, जब तक कि हेल्म एक संस्करण जारी नहीं करता है जो कहता है कि "जीआरपीसी> 1.4 का उपयोग करें, 1.8.0, 1.8.1, 1.8.2 को छोड़कर, लेकिन 1.9+ अच्छा है"।

दूसरे शब्दों में, शायद exclude grpc 1.8 पर्याप्त है क्योंकि हम यह नहीं जान पाएंगे कि जीआरपीसी 1.9 इसके प्रकाशित होने तक असंगत होगा या नहीं, जिस बिंदु पर हेल्म इसे बहिष्कृत सूची में जोड़ सकता है या नहीं।

मैं अनिवार्य रूप से इस स्थान के बारे में कुछ नहीं जानता। लेकिन यहां चर्चा को पढ़ने से ऐसा लगता है कि सबसे बड़ी असहमति इस बात पर है कि गलत मामलों का पता कैसे लगाया जाए। यही है, एमवीएस (वीजीओ) और एसएटी (डीईपी) दोनों सामान्य परिस्थितियों को कमोबेश अच्छी तरह से संभालते हैं, शायद समान रूप से नहीं, लेकिन पर्याप्त रूप से।

एसएटी एक ऐसी क्षमता प्रदान करता है जो एमवीएस नहीं करता है: एसएटी का उपयोग करके, पुस्तकालय पैकेज पी 1 के लेखक "पी 1 को पी 2 की आवश्यकता है, और पी 2 वर्जन> 1.1 और पी 2 वर्जन <1.4" के साथ काम करता है। MVS केवल "P1 को P2 की आवश्यकता है, और P2Version> 1.1 के साथ काम करता है" की घोषणा कर सकता है, और प्रतिबंध "P2Version <1.4" को व्यक्त नहीं कर सकता है। सामान्य मामले में, इससे कोई फर्क नहीं पड़ता। यह केवल तभी मायने रखता है जब कोई ऑपरेशन P2 को संस्करण 1.4 में अपग्रेड करने का प्रयास करता है। उस स्थिति में, SAT एक त्रुटि की रिपोर्ट करेगा, जबकि MVS नहीं करेगा। एमवीएस का उपयोग करते समय, यदि असंगति एक संकलन त्रुटि नहीं है, तो यह तथ्य के लंबे समय बाद विफलता का कारण बन सकती है।

इसमें कोई संदेह नहीं है कि सैट समर्थक एमवीएस के साथ अन्य प्रमुख समस्याओं को देखते हैं, लेकिन अभी तक यही वह है जिसे मैं समझता हूं।

मुझे लगता है कि यह ध्यान देने योग्य है कि यदि प्रतिबंध अभिव्यक्तियां स्वयं संस्करणित हैं - यदि वे पी 1 की विशिष्ट रिलीज का हिस्सा हैं - तो घटनाओं के सामान्य पाठ्यक्रम में, पी 2 संस्करण 1.4 जारी होने से पहले, पी 1 संस्करण 2.2 खुशी से "पी 2 वर्जन" कहेगा > 1.1"। P2 संस्करण 1.4 जारी होने पर ही P1 लेखक असंगति को नोटिस करेंगे, और P1 संस्करण 2.3 को "P2Version> 1.1 और P2Version <1.4" के साथ रिलीज़ करेंगे। इसलिए यदि आप P1 संस्करण 2.2 का उपयोग कर रहे हैं, तो न तो SAT और न ही MVS, P2 को संस्करण 1.4 में अपग्रेड करने में किसी समस्या की रिपोर्ट करेगा, हालांकि यह कुछ सूक्ष्म तरीके से विफल हो जाएगा।

दूसरे शब्दों में, जबकि P1 के न्यूनतम संगत संस्करणों को सूचीबद्ध करने के लिए P1 की रिलीज़ के लिए यह सही समझ में आता है, यदि रिलीज़ P2 के नवीनतम संस्करण के साथ सही ढंग से काम करता है, तो रिलीज़ के लिए अधिकतम संगत संस्करणों को सूचीबद्ध करने का कोई मतलब नहीं है . अधिकतम संगत संस्करण या तो रूढ़िवादी होगा, और इसलिए तेजी से गलत होगा क्योंकि P2 के नए और बेहतर संस्करण दिखाई देते हैं, या यदि P2 भविष्य में किसी असंगत तरीके से बदलता है, तो उस आवश्यकता को निर्दिष्ट करने में विफल रहेगा क्योंकि रिलीज के समय यह ' टी मौजूद है।

इसलिए यदि हम एक ऐसी प्रणाली चाहते हैं जो न्यूनतम संस्करण आवश्यकताओं के अलावा कुछ भी परिभाषित करे, तो उन आवश्यकताओं को एक विशिष्ट रिलीज का हिस्सा नहीं होना चाहिए, बल्कि इसके बजाय पैकेज से जुड़े किसी प्रकार के मेटाडेटा का हिस्सा होना चाहिए, मेटाडेटा जिसे प्राप्त किया जा सकता है किसी भी समय पैकेज को अपडेट किए बिना। और इसका मतलब है कि ऑपरेशन "इस पैकेज को अपडेट करें" ऑपरेशन से अलग होना चाहिए "जांचें कि मेरे वर्तमान पैकेज संस्करण संगत हैं या नहीं।"

मैं आगे दावा करूंगा - और यह निश्चित रूप से ऊपर की तुलना में अधिक कठिन है - कि यदि "जांचें कि क्या मेरे वर्तमान पैकेज संस्करण संगत हैं" विफल रहता है, तो समस्या को हल करने के लिए किसी भी उपकरण पर भरोसा करना सामान्य रूप से नासमझी है। यदि सरल ऑपरेशन "हर प्रासंगिक पैकेज को वर्तमान संस्करण में अपग्रेड करें" द्वारा संगतता समस्या को हल नहीं किया जा सकता है, तो इसके लिए विचार की आवश्यकता है। एक उपकरण उस विचार में मार्गदर्शन कर सकता है, लेकिन सामान्य तौर पर यह इसे प्रतिस्थापित नहीं कर सकता है। विशेष रूप से किसी टूल के लिए पैकेजों को स्वचालित रूप से डाउनग्रेड करना प्रारंभ करना बहुत नासमझी लगती है।

तो अगर हम के संदर्भ में सोचते हैं

1. पैकेज असंगतताओं का वर्णन करने वाले पैकेज मेटाडेटा को परिभाषित करने का एक तरीका
2. उसके आधार पर, एक उपकरण जो रिपोर्ट करता है कि आपके वर्तमान पैकेज संगत हैं या नहीं

तो शायद एमवीएस और एसएटी के बीच कुछ प्रमुख अंतर कम महत्वपूर्ण हो जाते हैं।

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

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

संस्करण संगतता के लिए बाहरी जानकारी के बारे में मेरा एक ही विचार था ... चूंकि संस्करण संगतता निरंतर होनी चाहिए, इसे स्रोत नियंत्रण में होने की आवश्यकता नहीं है (और वास्तव में स्रोत नियंत्रण में होना एक निश्चित नुकसान है जैसा कि ऊपर बताया गया है)। यह अच्छा होगा यदि इसके लिए एक प्रस्तावित समाधान हो, क्योंकि यह निश्चित रूप से प्रस्तावित एमवीएस के साथ एक बड़ी समस्या है।

चर्चा को इस दिशा में व्यवस्थित रूप से आगे बढ़ते हुए देखना अद्भुत है। यह मेरी चिंताओं का एक केंद्रीय जोर रहा है, और यह मूलभूत मुद्दों की व्याख्या करना इतना आसान बनाता है जब लोग पहले से ही इसके लिए सबसे अधिक रास्ते हैं।

@ianlancetaylor , मुझे लगता है कि आप पहले से जारी संस्करणों पर बाधा जानकारी में परिवर्तन करने में सक्षम होने की आवश्यकता के बारे में इस अवलोकन के साथ हाजिर हैं। जैसा कि @rsc ने संकेत दिया है, ऐसी सेवा कुछ ऐसी है जिस पर हमने चर्चा की है/मैंने अपनी बैठकों में सुझाव दिया है। हम इसे Godoc.org, या कुछ और के साथ कर सकते हैं, निश्चित रूप से। लेकिन मुझे वास्तव में नहीं लगता कि इसमें एक अलग सेवा की आवश्यकता है, और यह एक के बिना बेहतर होगा। मैंने इसका एक त्वरित संदर्भ उस अंश में दिया जो मैंने शुक्रवार को प्रकाशित किया था (बस उस एंकर से ऊपर)। यदि किसी सेवा में और कुछ नहीं है, तो ऐसे प्रश्नों का उत्तर दिया जाना चाहिए जिनके बारे में असंगतताओं की घोषणा चेतावनियों में दिखाई देनी चाहिए, जिसका अर्थ है पहचान को संभालना, और हम कैसे डिग्राफ में विशेष परिस्थितियों में घोषणाओं को गुंजाइश करते हैं। घोषणाओं को मेटाडेटा फ़ाइलों के अंदर रखने का मतलब है कि हमें इसके बारे में चिंता करने की ज़रूरत नहीं है। लेकिन उस पर और एक सेकंड में।

यहाँ वास्तव में जो महत्वपूर्ण है वह यह बिंदु है, हालाँकि शायद उस तरह से नहीं जैसा आप चाहते थे:

शायद एमवीएस और एसएटी के बीच कुछ प्रमुख अंतर कम महत्वपूर्ण हो जाते हैं।

मेटा-टूल का सुझाव जो यह खोज करता है - हाँ, यह एक एसएटी खोज है - लोगों की पहचान करने वाली समस्याओं के समाधान के रूप में बता रहा है। यदि एमवीएस वर्णित के अनुसार आगे बढ़ता है, तो यह ठीक वैसा ही है जैसा हमें डिपो में बदलना होगा। और ध्यान देने वाली पहली बात यह है कि, अगर हम इन असंगतियों के बारे में इतने चिंतित हैं कि हम एक खोज उपकरण के बारे में बात कर रहे हैं, तो हम वास्तव में जो कह रहे हैं वह यह है कि एमवीएस एक बड़े एल्गोरिथम में सिर्फ एक कदम बन जाता है, और ग्रोकेबिलिटी बेनिफिट्स सीधे खिड़की से बाहर जाते हैं।

सिवाय इसके कि यह उससे भी बदतर है, क्योंकि न्यूनतम और वर्तमान संस्करणों को एक साथ जमा करने से उत्पन्न होने वाली सूचना हानि की बेक-इन समस्या के आसपास मेटा टूलिंग की कोई भी मात्रा नहीं मिल सकती है। इसका बड़ा परिणाम कैस्केडिंग रोलबैक है, जिसका अर्थ है कि वास्तव में इस सूची में किसी भी असंगति को दूर करने की कोशिश करने से निर्भरता ग्राफ के अन्य हिस्सों को वापस उछालने की संभावना है जो आपकी समस्या से जरूरी नहीं है। और, डेवलपर ऐसी अपडेट रणनीति का पालन करने में सक्षम नहीं होंगे जो दूसरों के लिए हानिकारक न हो। . (ओह, और प्रेत नियम , लेकिन यह सामान्य रूप से सिर्फ एक एमवीएस साइड इफेक्ट है)।

यही कारण है कि मैंने दावा किया है कि एमवीएस एक अनुपयुक्त मध्यवर्ती परत है जिस पर इस तरह के एक उच्च-आदेश उपकरण का निर्माण करना है - "उद्देश्य के लिए उपयुक्त नहीं है।" यह स्पष्ट है कि लोगों का मानना ​​है कि ये असंगतियां होंगी, इसलिए एमवीएस सिर्फ एक कठिन समस्या ले रहा है और इसे कठिन बना रहा है।

यदि इसके बजाय, हम एक "असंगति सेवा" की समस्या को वापस मेटाडेटा फ़ाइल में एकीकृत करते हैं, तो मेरा मानना ​​​​है कि समान प्रभाव प्राप्त करने के लिए, जोड़ीदार घोषणाओं के केवल एक साधारण सेट का उपयोग करके यह संभव है। (यह अवधारणा का एक मसौदा है, लेकिन यह तेजी से एक साथ लटकता हुआ प्रतीत होता है)

यह आवश्यक होगा कि एमवीएस के कुछ हिस्सों में बदलाव हो, लेकिन एमवीएस अभी भी वहां एन्कोड की गई जानकारी के ऊपर चल सकता है। यह ज्यादातर उपयोगी होगा यदि असंगतताएं वास्तव में पागल हो जाती हैं, और आप उन सभी से बचना चाहते हैं। लेकिन प्राथमिक एल्गोरिथ्म एक आधार रेखा से शुरू होगा जो एमवीएस की तरह दिखता है, फिर एक व्यापक खोज पर स्विच करें (स्पष्ट होने के लिए, एमवीएस को अभी भी खोज माना जाना चाहिए), बेतुके पुराने संस्करणों में जाने की संभावना के बिना।

(ध्यान दें, मैं इस सप्ताह छुट्टी पर रहूंगा, इसलिए अगले सप्ताहांत तक जवाब नहीं दूंगा)

@sdboyer

एक मेटा-टूल का सुझाव जो यह खोज करता है - हाँ, यह एक SAT खोज है

क्या आप अधिक विशिष्ट हो सकते हैं? आपके द्वारा उद्धृत वाक्य इयान द्वारा यह रिपोर्ट करने के लिए एक उपकरण का सुझाव देने के ठीक बाद है कि क्या चयनित संस्करण संगत हैं - और मेरे सर्वोत्तम ज्ञान के लिए, यह यहां सुझाया गया मुख्य विकल्प है (यह निश्चित रूप से वही है जो मैं ऊपर चाहता था)। यह समस्या निश्चित रूप से एक खोज नहीं है और यह तुच्छ है और इसके लिए SAT को हल करने की आवश्यकता नहीं है (यह केवल मूल्यों के दिए गए सेट के लिए एक बूलियन फॉर्मूला का मूल्यांकन कर रहा है, न कि इसे संतुष्ट करने वाले मूल्यों को खोजने की कोशिश कर रहा है)।

ठीक है, केवल यह रिपोर्ट करना कि सूत्र में कुछ ज्ञात-असंगत मान हैं, SAT को हल करने की आवश्यकता नहीं है। उस आधार पर कोई कार्रवाई करना, जैसे कि एक ऐसे उपकरण के लिए जो परिणाम खोजने की प्रक्रिया में सहायता करता है जिसमें ऐसा कोई मूल्य नहीं है।

मैंने उस वाक्य को इसलिए उद्धृत नहीं किया क्योंकि मुझे लगता है कि यह लोगों द्वारा हमेशा आवश्यक खोज को स्वीकार करने का संकेत है, बल्कि इसलिए कि अगर हम मानते हैं कि ऐसी स्थितियों की रिपोर्ट करना महत्वपूर्ण है, तो ऐसा इसलिए है क्योंकि हमें विश्वास है कि हम ऐसे परिदृश्यों का सामना करेंगे।

समस्या यह है कि, एक बार जब उन मामलों को संबोधित करने की संभावना और महत्व स्थापित हो जाता है, तो ऐसा लगता है कि लोग गलत छलांग लगाते हैं कि "हम एमवीएस के शीर्ष पर सभी खोज चीजें कर सकते हैं, और यह ठीक रहेगा।" हम कर सकते हैं, लेकिन इस तरह के प्रयासों से निपटने के लिए बहुत मुश्किल हो जाते हैं क्योंकि एमवीएस डिजाइन द्वारा उपयोगी संभावित पथों को काट देता है।

28 मई, 2018 को 4:02:13 अपराह्न ईडीटी, एक्सल वैगनर नोटिफिकेशन @github.com ने लिखा:

@sdboyer

एक मेटा-टूल का सुझाव जो यह खोज करता है - हाँ, वह है a
सैट खोज

क्या आप अधिक विशिष्ट हो सकते हैं? आपके द्वारा उद्धृत वाक्य इयान के ठीक बाद में है
यह रिपोर्ट करने के लिए एक उपकरण का सुझाव देना कि क्या चयनित संस्करण हैंसंगत - और मेरी जानकारी के अनुसार, यह मुख्य है
विकल्प यहां सुझाया गया है (यह निश्चित रूप से वही है जो मैं ऊपर चाहता था)।
वह समस्या निश्चित रूप से कोई खोज नहीं है और यह तुच्छ है और
SAT को हल करने की आवश्यकता नहीं है (यह सिर्फ एक बूलियन सूत्र का मूल्यांकन कर रहा है
मूल्यों के दिए गए सेट के लिए, उन मूल्यों को खोजने की कोशिश नहीं करना जो इसे संतुष्ट करते हैं)।

--
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/golang/go/issues/24301#issuecomment -392595150

मैंने उस वाक्य को इसलिए उद्धृत नहीं किया क्योंकि मुझे लगता है कि यह लोगों द्वारा हमेशा आवश्यक खोज को स्वीकार करने का संकेत है, बल्कि इसलिए कि अगर हम मानते हैं कि ऐसी स्थितियों की रिपोर्ट करना महत्वपूर्ण है, तो ऐसा इसलिए है क्योंकि हमें विश्वास है कि हम ऐसे परिदृश्यों का सामना करेंगे।

स्पष्ट होने के लिए: इस तरह से ऊपरी सीमाओं को फिर से तैयार करने का सुझाव पूरी तरह से सामने आने वाली चिंताओं के प्रति प्रतिक्रियाशील है और यह दिखाने के लिए कि यह किया जा सकता है (इस दावे पर गंभीर रूप से सवाल उठाने के लिए कि एमवीएस उद्देश्य के लिए मौलिक रूप से अनुपयुक्त है)। उस रियायत और समझौता करने की इच्छा को प्रमाण के रूप में लेना थोड़ा अनुचित लगता है कि हमें लगता है कि आप हमेशा सही थे।

मेरे लिए, यह दावा (कि एमवीएस अनुपयुक्त है और गलत दिशा में एक अनिवार्य रूप से अपरिवर्तनीय कदम है) मैं व्यक्तिगत रूप से चुनौती दे रहा हूं और जिस लेंस के माध्यम से मैं आपके तर्क पढ़ रहा हूं। उन तर्कों में से एक यह था, कि यह एक विशेषता है यदि हम असंगतताओं की घोषणा कर सकते हैं और संस्करण चयन एल्गोरिदम विफल होने पर विफल हो जाते हैं। एक और उचित तर्क यह है कि यदि वे होते हैं, तो यह अच्छा होगा कि एल्गोरिदम हमारे लिए उन्हें हल करने में सक्षम हो (जिसके लिए वास्तव में एक एसएटी सॉल्वर की आवश्यकता होगी)।

हालांकि, जबकि मुझे लगता है कि वे वैध और उचित चिंताएं हैं, मुझे विश्वास नहीं है कि वे मुझे साबित करने के लिए बार-बार पास करते हैं कि एमवीएस मौलिक रूप से अनुपयुक्त है। मैं अब भी मानता हूं कि एमवीएस एक शुरुआती बिंदु के रूप में तालिका में अच्छी और महत्वपूर्ण विशेषताएं लाता है। और यह कि यदि वे चिंताएँ व्यवहार में महत्वपूर्ण दर्द का कारण बनती हैं, तो अभी भी बहुत सारे तरीके हैं जिनसे हम उस पर पुनरावृति कर सकते हैं - शुद्ध विफलताओं के साथ ऊपरी सीमा (चाहे go.mod के हिस्से के रूप में या एक अलग सेवा के रूप में) को जोड़ने से। किसी बिंदु पर पूर्ण SAT सॉल्वर और लॉक फ़ाइलों को जोड़ने तक और इसमें शामिल हैं। यानी मैं आपसे सहमत हूं कि वे चीजें होंगी, लेकिन ए) मैं (शायद भोलेपन से) आशावादी हूं कि वे उतना दर्द नहीं देंगे जितना आप अनुमान लगा रहे हैं और बी) कि जब हम एमवीएस के साथ शुरुआत करते हैं तब भी वे हल करने योग्य समस्याएं हैं।

मेरे साथ ऐसा होता है कि अनुकूलता निर्धारित करने वाले स्रोत नियंत्रण के बाहर कुछ एमवीएस सिस्टम के निर्धारणवाद को बदल देगा। यदि आपके पास एक lib में बाधा के रूप में foo>= 1.5.0 है, और दूसरे lib में foo>= 1.6.0 है। फिर उन दोनों को बाइनरी में डालें और वे 1.6.0 चुनें। एमवीएस में दोहराने योग्य निर्माण के लिए आपको बस इतना ही चाहिए। यह हमेशा 1.6 . चुनेगा

लेकिन अगर आप मिश्रण में बाहरी संगतता जोड़ते हैं, तो आप उस पहली लाइब्रेरी को यह कहने के लिए अपडेट कर सकते हैं कि यह 1.6 के साथ संगत नहीं है, और फिर एल्गोरिदम 1.7 का चयन करेगा, भले ही कोड नहीं बदला है ... जिसका अर्थ है कि आपको इसकी आवश्यकता होगी एक लॉक फ़ाइल फिर से।

संदर्भ के लिए, मुझे नहीं लगता कि लॉक फ़ाइल एक बुरी चीज है। आपको वास्तव में जो बनाने की आवश्यकता है उसकी एक स्पष्ट सूची होना अच्छा है। और वह इसे तेजी से बनाना चाहिए। कोई जादू तर्क की जरूरत नहीं है।

@natefinch यदि एप्लिकेशन की go.mod फ़ाइल को v1.7.0 की आवश्यकता के लिए अद्यतन किया गया था क्योंकि बाहरी संगतता उपकरण ने संकेत दिया था कि v1.6.0 असंगत था, तो आपको लॉक फ़ाइल की आवश्यकता नहीं होगी। क्योंकि v1.7.0 जीवन को go.mod फ़ाइल में निर्दिष्ट करते हुए लेखक यह कहते हुए एक टिप्पणी भी जोड़ सकता है कि v1.7.0 का उपयोग क्यों किया जा रहा है और यह जानकारी पाठकों के लिए उपयोगी होगी।

@leighmcculloch , यदि ऐप में कोई भी फाइल अपडेट की जाती है तो यह एक अलग निर्माण है और पूरी तरह से "लॉकफाइल के बिना प्रतिलिपि प्रस्तुत करने योग्य निर्माण" समस्या के दायरे से बाहर है।

आउट-ऑफ-बैंड संगतता जानकारी यह दर्शाने के लिए प्रस्तावित है कि ज्ञान कैसे विकसित होता है: रिलीज़ के समय कोई असंगति ज्ञात नहीं थी, लेकिन फिर यह स्पष्ट हो गया और पहले से जारी संस्करणों के बारे में अतिरिक्त जानकारी प्रकाशित की गई। परिभाषा के अनुसार आईएमएचओ इस दृष्टिकोण में बदलाव की ओर जाता है कि निर्भरता कैसे खींची जाती है, अन्यथा यह असंगतता की जानकारी क्यों निकालती है?

@redbaron @natefinch

असंगति जानकारी का मुद्दा पुस्तकालयों के लेखकों के लिए अपने उपयोगकर्ताओं के लिए असंगति जानकारी को संप्रेषित करना है। क्या उस जानकारी का निर्माण या रिलीज के समय उपयोग किया जाता है, यह एक अलग सवाल है।

वीजीओ के मामले में, वर्तमान विचार केवल चेतावनियां (या संभावित रूप से क्रोक) प्रदर्शित करना है। लेकिन विशेष रूप से इसे इस्तेमाल किए गए संस्करणों की पसंद को प्रभावित नहीं करने देना है (क्योंकि इसके लिए SAT को हल करने की आवश्यकता होगी)। तो यह वास्तव में कोई फर्क नहीं पड़ता, आप इसे या तो या दोनों में उपयोग कर सकते हैं और यह दोहराव की संपत्ति को बनाए रखते हुए अपने कर्तव्य को ठीक से पूरा करेगा।

dep में, यह जानकारी केवल रिलीज़ के समय उपयोग की जाती है और फिर लॉक फ़ाइल में दर्ज की जाती है, जिसका उपयोग बिल्ड समय पर किया जाता है। तो ऐसा लगता है कि हम वैसे भी रिलीज-टाइम उपयोग "काफी अच्छा" पर विचार कर रहे हैं, कम से कम जब यह vgo बनाम dep की चिंताओं की बात आती है।

मुझे अभी भी नहीं लगता कि हमें वास्तव में अभी उन सवालों के जवाब देने हैं।

[1] व्यक्तिगत रूप से, मैं तर्क दूंगा कि रिलीज के समय इसका उपयोग करना और केवल अगर -v का निर्माण समय पर उपयोग किया जाता है, तो बेहतर है, क्योंकि उपयोगकर्ता को यह तय नहीं करना चाहिए कि चेतावनी कार्रवाई योग्य है या नहीं।

@rsc ने लिखा:

अनुवर्ती कार्रवाई के लिए, एक बार जब हमने संस्करण और वीजीओ स्थापित कर लिया है, तो हम पूरी तरह से एक नया godoc.org (शायद एक अलग नाम) चाहते हैं जो संकुल के बारे में अतिरिक्त जानकारी रिकॉर्ड करता है, जानकारी जिसे गो कमांड परामर्श कर सकता है। और उस जानकारी में से कुछ जोड़ी-वार असंगति होगी कि गो कमांड किसी विशेष निर्माण में चेतावनियों या त्रुटियों के रूप में रिपोर्ट कर सकता है (यानी, क्षति की रिपोर्ट करना, इसके आसपास काम करके इसे छिपाने की कोशिश नहीं करना)।

मैं सोच रहा हूं कि जोड़ी-वार असंगतता रिकॉर्ड करना आवश्यक है या नहीं। जिस तरह से मैं इसे वर्तमान में देखता हूं वह यह है कि मॉड्यूल ए @ वीएन और मॉड्यूल बी @ वीएम के बीच कोई असंगतता वास्तव में है क्योंकि बी ने कुछ संस्करण वीएल से असंगत परिवर्तन किया है जहां एल <एम।

यदि मॉड्यूल बी ने असंगत परिवर्तन नहीं किया है, तो मॉड्यूल ए में बस एक बग है। अगर ऐसा होता है, तो मुद्दा बी के बारे में ही है, न कि ए और बी की जोड़ी के बारे में।

इसलिए आईएसटीएम कि मॉड्यूल मेटाडेटा का कोई भी सार्वजनिक भंडार अपने पिछले संस्करणों के साथ किसी भी मॉड्यूल की केवल असंगतताओं को रिकॉर्ड कर सकता है, जो समस्या को और अधिक सुगम बना सकता है। ये असंगतता रिपोर्ट बग रिपोर्ट से काफी मिलती-जुलती हैं, हालांकि इनका समाधान नहीं किया जा सकता क्योंकि एक बार संस्करण प्रकाशित हो जाने के बाद, इसे बदला नहीं जा सकता है।

जब आप अपने मॉड्यूल संस्करणों को अपग्रेड करते हैं, तो गो टूल मेटाडेटा पर विचार कर सकता है और ऐसे संस्करण पर विचार करने से इंकार कर सकता है जो वर्तमान में चुने गए किसी भी संस्करण के साथ असंगत है। मुझे लगता है कि यह SAT को हल करने की आवश्यकता से बचा जाता है। यह यह भी तय कर सकता है कि किसी दिए गए मॉड्यूल में बहुत अधिक असंगतता रिपोर्ट हैं और इसे निर्भरता के रूप में जोड़ने से इंकार कर सकते हैं।

प्रपत्र के टुपल्स का एक सेट ( मॉड्यूल , पुराना संस्करण, नया संस्करण , विवरण ) पर्याप्त हो सकता है।

गो टूल मेटाडेटा पर विचार कर सकता है और ऐसे संस्करण पर विचार करने से इंकार कर सकता है जो वर्तमान में चुने गए किसी भी संस्करण के साथ असंगत है

बेशक, यह तब काम नहीं करता जब आप कई निर्भरताएँ जोड़ रहे होते हैं, जो उनके बीच परस्पर असंगत संस्करणों का उपयोग करने की आवश्यकता होती है, क्योंकि नए संस्करण मौजूदा मॉड्यूल का हिस्सा नहीं हैं, लेकिन एक उचित अनुमानी उपलब्ध हो सकता है। यह महत्वपूर्ण AFAICS नहीं है, क्योंकि निर्भरता अपेक्षाकृत कम ही जोड़ी जानी चाहिए ।

मुझे चिंता है कि go release इस चर्चा का "पर्याप्त रूप से स्मार्ट कंपाइलर" बन रहा है। गो 1.11/12 में उपयोगकर्ता go release से क्या उम्मीद कर सकते हैं? मुझे लगता है कि इससे फर्क पड़ता है कि एमवीएस/एसआईवी के आसपास क्या उचित अपेक्षाएं हैं।

ऊर्जा के लिए धन्यवाद, आप में से बहुत से लोग गो और विशेष रूप से इस प्रस्ताव को लेकर आए हैं।

प्रस्ताव प्रक्रिया का पहला लक्ष्य "[एम] यह सुनिश्चित करना है कि प्रस्तावों को स्पष्ट उत्तर के साथ उचित, निष्पक्ष, समयबद्ध, रिकॉर्ड किया गया मूल्यांकन मिले।" इस प्रस्ताव पर विस्तार से चर्चा हुई और हमने चर्चा का सारांश प्रकाशित किया। छह सप्ताह और बहुत चर्चा के बाद, प्रस्ताव समीक्षा समिति - मध्यस्थ के रूप में कदम रखते हुए क्योंकि मैंने प्रस्ताव लिखा था - प्रस्ताव को स्वीकार कर लिया।

एक एकल गिटहब मुद्दा एक व्यापक चर्चा के लिए एक कठिन जगह है, क्योंकि गिटहब में वार्तालाप के विभिन्न पहलुओं के लिए कोई थ्रेडिंग नहीं है और अब सभी टिप्पणियों को प्रदर्शित भी नहीं करता है। इस तरह की चर्चा का एकमात्र तरीका चर्चा सारांश की सक्रिय अवधि है। जब तक प्रस्ताव स्वीकार किया गया तब तक सारांश भी बोझिल हो गया था।

अब जबकि प्रस्ताव स्वीकार कर लिया गया है, यह मुद्दा अब चर्चा के लिए सही जगह नहीं है, और हम अब सारांश को अपडेट नहीं कर रहे हैं। इसके बजाय, कृपया अपनी समस्याओं के बारे में नए, लक्षित मुद्दे दर्ज करें या परिवर्तनों के लिए ठोस सुझाव दें, ताकि हम प्रत्येक विशिष्ट विषय पर केंद्रित चर्चा कर सकें। कृपया इन नए मुद्दों के आगे "x/vgo:" लगाएं। यदि आप नए अंक के पाठ में #24301 का उल्लेख करते हैं, तो इसे अन्य लोगों को खोजने के लिए यहां क्रॉस-रेफर किया जाएगा।

एक अंतिम बिंदु यह है कि प्रस्ताव को स्वीकार करने का अर्थ है विचार को स्वीकार करना, न कि प्रोटोटाइप कार्यान्वयन बग और सभी। काम करने के लिए अभी भी विवरण हैं और बग को ठीक करना है, और हम इसे एक साथ करना जारी रखेंगे।

आपके सहयोग के लिए पुन: धन्यवाद।

अभी और काम किया जाना है ( मॉड्यूल लेबल देखें) लेकिन इस मुद्दे में प्रस्तावित प्रारंभिक मॉड्यूल कार्यान्वयन मुख्य पेड़ के लिए प्रतिबद्ध है, इसलिए मैं इस मुद्दे को बंद कर रहा हूं।