Go: प्रस्ताव: cmd/go: बायनेरिज़ में स्थिर संपत्ति (फ़ाइलें) एम्बेड करने का समर्थन

यह विचार करने योग्य है कि क्या embedglob को एक पूर्ण फ़ाइल ट्री का समर्थन करना चाहिए, शायद कुछ यूनिक्स शेल द्वारा समर्थित ** सिंटैक्स का उपयोग करके।

कुछ लोगों को http.FileServer का उपयोग करके HTTP के साथ एम्बेडेड संपत्तियों की सेवा करने की क्षमता की आवश्यकता होगी।

मैं व्यक्तिगत रूप से या तो mjibson/esc (जो ऐसा करता है) का उपयोग करता हूं या कुछ मामलों में मेरी अपनी फ़ाइल एम्बेडिंग कार्यान्वयन जो अद्वितीय पथ बनाने के लिए फ़ाइलों का नाम बदलता है और मूल पथ से नए पथों में एक नक्शा जोड़ता है, जैसे "/js/bootstrap.min.js": "/js/bootstrap.min.827ccb0eea8a706c4c34a16891f84e7b.js" । फिर आप इस मानचित्र का उपयोग इस तरह के टेम्प्लेट में कर सकते हैं: href="{{ static_path "/css/bootstrap.min.css" }}" ।

मुझे लगता है कि इसका एक परिणाम यह होगा कि यह पता लगाना गैर-तुच्छ होगा कि प्रोग्राम बनाने के लिए कौन सी फाइलें आवश्यक हैं।

//go:embed दृष्टिकोण जटिलता का एक और स्तर भी पेश करता है। कोड को टाइप करने के लिए आपको जादुई टिप्पणियों को पार्स करना होगा। "एम्बेड पैकेज" दृष्टिकोण स्थिर विश्लेषण के लिए मित्रवत लगता है।

(यहाँ बस ज़ोर से बोल रहा हूँ।)

@ओपेनोटा ,

http.FileServer का उपयोग करके HTTP के साथ एम्बेडेड संपत्तियों की सेवा करने की क्षमता की आवश्यकता होगी।

हां, ऊपर दिया गया पहला लिंक एक पैकेज है जिसे मैंने लिखा था ( 2011 में, गो 1 से पहले ) और अभी भी उपयोग करता है, और यह http.FileServer: https://godoc.org/perkeep.org/pkg/fileembed#Files.Open का उपयोग करने का समर्थन करता है।

@सेस्पारे ,

// गो: एम्बेड दृष्टिकोण जटिलता का एक और स्तर भी पेश करता है। कोड को टाइप करने के लिए आपको जादुई टिप्पणियों को पार्स करना होगा। "एम्बेड पैकेज" दृष्टिकोण स्थिर विश्लेषण के लिए मित्रवत लगता है।

हाँ, अच्छा बिंदु। पैकेज का उपयोग करने के लिए यह एक बहुत मजबूत तर्क है। यह इसे और अधिक पठनीय और दस्तावेज़ योग्य बनाता है, क्योंकि हम इसे cmd/go के दस्तावेज़ों में गहराई के बजाय नियमित गोडोक के साथ दस्तावेज कर सकते हैं।

@bradfitz - क्या आप इसे https://github.com/golang/go/issues/3035 बंद करना चाहते हैं?

@agnivade ,

यदि हम मैजिक पैकेज के साथ जाते हैं, तो हम यह सुनिश्चित करने के लिए अनएक्सपोर्टेड टाइप ट्रिक का उपयोग कर सकते हैं कि कॉलर्स कंपाइल-टाइम कॉन्स्टेंट को तर्क के रूप में पास करें :

(यहाँ संदर्भित रणनीति है: https://groups.google.com/forum/#!topic/golang-nuts/RDA9Hag8RZw/discussion)

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

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

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

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

@ianlancetaylor , मुझे लगता है कि @AlexRouSg जो अंतर बना रहा था, वह वैश्विक []byte s (अनपेजेबल, संभावित रूप से लिखने योग्य मेमोरी) के रूप में प्रदान की गई फाइलों के बीच था, जो एक ईएलएफ सेक्शन का केवल-पढ़ने, ऑन-डिमांड व्यू प्रदान करने के बीच था। सामान्य रूप से डिस्क पर (निष्पादन में) को लाइव, एक के माध्यम से की तरह Open कॉल कि रिटर्न एक *io.SectionReader । (मैं http.File या http.FileSystem में cmd/go या रनटाइम में बेक नहीं करना चाहता... net/http एक एडेप्टर प्रदान कर सकता है।)

@bradfitz दोनों http.File ही एक इंटरफ़ेस है जिसमें http पैकेज पर कोई तकनीकी निर्भरता नहीं है। किसी भी Open विधि के लिए उस इंटरफ़ेस के अनुरूप कार्यान्वयन प्रदान करना एक अच्छा विचार हो सकता है, क्योंकि Stat और Readdir दोनों ही ऐसी संपत्तियों के लिए काफी उपयोगी हैं।

@urandom , हालांकि, "http.File" नाम (https://play.golang.org/p/-r3KjG1Gp-8) का उल्लेख किए बिना, यह http.FileSystem को लागू नहीं कर सका।

@robpike और मैंने इस साल पहले ऐसा करने के प्रस्ताव के माध्यम से बात की थी (इससे पहले कि कोई प्रस्ताव प्रक्रिया थी) और कभी भी कुछ भी करने से पीछे नहीं

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

एक युगल विचार:

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

किसी भी तरह, यह /etc/shadow या .git एम्बेड करने को रोकता है। न तो मॉड्यूल ज़िप में शामिल किया जा सकता है।

सामान्य तौर पर, मैं गो कमांड के दायरे को बहुत अधिक विस्तारित करने के बारे में चिंतित हूं। हालाँकि, तथ्य यह है कि इस समस्या के बहुत सारे समाधान हैं, इसका मतलब है कि शायद एक आधिकारिक समाधान होना चाहिए।

मैं go_embed_data और go-bindata (जिनमें से कई कांटे हैं) से परिचित हूं, और ऐसा लगता है कि उन उपयोग मामलों को कवर किया गया है। क्या ऐसी कोई महत्वपूर्ण समस्या है जिसे अन्य लोग हल करते हैं जो इसमें शामिल नहीं हैं?

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

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

embed ui "./ui/build"

func main() {
  file, err := ui.Open("version.txt")
  if err != nil {
    panic(err)
  }
  version, err = ioutil.ReadAll(file)
  if err != nil {
    panic(err)
  }
  file.Close()

  log.Printf("UI Version: %s\n", bytes.TrimSpace(version))
  http.ListenAndServe(":8080", http.EmbeddedDir(ui))
}

संपादित करें: आपने मुझे इसे हरा दिया, @jayconrod।

https://github.com/golang/go/issues/35950#issuecomment -561703346 पर विस्तार करने के लिए, उजागर एपीआई के बारे में एक पहेली है। डेटा को उजागर करने के स्पष्ट तरीके हैं []byte , string , और Read -ish इंटरफेस।

विशिष्ट मामला यह है कि आप चाहते हैं कि एम्बेडेड डेटा अपरिवर्तनीय हो। हालांकि, []byte (जिसमें io.Reader , io.SectionReader , आदि शामिल हैं) को उजागर करने वाले सभी इंटरफेस को या तो (1) एक प्रतिलिपि बनाना चाहिए, (2) उत्परिवर्तन की अनुमति दें, या (3) []byte होने के बावजूद अपरिवर्तनीय हो। डेटा को string s के रूप में उजागर करने से यह हल हो जाता है, लेकिन एक एपीआई की कीमत पर जिसे अक्सर किसी भी तरह से कॉपी करने की आवश्यकता होती है, क्योंकि बहुत सारे कोड जो एम्बेडेड फ़ाइलों का उपभोग करते हैं, उन्हें अंततः एक या दूसरे तरीके से बाइट स्लाइस की आवश्यकता होती है।

मैं मार्ग (3) का सुझाव दूंगा: []byte होने के बावजूद अपरिवर्तनीय हो। आप बैकिंग सरणी के लिए केवल पढ़ने के लिए प्रतीक का उपयोग करके इसे सस्ते में लागू कर सकते हैं। यह आपको []byte और string के समान डेटा को सुरक्षित रूप से उजागर करने देता है; डेटा को बदलने का प्रयास विफल हो जाएगा। संकलक अपरिवर्तनीयता का लाभ नहीं उठा सकता है, लेकिन यह बहुत बड़ा नुकसान नहीं है। यह ऐसा कुछ है जो टूलचेन समर्थन तालिका में ला सकता है (जहां तक ​​​​मुझे पता है) मौजूदा कोडजन पैकेजों में से कोई भी नहीं करता है।

(एक तृतीय पक्ष कोडजन पैकेज DATA प्रतीकों वाली एक सामान्य असेंबली फ़ाइल उत्पन्न करके ऐसा कर सकता है जिसे केवल पढ़ने के लिए चिह्नित किया गया है, और फिर उन प्रतीकों को string के रूप में उजागर करने वाली छोटी आर्क-विशिष्ट असेंबली फ़ाइलें s और []byte s। मैंने CL १६३७४७ को विशेष रूप से इस उपयोग के मामले को ध्यान में रखते हुए लिखा था, लेकिन इसे किसी भी कोडजन पैकेज में एकीकृत करने के लिए कभी नहीं मिला।)

मुझे यकीन नहीं है कि आप अपरिवर्तनीयता के बारे में क्या बात कर रहे हैं। io.Reader पहले से ही अपरिवर्तनीयता को लागू करता है। वह पूरी बात है। जब आप Read(buf) कॉल करते हैं, तो यह डेटा को _you_ प्रदान किए गए बफ़र में कॉपी करता है। बदल रहा है buf उसके बाद के आंतरिक भागों पर शून्य प्रभाव पड़ता है io.Reader ।

मैं @DeedleFake से सहमत हूं। मैं जादू []byte सरणी बैकिंग्स के साथ गेम नहीं खेलना चाहता हूं। बाइनरी से उपयोगकर्ता द्वारा प्रदत्त बफर में कॉपी करना ठीक है।

यहां बस एक और शिकन - मेरे पास एक अलग परियोजना है जो डीटी्रेस स्रोत कोड (एम्बेडेड) का उपयोग करती है। यह \n और \r\n के बीच अंतर के प्रति संवेदनशील है। (हम तर्क दे सकते हैं कि यह डीटी्रेस में एक गूंगा बात है या नहीं - यह बिंदु के बगल में है और आज की स्थिति है।)

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

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

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

एक नया आरक्षित निर्देशिका नाम पेश करने में बहुत देर हो सकती है, जितना मैं चाहूं।
(2014 में बहुत देर नहीं हुई थी, लेकिन शायद अब बहुत देर हो चुकी है।)
तो किसी प्रकार की ऑप्ट-इन टिप्पणी आवश्यक हो सकती है।

मान लीजिए कि हम एक प्रकार का रनटाइम परिभाषित करते हैं। फ़ाइलें। तब आप लिखने की कल्पना कर सकते हैं:

//go:embed *.html (or static/* etc)
var files runtime.Files

और फिर रनटाइम पर आप केवल फाइल को कॉल करते हैं। डेटा के साथ interface { io.ReadSeeker; io.ReaderAt } वापस पाने के लिए खोलें। ध्यान दें कि var निर्यात नहीं किया गया है, इसलिए एक पैकेज दूसरे पैकेज की एम्बेडेड फ़ाइलों में ग्रबिंग के आसपास नहीं जा सकता है।

नाम टीबीडी लेकिन जहां तक ​​​​ऐसा लगता है कि तंत्र पर्याप्त होना चाहिए, और मुझे नहीं लगता कि इसे सरल कैसे बनाया जाए। (सरलीकरण निश्चित रूप से स्वागत है!)

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

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

आम तौर पर मूंगिंग के संबंध में - मैं एक ऐसे समाधान की कल्पना कर सकता हूं जहां कोई इंटरफ़ेस का कार्यान्वयन प्रदान करता है (एक तरफ रीडर () की तरह कुछ, और दूसरी तरफ फ़ाइल प्राप्त करने के लिए कुछ - शायद io.Reader के साथ तत्काल हो सकता है फ़ाइल से ही) -- जिसे गो cmd बनाएगा और एम्बेड करने से पहले फ़ाइल को प्रीफ़िल्टर करने के लिए चलाएगा। फिर लोग जो चाहें फ़िल्टर प्रदान कर सकते हैं। मुझे लगता है कि कुछ लोग अर्ध-मानक फ़िल्टर प्रदान करेंगे जैसे dos2unix कार्यान्वयन, संपीड़न इत्यादि। (शायद उन्हें भी श्रृंखलाबद्ध होना चाहिए।)

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

एक नया आरक्षित निर्देशिका नाम पेश करने में बहुत देर हो सकती है, जितना मैं चाहूं। [...] किसी प्रकार की ऑप्ट-इन टिप्पणी आवश्यक हो सकती है।

यदि फ़ाइलें केवल एक विशेष पैकेज के माध्यम से पहुंच योग्य हैं, तो runtime/embed कहें, तो उस पैकेज को आयात करना ऑप्ट-इन सिग्नल हो सकता है।

io.Read दृष्टिकोण ऐसा लगता है कि यह strings.Contains (जैसे cmd/go/internal/cfg ) जैसे अवधारणात्मक-सरल रैखिक संचालन के लिए महत्वपूर्ण ओवरहेड (प्रतिलिपि और स्मृति पदचिह्न दोनों के संदर्भ में) जोड़ सकता है या , गंभीर रूप से, template.Parse ।

उन उपयोग-मामलों के लिए, कॉलर को यह चुनने की अनुमति देना आदर्श लगता है कि पूरे ब्लॉब को (संभवतः मेमोरी-मैप्ड) string या io.ReaderAt रूप में माना जाए या नहीं।

यह सामान्य runtime.Files दृष्टिकोण के साथ संगत लगता है, हालांकि: runtime.Files.Open से लौटाई गई चीज़ में ReadString() string विधि हो सकती है जो स्मृति-मैप किए गए प्रतिनिधित्व को लौटाती है।

किसी प्रकार की ऑप्ट-इन टिप्पणी आवश्यक हो सकती है।

हम ऐसा go संस्करण के साथ go.mod फ़ाइल में कर सकते हैं। 1.15 (या जो भी) से पहले static उपनिर्देशिका में एक पैकेज होगा, और 1.15 या उच्चतर पर इसमें एम्बेडेड संपत्तियां होंगी।

(हालांकि, यह वास्तव में GOPATH मोड में मदद नहीं करता है।)

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

जबकि मैं सादगी के लिए अभियान की सराहना करता हूं, हमें यह भी सुनिश्चित करना चाहिए कि हम उपयोगकर्ताओं की जरूरतों को पूरा कर रहे हैं।

https://tech.townsourced.com/post/embedding-static-files-in-go/#comparison सपोर्ट कंप्रेशन पर सूचीबद्ध 14 में से 12 टूल, जो बताता है कि यह एक बहुत ही सामान्य आवश्यकता है।

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

प्रारंभिक प्रस्ताव में सूचीबद्ध तीन लक्ष्य थे:

• जेनरेट की गई फाइलों में चेक इन न करें
• गो इंस्टाल करें / गो बिल्ड करें एम्बेडिंग स्वचालित रूप से करें
• जहां उपयुक्त हो, बाइनरी में संपीड़ित संपत्ति को स्टोर करें

यदि हम इनमें से दूसरे को "एम्बेडिंग के लिए एक अलग उपकरण की आवश्यकता नहीं है" के रूप में पढ़ते हैं, तो संपीड़ित फ़ाइलों का प्रत्यक्ष या अप्रत्यक्ष रूप से समर्थन नहीं करना इन तीनों लक्ष्यों को पूरा करने में विफल रहता है।

क्या इसे पैकेज स्तर की आवश्यकता है? मॉड्यूल स्तर एक बेहतर ग्रैन्युलैरिटी लगता है क्योंकि सबसे अधिक संभावना है कि एक मॉड्यूल = एक प्रोजेक्ट।

चूंकि इस निर्देशिका में गो कोड नहीं होगा† क्या यह _static जैसा कुछ हो सकता है?

या, यदि ऐसा है, तो इसे मनमाना बाइट्स के रूप में माना जाएगा जिसका नाम संकलित करने के लिए गो कोड के बजाय ".go" में समाप्त होता है

यदि यह एक विशेष निर्देशिका है, तो तर्क उस निर्देशिका पेड़ में कुछ भी और सबकुछ खत्म कर सकता है। मैजिक एम्बेड पैकेज आपको एसेट ट्री की उपनिर्देशिका में फ़ाइल खोलने के लिए embed.Open("img/logo.svg") जैसा कुछ करने दे सकता है।

तार काफी अच्छे लगते हैं। उन्हें आसानी से []byte में कॉपी किया जा सकता है या Reader में परिवर्तित किया जा सकता है। init दौरान फैनसीयर एपीआई प्रदान करने और चीजों को संभालने के लिए कोड जनरेशन या पुस्तकालयों का उपयोग किया जा सकता है। इसमें डीकंप्रेसन या http.FileSystem बनाना शामिल हो सकता है।

क्या विंडोज़ के पास संपत्तियों को एम्बेड करने के लिए कोई विशेष प्रारूप नहीं है। क्या इसका उपयोग विंडोज़ निष्पादन योग्य बनाते समय किया जाना चाहिए? यदि हां, तो क्या प्रदान किए जा सकने वाले कार्यों के प्रकारों पर इसका कोई प्रभाव पड़ता है?

गिटफ्स को मत भूलना

• https://github.com/posener/gitfs

क्या कोई कारण है कि यह गो बिल्ड / लिंक का हिस्सा नहीं हो सकता है ... उदाहरण के लिए go build -embed example=./path/example.txt और कुछ पैकेज जो उस तक पहुंच को उजागर करते हैं (उदाहरण के लिए embed.File("example") का उपयोग करने के बजाय go:embed ?

हालांकि इसके लिए आपको अपने कोड में एक स्टब की आवश्यकता है

@egonelbre go build -embed साथ समस्या यह है कि सभी उपयोगकर्ताओं को इसे ठीक से उपयोग करने की आवश्यकता होगी। यह पूरी तरह से पारदर्शी और स्वचालित होना चाहिए; मौजूदा go install या go get कमांड सही काम करना बंद नहीं कर सकते।

@bradfitz मैं https://github.com/markbates/pkger की सिफारिश करूंगा। यह फाइलों के साथ काम करने के लिए मानक पुस्तकालय एपीआई का उपयोग करता है।

func run() error {
    f, err := pkger.Open("/public/index.html")
    if err != nil {
        return err
    }
    defer f.Close()

    info, err := f.Stat()
    if err != nil {
        return err
    }

    fmt.Println("Name: ", info.Name())
    fmt.Println("Size: ", info.Size())
    fmt.Println("Mode: ", info.Mode())
    fmt.Println("ModTime: ", info.ModTime())

    if _, err := io.Copy(os.Stdout, f); err != nil {
        return err
    }
    return nil
}

या हो सकता है कि कुछ बिल्ड टैग या झंडे इसके बजाय रनटाइम पर काम करने के लिए वापस आ जाएं। परकीप (ऊपर लिंक किया गया) में एक ऐसी विधा है, जो वृद्धिशील विकास को गति देने के लिए अच्छा है जहाँ आप एक बड़े बाइनरी को जोड़ने की परवाह नहीं करते हैं।

mjibson/esc यह भी करता है, और वेबएप विकसित करते समय यह जीवन की गुणवत्ता में एक बड़ा सुधार है; आप न केवल लिंकिंग समय बचाते हैं बल्कि एप्लिकेशन को पुनरारंभ करने से भी बचते हैं, जिसमें वेबएप के कार्यान्वयन के आधार पर आपके परिवर्तनों का परीक्षण करने के लिए पर्याप्त समय और/या अतिरिक्त चरणों को दोहराने की आवश्यकता हो सकती है।

मौजूदा हालात से परेशानी :

• गो का उपयोग करना: जनरेट-आधारित समाधान प्रत्येक फ़ाइल की दूसरी (और थोड़ी बड़ी) प्रति के साथ गिट इतिहास को फुलाता है।

लक्ष्य:

• जेनरेट की गई फाइलों में चेक इन न करें

खैर, जेनरेट की गई फ़ाइलों को .gitignore फ़ाइल या समकक्ष में जोड़कर इस भाग को आसानी से हल किया जा सकता है। मैंने हमेशा यही किया...

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

मैं यहाँ सिर्फ विचार-मंथन कर रहा हूँ / जोर से सोच रहा हूँ ... लेकिन मुझे वास्तव में प्रस्तावित विचार समग्र रूप से पसंद है। मैं

इसके अतिरिक्त, क्योंकि //go:generate निर्देशों पर स्वचालित रूप से नहीं चला go build के व्यवहार go build थोड़ा असंगत लग सकता है: //go:embed स्वचालित रूप से कार्य करेगी, लेकिन के लिए //go:generate आपको मैन्युअल रूप से go generate चलाना होगा। ( //go:generate पहले से ही go get प्रवाह को तोड़ सकता है यदि यह निर्माण के लिए आवश्यक .go फाइलें उत्पन्न करता है)।

//go:generate पहले से ही गो गेट फ्लो को तोड़ सकता है यदि यह बिल्ड के लिए आवश्यक .go फाइलें बनाता है

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

@bradfitz इसे http.FileSystem को लागू करने की आवश्यकता नहीं है। यदि कार्यान्वयन एक प्रकार प्रदान करता है जो http.File को लागू करता है, तो यह किसी के लिए भी तुच्छ होगा, जिसमें Open फ़ंक्शन के चारों ओर एक आवरण प्रदान करने के लिए stdlib http पैकेज भी शामिल है, इस प्रकार को http.File परिवर्तित करना http.FileSystem अनुरूप होने के लिए

@andreynering //go:generate और //go:embed हालांकि बहुत अलग हैं। यह तंत्र निर्माण समय पर निर्बाध रूप से हो सकता है क्योंकि यह मनमाना कोड नहीं चलाएगा। मेरा मानना ​​​​है कि यह समान बनाता है कि कैसे cgo go build हिस्से के रूप में कोड उत्पन्न कर सकता है।

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

जबकि मैं सादगी के लिए अभियान की सराहना करता हूं, हमें यह भी सुनिश्चित करना चाहिए कि हम उपयोगकर्ताओं की जरूरतों को पूरा कर रहे हैं।

https://tech.townsourced.com/post/embedding-static-files-in-go/#comparison सपोर्ट कंप्रेशन पर सूचीबद्ध 14 में से 12 टूल, जो बताता है कि यह एक बहुत ही सामान्य आवश्यकता है।

मुझे यकीन नहीं है कि मैं इस तर्क से सहमत हूं।

अन्य पुस्तकालयों द्वारा किया गया संपीड़न इसे इस प्रस्ताव में जोड़ने से अलग है क्योंकि वे बाद के निर्माण पर प्रदर्शन को कम नहीं करेंगे क्योंकि विकल्प आम तौर पर निर्माण समय के बजाय निर्माण से पहले उत्पन्न होते हैं।

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

ऐसा नहीं है कि फ़ाइल एम्बेडिंग संपीड़न के बिना बेकार होगी, संपीड़न एक अच्छा-से-बाइनरी आकार को 100 एमबी से 50 एमबी तक कम करना है - जो कि बहुत अच्छा है, लेकिन अधिकांश अनुप्रयोगों के लिए कार्यक्षमता के लिए एक स्पष्ट डीलब्रेकर भी नहीं है जिसके बारे में मैं सोच सकता हूं . विशेष रूप से तब नहीं जब अधिकांश "भारी" संपत्ति जेपीईजी या पीएनजी जैसी फाइलें हैं जो पहले से ही बहुत अच्छी तरह से संपीड़ित हैं।

संपीड़न को अभी के लिए बाहर रखने और इसे जोड़ने के बारे में क्या है यदि यह वास्तव में बहुत से लोगों द्वारा याद किया जाता है? (और अनुचित लागत के बिना किया जा सकता है)

ऊपर @sakjur की टिप्पणी में जोड़ने के लिए: संपीड़न मुझे ऑर्थोगोनल लगता है। मैं आम तौर पर एक संपूर्ण बाइनरी या रिलीज संग्रह को संपीड़ित करना चाहता हूं, न कि केवल संपत्तियां। विशेष रूप से जब गो बायनेरिज़ बिना किसी संपत्ति के दसियों मेगाबाइट में आसानी से प्रवेश कर सकते हैं।

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

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

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

ऐसा नहीं है कि फ़ाइल एम्बेडिंग संपीड़न के बिना बेकार होगी, संपीड़न एक अच्छा-से-बाइनरी आकार को 100 एमबी से 50 एमबी तक कम करना है - जो कि बहुत अच्छा है, लेकिन अधिकांश अनुप्रयोगों के लिए कार्यक्षमता के लिए एक स्पष्ट डीलब्रेकर भी नहीं है जिसके बारे में मैं सोच सकता हूं .

कई गो डेवलपर्स (https://github.com/golang/go/issues/6853) के लिए बाइनरी आकार एक बड़ी बात है। गो विशेष रूप से बाइनरी आकार को कम करने के लिए डीडब्ल्यूएआरएफ डीबग जानकारी को संपीड़ित करता है, भले ही यह समय लिंक करने की लागत पर आता है (https://github.com/golang/go/issues/11799, https://github.com/golang/go/ मुद्दे/26074)। यदि बाइनरी आकार को आधे में काटने का एक आसान तरीका था, तो मुझे लगता है कि डेवलपर्स उस अवसर पर छलांग लगाएंगे (हालांकि मुझे संदेह है कि यहां लाभ लगभग उतना ही महत्वपूर्ण होगा)।

यह वास्तव में GOPATH मोड में मदद नहीं करता है, हालांकि

हो सकता है, यदि आप GOPATH मोड में हैं, तो यह सुविधा केवल इसलिए लागू नहीं होती है क्योंकि मुझे लगता है कि Go टीम हमेशा के लिए GOPATH के लिए फीचर समानता करने की योजना नहीं बना रही है? पहले से ही ऐसी विशेषताएं हैं जो GOPATH में समर्थित नहीं हैं (जैसे सुरक्षा w/चेकसम डीबी, प्रॉक्सी सर्वर के माध्यम से निर्भरता डाउनलोड करना, और अर्थपूर्ण आयात संस्करण)

जैसा कि @bcmills ने उल्लेख किया है, go.mod फ़ाइल में स्थिर निर्देशिका नाम होना इस सुविधा को गो 1.15 में पेश करने का एक शानदार तरीका है क्योंकि यह सुविधा स्वचालित रूप से go.mod फ़ाइलों में बंद हो सकती है जिसमें <=go1.14 क्लॉज होता है।

उस ने कहा, इसका मतलब यह भी है कि उपयोगकर्ताओं को मैन्युअल रूप से लिखना होगा कि स्थिर निर्देशिका पथ क्या है।

मुझे लगता है कि विक्रेता निर्देशिका और _test.go सम्मेलन इस बात के महान उदाहरण हैं कि उन्होंने गो के साथ कैसे काम किया और उन दो सुविधाओं को बहुत आसान बना दिया।

मुझे याद नहीं है कि बहुत से लोग विक्रेता निर्देशिका नाम को अनुकूलित करने के विकल्प का अनुरोध कर रहे हैं या _test.go सम्मेलन को किसी और चीज़ में बदलने की क्षमता रखते हैं। लेकिन अगर गो कभी भी _test.go फीचर पेश नहीं करता है, तो आज गो में परीक्षण बहुत अलग दिखाई देगा।

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

संभावित रूप से कम-टकराव वाले नामों के उदाहरण:

• _embed - _test.go सम्मेलन का पालन करता है
• go_binary_assets
• .gobin .git सम्मेलन का पालन करता है
• runtime_files - ताकि यह runtime.Files संरचना से मेल खाए

अंत में, vendor निर्देशिका को Go 1.5 में जोड़ा गया। सू, शायद अब एक नया सम्मेलन जोड़ना इतना बुरा नहीं है? मैं

मुझे लगता है कि इसे mmap-readonly []byte बेनकाब करना चाहिए। निष्पादन योग्य से पृष्ठों तक कच्ची पहुंच, आवश्यकतानुसार ओएस द्वारा पृष्ठांकित। उसके ऊपर बाकी सब कुछ प्रदान किया जा सकता है, केवल bytes.NewReader ।

यदि यह किसी कारण से अस्वीकार्य है, तो कृपया ReaderAt न कि केवल ReadSeeker ; उत्तरार्द्ध पूर्व से निर्माण के लिए छोटा है, लेकिन दूसरा तरीका उतना अच्छा नहीं है: इसे एकल ऑफसेट की रक्षा करने और प्रदर्शन को बर्बाद करने के लिए एक म्यूटेक्स की आवश्यकता होगी।

ऐसा नहीं है कि फ़ाइल एम्बेडिंग संपीड़न के बिना बेकार होगी, संपीड़न एक अच्छा-से-बाइनरी आकार को 100 एमबी से 50 एमबी तक कम करना है - जो कि बहुत अच्छा है, लेकिन अधिकांश अनुप्रयोगों के लिए कार्यक्षमता के लिए एक स्पष्ट डीलब्रेकर भी नहीं है जिसके बारे में मैं सोच सकता हूं .

कई गो डेवलपर्स (#6853) के लिए बाइनरी आकार एक बड़ी बात है। गो विशेष रूप से बाइनरी आकार को कम करने के लिए डीडब्ल्यूएआरएफ डीबग जानकारी को संपीड़ित करता है, भले ही यह लिंक समय (# 11799, # 26074) की लागत पर आता है। यदि बाइनरी आकार को आधे में काटने का एक आसान तरीका था, तो मुझे लगता है कि डेवलपर्स उस अवसर पर छलांग लगाएंगे (हालांकि मुझे संदेह है कि यहां लाभ लगभग उतना ही महत्वपूर्ण होगा)।

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

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

मेरा वर्तमान संपत्ति एम्बेडिंग टूल -tags dev साथ निर्मित होने पर संपत्ति फ़ाइलों से सामग्री लोड करता है। इस तरह के कुछ सम्मेलन शायद यहां भी उपयोगी होंगे; यह विकास चक्र को महत्वपूर्ण रूप से छोटा करता है जब उदाहरण के लिए एचटीएमएल या टेम्पलेट के साथ झुकाव।

यदि नहीं, तो कॉलर को इस निचले स्तर के तंत्र को कुछ *_dev.go और *_nodev.go रैपर के साथ लपेटना होगा और dev परिदृश्य के लिए गैर-एम्बेडेड लोडिंग को लागू करना होगा। कठिन भी नहीं है, लेकिन वह सड़क उपकरण के समान विस्फोट की ओर ले जाएगी जो इस मुद्दे पर पहली टिप्पणी में वर्णित है। उन उपकरणों को आज की तुलना में कम करना होगा, लेकिन वे फिर भी गुणा करेंगे।

मुझे लगता है कि गो मॉड्यूल के बाहर चलने पर -tags dev काम करने में विफल होना उचित होगा (यह पता नहीं लगा सकता कि संपत्ति कहां से लोड की जाए)।

केवल एक go tool embed बारे में क्या है जो इनपुट लेता है और कंप्यूटर द्वारा एम्बेडेड फाइलों के रूप में मान्यता प्राप्त एक विशेष प्रारूप में गो आउटपुट फाइलों का उत्पादन करता है जिसे तब runtime/emved या कुछ के माध्यम से एक्सेस किया जा सकता है। तब आप बस एक साधारण //go:generate gzip -o - static.txt | go tool embed -o static.go ।

बेशक, एक बड़ा नकारात्मक पहलू यह है कि आपको जेनरेट की गई फाइलों को प्रतिबद्ध करना होगा।

@DeedleFake इस मुद्दे की शुरुआत से हुई

गो का उपयोग करना: जनरेट-आधारित समाधान प्रत्येक फ़ाइल की दूसरी (और थोड़ी बड़ी) प्रति के साथ गिट इतिहास को फुलाता है।

वूप्स। कोई बात नहीं। माफ़ करना।

ऐसा नहीं है कि फ़ाइल एम्बेडिंग संपीड़न के बिना बेकार होगी, संपीड़न एक अच्छा-से-बाइनरी आकार को 100 एमबी से 50 एमबी तक कम करना है - जो कि बहुत अच्छा है, लेकिन अधिकांश अनुप्रयोगों के लिए कार्यक्षमता के लिए एक स्पष्ट डीलब्रेकर भी नहीं है जिसके बारे में मैं सोच सकता हूं .

कई गो डेवलपर्स (#6853) के लिए बाइनरी आकार एक बड़ी बात है। गो विशेष रूप से बाइनरी आकार को कम करने के लिए डीडब्ल्यूएआरएफ डीबग जानकारी को संपीड़ित करता है, भले ही यह लिंक समय (# 11799, # 26074) की लागत पर आता है। यदि बाइनरी आकार को आधे में काटने का एक आसान तरीका था, तो मुझे लगता है कि डेवलपर्स उस अवसर पर छलांग लगाएंगे (हालांकि मुझे संदेह है कि यहां लाभ लगभग उतना ही महत्वपूर्ण होगा)।

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

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

मैं इसे 15 प्रतिस्पर्धी मानकों में से एक के रूप में कहता हूं जब मैंने गोम्बेड लिखा

@tv42 ने लिखा:

मुझे लगता है कि इसे mmap-readonly []byte बेनकाब करना चाहिए। निष्पादन योग्य से पृष्ठों तक कच्ची पहुंच, आवश्यकतानुसार ओएस द्वारा पृष्ठांकित।

यह टिप्पणी आसानी से छूट जाती है और आश्चर्यजनक रूप से मूल्यवान है।

@ टीवी42 ,

मुझे लगता है कि इसे एमएमएपी-रीडोनली [] बाइट का पर्दाफाश करना चाहिए। निष्पादन योग्य से पृष्ठों तक कच्ची पहुंच, आवश्यकतानुसार ओएस द्वारा पृष्ठांकित। बाकी सब कुछ उसके ऊपर, केवल बाइट्स के साथ प्रदान किया जा सकता है। न्यू रीडर।

वह प्रकार जो पहले से केवल-पढ़ने के लिए है string । साथ ही: यह io.ReaderAt विपरीत एक आकार प्रदान करता है, और यह मानक पुस्तकालय पर निर्भर नहीं करता है। शायद यही हम बेनकाब करना चाहते हैं।

वह प्रकार जो पहले से केवल-पढ़ने के लिए है string ।

लेकिन पूरे पारिस्थितिकी तंत्र Write आदि पर काम करता है []byte । यह सरल व्यावहारिकता है। मुझे नहीं लगता कि केवल पढ़ने योग्य संपत्ति io.Writer.Write डॉक्स के कहने की तुलना में कोई समस्या है

राइट को अस्थायी रूप से भी स्लाइस डेटा को संशोधित नहीं करना चाहिए।

एक और संभावित नकारात्मक पक्ष यह है कि go:generate साथ निर्देशिका एम्बेड करते समय मैं git diff के आउटपुट की जांच कर सकता हूं और देख सकता हूं कि गलती से कोई फाइल है या नहीं। इस प्रस्ताव के साथ - ? शायद गो कमांड उन फाइलों की सूची को प्रिंट करेगा जो इसे एम्बेड कर रही हैं?

@tv42

लेकिन राइट आदि का पूरा इकोसिस्टम []byte पर काम करता है।

हालांकि, html/template स्ट्रिंग्स के साथ काम करता है।

जाओ पहले से ही आपको कुछ तार सेट करने के लिए -ldflags -X का उपयोग करने दें (गिट संस्करण, संकलन समय, सर्वर, उपयोगकर्ता इत्यादि सेट करने के लिए उपयोगी), क्या इस तंत्र को स्ट्रिंग के बजाय io.Readers सेट करने के लिए बढ़ाया जा सकता है?

@bradfitz क्या आप यहां उन डेटा के लिए भी स्ट्रिंग्स का उपयोग करने का प्रस्ताव कर रहे हैं जो टेक्स्ट नहीं है? छोटी बाइनरी फ़ाइलों जैसे आइकन और छोटी छवियों आदि को एम्बेड करना काफी आम है।

@ tv42 आपने कहा Write लेकिन मुझे लगता है कि आपका मतलब Read । आप string को io.ReaderAt का उपयोग करके strings.NewReader , इसलिए स्ट्रिंग का उपयोग करना वहां एक बाधा की तरह प्रतीत नहीं होता है।

@andreynering A string बाइट्स के किसी भी क्रम को पकड़ सकता है।

एक string बाइट्स के किसी भी क्रम को पकड़ सकता है।

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

हालांकि, मुझे पूरी तरह से विचार मिला। स्पष्टीकरण देने के लिए धन्यवाद।

@ianlancetaylor

Read में पारित स्लाइस को बदलना माना जाता है। Write नहीं है। इसलिए Write प्रलेखन कहता है कि इसकी अनुमति नहीं है। मुझे दस्तावेज़ीकरण के अलावा और कुछ भी आवश्यक नहीं दिख रहा है कि उपयोगकर्ताओं को लौटाए गए []byte नहीं लिखना चाहिए।

सिर्फ इसलिए कि strings.Reader मौजूद है इसका मतलब यह नहीं है कि io.WriteString लेखन स्ट्रिंग का एक कुशल कार्यान्वयन पाएगा। उदाहरण के लिए, TCPConn में WriteString ।

मुझे इस तरह की एक नई सुविधा शामिल करने से नफरत है, केवल सभी डेटा को कॉपी करने के लिए मजबूर करने के लिए इसे सॉकेट में लिखने के लिए।

साथ ही, सामान्य धारणा यह है कि तार मानव-मुद्रण योग्य होते हैं और []byte अक्सर नहीं होते हैं। JPEG को स्ट्रिंग्स में रखने से बहुत सारे गड़बड़ टर्मिनल होंगे।

@opennota

html/टेम्पलेट स्ट्रिंग्स के साथ काम करता है, हालाँकि।

हाँ, यह एक अजीब बात है, यह केवल पथनाम से फाइलें लेता है पाठकों के रूप में नहीं। दो प्रतिक्रियाएँ:

1. ऐसा कोई कारण नहीं है कि एम्बेड किए गए डेटा में Bytes() []byte और String() string दोनों विधियां न हों।

2. उम्मीद है कि आप प्रत्येक अनुरोध पर प्रत्येक टेम्पलेट को पार्स नहीं कर रहे हैं; जबकि आपको वास्तव में प्रत्येक अनुरोध के लिए एक जेपीईजी के डेटा को एक टीसीपी सॉकेट में भेजना होगा जो इसके लिए पूछता है।

@ tv42 हम आवश्यकतानुसार WriteString तरीके जोड़ सकते हैं।

मुझे नहीं लगता कि इस कार्यक्षमता का सबसे आम उपयोग अनमोडिफाइड डेटा लिखना होगा, इसलिए मुझे नहीं लगता कि हमें उस मामले के लिए अनुकूलित करना चाहिए।

मुझे नहीं लगता कि इस कार्यक्षमता का सबसे आम उपयोग अनमॉडिफाइड डेटा लिखना होगा,

मुझे लगता है कि इस कार्यक्षमता का सबसे आम उपयोग वेब संपत्तियों, छवियों/जेएस/सीएसएस, अनमोडिफाइड की सेवा करना होगा।

लेकिन इसके लिए मेरा शब्द न लें, आइए ब्रैड के फाइलमबेड के कुछ आयातकों को देखें:

#fileembed pattern .+\.(js|css|html|png|svg|js.map)$

#fileembed pattern .*\.png



md5-f8b48fccd03599094034bf2b507e9e67



#fileembed pattern .*\.js$

और इसी तरह..

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

मैं निर्देश के विपरीत नए पैकेज के लिए वोट करूंगा। इस पर पकड़ बनाना बहुत आसान है, संभालना/प्रबंधन करना आसान है और दस्तावेज़ीकरण और विस्तार करना बहुत आसान है। उदाहरण के लिए, क्या आप आसानी से गो निर्देश के लिए दस्तावेज़ ढूंढ सकते हैं जैसे "go:generate"? “fmt” पैकेज के दस्तावेज़ीकरण के बारे में क्या? क्या आपने देखा कि मुझे इसके साथ कहां जाना है?

तो, वैकल्पिक रूप से गो का अपना "आधिकारिक" एम्बेड टूल हो सकता है जो डिफ़ॉल्ट रूप से go build पर चलता है

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

इस सुविधा के बारे में सोचते समय मेरे दिमाग में दो अतिरिक्त बातें आती हैं:

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

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

संकलन/संपीड़न चर्चा को छोड़कर, एक और दर्द बिंदु stdlib में फाइल सिस्टम अबास्ट्रक्शन की कमी है क्योंकि:

• एक डेवलपर की मशीन पर, कई go run s और बिल्ड को एम्बेडिंग (वैकल्पिक रूप से संपीड़ित करते समय) संपत्तियों के ऊपरी हिस्से से बोझ नहीं होना चाहिए। एक फाइल सिस्टम एब्स्ट्रैक्शन विकास के दौरान स्थानीय फाइल सिस्टम को आसानी से _failover_ करने की अनुमति देगा।

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

संपादित करें: निष्कर्ष निकालने के लिए, यदि एम्बेड पैकेज फ़ाइल सिस्टम-जैसे इंटरफ़ेस का पर्दाफाश कर सकता है, तो http.FileSystem से बेहतर कुछ, यह इन चिंताओं को हल करेगा।

एम्बेड और स्थानीय फाइल सिस्टम के बीच निर्बाध रूप से स्विच करने की क्षमता

निश्चित रूप से इसे आवेदन स्तर पर लागू किया जा सकता है, और यह इस प्रस्ताव के दायरे से बाहर है, नहीं?

निश्चित रूप से इसे आवेदन स्तर पर लागू किया जा सकता है, और यह इस प्रस्ताव के दायरे से बाहर है, नहीं?

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

संपादित करें: टाइपो।

@knadh पूरी तरह से सहमत हैं कि जब आप go run भी उपयोग करते हैं तो इसे काम करना चाहिए, जिस तरह से पैकर इसे संभालता है वह वास्तव में अच्छा है। यह जानता है कि आप फाइलें कहां हैं, अगर वे ऐप में एम्बेड नहीं हैं, तो यह उन्हें डिस्क से लोड करता है क्योंकि यह मूल रूप से "विकास मोड" होने की अपेक्षा करता है।

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

मुझे नहीं पता कि यह पहले से चल रहा है या नहीं, लेकिन "एम्बेड पैकेज दृष्टिकोण" बहुत जादुई है, यह कुछ अजीबता भी प्रदान करता है क्योंकि टूल कॉल के आधार पर फ़ाइल में क्या करना है, यह घटा सकता है। जैसे एपीआई कुछ ऐसा हो सकता है

package embed
func FileReader(name string) io.Reader {…}
func FileReaderAt(name string) io.ReaderAt {…}
func FileBytes(name string) []byte {…}
func FileString(name string) string {…}

यदि गो टूल को FileReaderAt कॉल मिलती है, तो यह जानता है कि डेटा असम्पीडित होना चाहिए। यदि यह केवल FileReader कॉल पाता है, तो यह जानता है कि यह संपीड़ित डेटा संग्रहीत कर सकता है। अगर उसे FileBytes कॉल मिलती है, तो वह जानता है कि उसे एक प्रतिलिपि करने की ज़रूरत है, अगर उसे केवल FileString , तो यह जानता है कि यह केवल पढ़ने के लिए स्मृति से काम कर सकता है। और इसी तरह।

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

[संपादित करें] भी, निश्चित रूप से, आइए हम इस तथ्य के बाद इन अतिरिक्त मैंगलिंग चीजों को जोड़ते हैं, पहले अधिक न्यूनतम फीचर-सेट पर ध्यान केंद्रित करते हैं [/ संपादित करें]

अगर यह केवल FileReader कॉल पाता है ...

यह प्रतिबिंब के माध्यम से अन्य विधियों के उपयोग को रोकता है।

[संपादित करें] वास्तव में, मुझे लगता है कि इसके प्रभाव इससे कहीं अधिक व्यापक हैं। के उपयोग हैं FileReaderAt एक संकेत है कि डेटा असम्पीडित होना चाहिए है, तो के उपयोग FileReaderAt() किसी भी गैर के साथ const इनपुट का तात्पर्य है कि सभी फाइलों असम्पीडित संग्रहीत किया जाना चाहिए।

मुझे नहीं पता कि यह अच्छा है या बुरा। मुझे लगता है कि जादू ह्युरिस्टिक लगभग उतना उपयोगी नहीं होगा जितना कि यह पहली बार में लग सकता है।

एक विशेष निर्देशिका नाम ( static/ //go:embed ) के बजाय एक टिप्पणी प्राग्मा ( _test.go फ़ाइल में प्रकट होने की आवश्यकता है।

मुझे उम्मीद है कि यह मॉड्यूल के साथ एक आम समस्या का समाधान करेगा: यदि वह पैकेज किसी अन्य मॉड्यूल में है तो किसी अन्य पैकेज के लिए परीक्षण डेटा तक पहुंचना मुश्किल है। एक पैकेज _test.go फ़ाइल में //go:embedglob testdata/* जैसी टिप्पणी के साथ अन्य परीक्षणों के लिए डेटा प्रदान कर सकता है। पैकेज को उन फ़ाइलों को खींचे बिना एक नियमित गैर-परीक्षण बाइनरी में आयात किया जा सकता है।

@ fd0 ,

फ़ाइलों को एम्बेड करना बिल्ड कैश के साथ स्वचालित रूप से कैसे काम करेगा?

यह अभी भी काम करेगा। एम्बेडेड फ़ाइल सामग्री हैश को कैश कुंजी में मिलाया जाएगा।

क्या एक मॉड्यूल/पैकेज/तंत्र होना संभव होगा (या यहां तक ​​​​कि एक अच्छा विचार) जो व्यावहारिक रूप से पारदर्शी होगा, जैसा कि आपके आवेदन के अंदर से आप बस एक रास्ता खोलने की कोशिश कर रहे हैं

internal://static/default.css

और फ़ाइल फ़ंक्शन बाइनरी के अंदर या किसी वैकल्पिक स्थान से डेटा पढ़ेगा
पूर्व Package.Mount("internal[/<folder>.]", binary_path + "/resources/")

बाइनरी में सभी फाइलों के साथ "आंतरिक: //" बनाने के लिए, निष्पादन योग्य पथ/संसाधनों पर वापस आएं/यदि देव मोड में या यदि फ़ाइल बाइनरी में नहीं मिली है (और शायद लॉगिंग उद्देश्यों के लिए चेतावनी या कुछ फेंक दें)

यह उदाहरण के लिए अनुमति देगा

Package.Mount("internal", binary_path  + "/resources/private/")
Package.Mount("anotherkeyword", binary_path  + "/resources/content/")

'रिलीज़' मोड में वैकल्पिक स्थान को निष्पादन योग्य के पथ पर लॉक करने के लिए शायद सबसे अच्छा है, लेकिन इसे देव मोड में आराम दें (केवल go_path में फ़ोल्डर्स को अनुमति दें या ऐसा कुछ)

डिफ़ॉल्ट रूप से, पैकेज आंतरिक: // या किसी अन्य कीवर्ड को "माउंट" करता है, लेकिन उपयोगकर्ता को इसका नाम बदलने दें यदि वह चाहता है .. उदा। रीमाउंट ("आंतरिक", "myCustomName") या ऐसा कुछ।

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

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

एक समस्या जो मुझे दिखाई दे रही है वह यह है कि यदि पैकेज कस्टम नामों की अनुमति देता है, तो उसे किसी प्रकार की ब्लैकलिस्ट की आवश्यकता होगी, जैसे कि "udp, फ़ाइल, ftp, http, https और कई अन्य लोकप्रिय कीवर्ड" की अनुमति नहीं है।

बाइट सरणी/स्ट्रिंग या संपीड़न के रूप में स्टोर के लिए ... imho जो भी निर्णय लिया जाता है, उसे भविष्य में आसानी से अपडेट करने के लिए जगह छोड़नी चाहिए ... पूर्व में आप बिना किसी संपीड़न के शुरू कर सकते हैं और केवल ऑफ़सेट और फ़ाइल आकारों की एक सूची है और फ़ाइल नाम लेकिन भविष्य में आसानी से संपीड़न जोड़ना संभव बनाता है (उदा विधि zlib, lzma, संपीड़ित आकार, असम्पीडित आकार यदि इसे अनपैक करने के लिए पर्याप्त स्मृति आवंटित करने की आवश्यकता है आदि।

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

कुछ विचार जो अप्रत्यक्ष रूप से संबंधित हैं:

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

package embed

type Codec interface {
    // Encode transforms a source representation to an in-binary encoded asset.
    Encode(io.Writer, io.Reader) error

    // Decode transforms an in-binary asset to its active representation that the embedded application wants to use.
    Decode(io.Writer, io.Reader) error
}

यह बहुत विशिष्ट उपयोग के मामलों को कवर कर सकता है, जैसे कि यह एक काल्पनिक है:

package main

func NewJSONShrinker() embed.Codec {
   return jsonShrinker{}
}

type jsonShrinker struct{}
func (_ jsonShrinker)  Encode(io.Writer, io.Reader) error {
    // use json.Compact + gzip.Encode...
}
func (_ jsonShrinker)  Decode(io.Writer, io.Reader) error {
    // use gzip.Decode + json.Indent
}

इसका उपयोग करने जैसा दिख सकता है

// go:embed file.name NewJSONShrinker

func main() {
    embed.NewFileReader("file.name") // codec is implied by the comment above
}

या संभवतः

func main() {
    f, err := embed.NewFileReaderCodec("file.name", NewJSONShrinker())
    ...
}

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

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

अगर हम कंप्रेशन करते हैं, तो कोई कोडेक टाइप या कंप्रेशन लेवल नॉब्स बिल्कुल नहीं होंगे। यही है, किसी भी प्रकार की घुंडी होना संपीड़न का समर्थन न करने का सबसे बड़ा तर्क है।

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

लेकिन मैं @rsc के पक्ष में आ गया हूं क्योंकि मेरे पास एक अहसास के कारण संपीड़न नहीं है : बहुत ही सामग्री जो सबसे अधिक संकुचित है (HTML, JS, CSS, आदि) वह सामग्री है जिस पर आप अभी भी यादृच्छिक पहुंच चाहते हैं (के लिए) के माध्यम से परोसा जा सकता है, कहें, http.FileServer , जो रेंज अनुरोधों का समर्थन करता है)

और परकीप के एचटीएमएल/सीएसएस/जेएस के संयुक्त आकार को देखते हुए जिसे हम एम्बेड करते हैं, यह 48 केबी असम्पीडित है। परकीप सर्वर बाइनरी 49 एमबी है। (मैं एम्बेडेड छवियों के आकार को अनदेखा कर रहा हूं क्योंकि वे पहले से ही संकुचित हैं।) तो ऐसा लगता है कि यह इसके लायक नहीं है, लेकिन इसे बाद में जोड़ा जा सकता है।

@rsc के साथ चर्चा से, ऐसा लगता है कि हम उपरोक्त दृष्टिकोणों का मिश्रण कर सकते हैं:

पैकेज रनटाइम में,

package runtime

type Files struct {
     // unexported field(s), at least 1 byte long so Files has a unique address
}

func (f *Files) Open(...) (...) { ...}
func (f *Files) Stat(...) (...) { ...}
func (f *Files) EnumerateSomehow(...) { ...}

फिर आपके कोड में:

package yourcode

//go:embed static/*
//go:embed logo.jpg
var website runtime.Files

func F() {
     ... = website.Open("logo.jpg")
}

फिर cmd/go टूल go:embed टिप्पणियों को पार्स करेगा और उन पैटर्नों को ग्लोब करेगा + उन फ़ाइलों को हैश करेगा और &website का उपयोग करके उन्हें रनटाइम के साथ पंजीकृत करेगा।

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

@gdamore ,

यहां बस एक और शिकन - मेरे पास एक अलग परियोजना है जो डीटी्रेस स्रोत कोड (एम्बेडेड) का उपयोग करती है। यह n और rn के बीच अंतर के प्रति संवेदनशील है।
...
यदि विभिन्न मूंगिंग चाल नहीं चलेगा, तो यह इस नई सुविधा का उपयोग करने के खिलाफ एक तर्क है।

आप किसी भी कैरिज रिटर्न को हटाने के लिए रनटाइम पर भी मंग सकते हैं जो विंडोज उपयोगकर्ताओं से एम्बेडेड हो जाते हैं जो इंस्टॉल चल रहे हैं। मैंने लिखा है कि io.Reader एक दो बार फ़िल्टर करें।

लेकिन मैं @rsc के पक्ष में आ गया

संपीड़न और यादृच्छिक अभिगम पूरी तरह से परस्पर अनन्य नहीं हैं। उदाहरण के लिए यहां कुछ चर्चा देखें: https://stackoverflow.com/questions/429987/compression-formats-with-good-support-for-random-access-within-archives

संपीड़न और यादृच्छिक अभिगम पूरी तरह से परस्पर अनन्य नहीं हैं

हाँ, अगर हम चाहते थे कि मोटे अनाज वाले कुछ ओवरहेड के साथ सही स्थिति में आ जाएं। मैंने इस स्थान में CRFS के stargz प्रारूप के साथ कुछ काम किया है। लेकिन मुझे डर है कि ओवरहेड इतना बड़ा होगा कि हम लोगों के लिए इसे स्वचालित रूप से नहीं करना चाहेंगे। मुझे लगता है कि आप इसे स्मृति में आलसी रूप से बढ़ा सकते हैं (और इसे सिंक की तरह जीसी पर छोड़ने में सक्षम हो सकते हैं। पूल), लेकिन यह इसके लायक नहीं लगता है।

मुझे डर है कि ओवरहेड इतना बड़ा होगा कि हम लोगों के लिए इसे स्वचालित रूप से नहीं करना चाहेंगे।

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

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

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

मैंने वही लचीलापन प्रदान करने का एक और तरीका सोचा जो अधिक सुखद हो सकता है। // go:embed निर्देश एक कमांड आमंत्रण हो सकता है, जैसे // go:generate है। सबसे सरल मामले के लिए, कुछ इस तरह

// go:embed "file.name" go run example.com/embedders/cat file.name

बेशक, मुख्य अंतर यह है कि कमांड इनवोकेशन का स्टडआउट दिए गए नाम के तहत एम्बेड किया गया है। उदाहरण go run साथ एक प्रिटेंड पैकेज का भी उपयोग करता है, यह दिखाने के लिए कि कमांड OS को स्वतंत्र बनाने के लिए यह कैसे संभव होगा, क्योंकि cat हर जगह गो कंपाइल उपलब्ध नहीं हो सकता है।

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

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

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

क्या इस परियोजना का एक लक्ष्य यह सुनिश्चित करना है कि गो बिल्ड के लिए किसी बाहरी टूलिंग की आवश्यकता नहीं है और न ही गो: जनरेट लाइन्स की आवश्यकता है?

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

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

@ सैम व्हाइट ,

क्या इस परियोजना का एक लक्ष्य यह सुनिश्चित करना है कि गो बिल्ड के लिए किसी बाहरी टूलिंग की आवश्यकता नहीं है और न ही गो: जनरेट लाइन्स की आवश्यकता है?

हां।

यदि लोग go:generate या Makefiles या अन्य टूल का उपयोग करना चाहते हैं, तो उनके पास आज दर्जनों विकल्प हैं।

हम कुछ ऐसा चाहते हैं जो पोर्टेबल और सुरक्षित और सही हो जो डिफ़ॉल्ट रूप से काम करता हो। (और स्पष्ट होने के लिए: सुरक्षित का मतलब है कि हम "गो इंस्टाल" समय पर मनमाना कोड नहीं चला सकते हैं, उसी कारण से गो: जनरेट डिफ़ॉल्ट रूप से नहीं चलता है)

@ स्टीफ़ेंस २४२४

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

go build दौरान कोई मनमाना कोड निष्पादन नहीं।

गो बिल्ड के दौरान कोई मनमाना कोड निष्पादन नहीं।

हाँ, मैं इसे अब देखता हूँ। मुझे लगता है कि रेपो के लिए प्रतिबद्ध केवल "स्रोत" फाइलों को समेटने का कोई तरीका नहीं है, "संसाधित" फाइलें एम्बेड करना चाहते हैं, पैकेज को "प्राप्त करने योग्य" होने के लिए, _and_ go build सरल और सुरक्षित रखें। मैं अभी भी यहां मानकीकरण के लिए जोर दे रहा हूं, लेकिन मुझे उम्मीद है कि मेरा केक होगा और मैं इसे भी खाऊंगा, मुझे लगता है। करने के लायक है! समस्या को पकड़ने के लिए धन्यवाद!

@flimzy

यह प्रतिबिंब के माध्यम से अन्य विधियों के उपयोग को रोकता है।

मैंने जो उल्लेख किया है उसमें कोई विधि नहीं है, केवल कार्य करता है। वे रनटाइम पर खोजने योग्य नहीं हैं और स्रोत में नाम से उनका उल्लेख किए बिना उन्हें संदर्भित करने का कोई तरीका नहीं है। और ध्यान दें कि विभिन्न कार्यों द्वारा लौटाए गए इंटरफ़ेस-मान एक ही प्रकार के नहीं होते हैं - वास्तव में मैं उनसे अपेक्षा करता हूं कि वे या तो उस इंटरफ़ेस को लागू करने के लिए आवश्यक विधि के साथ या *strings.Reader उदाहरण के साथ निर्यात न किए गए प्रकार हों।

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

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

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

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

@मेरोवियस

गैर-कॉन्स्ट इनपुट की अनुमति देने का कोई मतलब नहीं है

मुझे लगता है कि हम अलग-अलग चीजों के बारे में बात कर रहे हैं। मेरा मतलब है एक्सेसर फ़ंक्शंस के इनपुट (यानी FileReaderAt() ) मुझे यकीन है कि आप सहमत होंगे कि गैर-कॉन्स्ट इनपुट वहां समझ में आता है।

और मेरा कहना है: मान लीजिए कि हमने 100 फाइलें एम्बेड की हैं, लेकिन हमारे पास FileReaderAt(filename) कॉल है, जहां filename स्थिर नहीं है; यह जानने का कोई तरीका नहीं है कि एम्बेडेड फ़ाइलों में से कौन सी (यदि वास्तव में कोई है) इस तरह से एक्सेस की जाएगी, इस प्रकार सभी को असंपीड़ित किया जाना चाहिए।

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

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

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

वाह वाह!!!

@ जूलियो-गुएरा
मुझे पूरा यकीन है कि आपको अभी भी उन्हें डिस्क पर निकालना होगा और फिर सी फ़ंक्शन को कॉल करने के लिए dlopen और dlsym का उपयोग करना होगा।

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

http स्थिर संपत्तियों के बाहर, एम्बेडेड ब्लॉब्स के लिए जो आपको स्मृति में पॉइंटर में चाहिए, एक ऐसा फ़ंक्शन होना अच्छा होगा जो पॉइंटर को पहले से ही प्रक्रिया में एम्बेडेड मेमोरी में वापस कर दे। अन्यथा किसी को नई मेमोरी आवंटित करनी होगी और io.Reader से एक प्रति बनानी होगी। यह दो बार स्मृति का उपभोग करेगा।

@ग्लिसरीन , फिर से, यह एक string । एक string एक सूचक और एक लंबाई है।

क्या संकलन समय पर कोड को निष्पादित करने के लिए कोड को चिह्नित करने और रनटाइम पर परिणाम प्रदान करने का कोई तरीका होना अच्छा नहीं होगा। इस तरह आप किसी भी फाइल को पढ़ सकते हैं, यदि आप संकलन समय पर चाहें तो इसे संपीड़ित कर सकते हैं और रनटाइम पर आप इसे एक्सेस कर सकते हैं। यह कुछ गणनाओं के लिए काम करेगा क्योंकि यह फ़ाइल सामग्री के प्रीलोडिंग के लिए काम करेगा।

@burka जैसा कि पहले धागे में कहा गया है, go build मनमाना कोड नहीं चलाएगा।

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

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

मुझे नहीं पता कि प्रॉक्सी पहले से ही इसके लिए अनुकूलित कर चुके हैं लेकिन किसी दिन यह संभव है कि वे चाहें।

@leighmcculloch मुझे नहीं लगता कि आज भी ऐसा ही है, हालाँकि। गो पैकेज में सभी गैर-गो फ़ाइलें मॉड्यूल संग्रह में शामिल की जानी चाहिए, क्योंकि वे go test लिए आवश्यक हो सकती हैं। एक अन्य उदाहरण के रूप में आपके पास सीजीओ के लिए सी फाइलें भी हो सकती हैं।

यह एक रोमांचक दिशा है, हमें निश्चित रूप से हमारे उपयोग के मामलों के लिए इसकी आवश्यकता है।

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

यह मददगार हो सकता है - कम से कम मेरे लिए वास्तव में मददगार हो - अगर हम फ़ाइल एम्बेडिंग समाधान के लिए चुनौतियों को चित्रित कर सकते हैं ।

उदाहरण के लिए, हमारा प्राथमिक उपयोग-मामला HTML + CSS + JS + JPG + आदि को एम्बेड करना है ताकि जब गो ऐप चलाया जाए तो यह उन फ़ाइलों को एक निर्देशिका में लिख सके जैसे कि उन्हें http.FileServer द्वारा परोसा जा सके। . यह देखते हुए कि उपयोग-मामले में मैंने पाठकों और लेखकों पर चर्चा करते हुए पढ़ी गई अधिकांश टिप्पणियां मेरे लिए विदेशी हैं क्योंकि हमें गो से फाइलों तक पहुंचने की आवश्यकता नहीं है, हम केवल go-bindata उन्हें डिस्क पर कॉपी करने देते हैं _(यद्यपि शायद बेहतर तकनीकों का लाभ उठाने का एक तरीका है जिसे हमने अभी तक महसूस नहीं किया है कि हमें विचार करना चाहिए।)_

लेकिन हमारी चुनौतियाँ इस प्रकार हैं: हम आम तौर पर अपने डिबगर के साथ GoLand का उपयोग करते हैं और लगातार बदलाव करते हुए वेब ऐप पर काम करेंगे। इसलिए विकास के दौरान हमें फ़ाइलों को सीधे हमारी स्रोत निर्देशिका से लोड करने के लिए http.FileServer आवश्यकता होती है। लेकिन जब ऐप http.FileServer चलता है तो उस निर्देशिका से उन फ़ाइलों को पढ़ने की आवश्यकता होती है जहां फ़ाइलों को एम्बेडिंग समाधान द्वारा लिखा गया है। जिसका अर्थ है कि जब हम संकलित करते हैं तो हमें फाइलों को अपडेट करने के लिए गो-बिंदाटा चलाना होता है, और फिर उन्हें गिट में जांचना होता है। और यह सब आम तौर पर go-bindata साथ व्यावहारिक है, हालांकि निश्चित रूप से विचार नहीं है।

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

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

विचार करने के लिए अग्रिम धन्यवाद।

चूंकि मैं इसे उपयोग के मामले के रूप में उल्लेखित नहीं देखता, इसलिए हमें टेम्प्लेट की हमारी निर्देशिका के लिए भी इसका लाभ होगा, जिसे हम template.ParseFiles के माध्यम से एक्सेस करते हैं।

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

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

मेरे दिमाग में इस तरह का एक समाधान उपयोग में आसानी और कम "जादू" में संतुलन प्राप्त करता है।

@jayconrod ने लिखा:

एक विशेष निर्देशिका नाम (स्थिर /) के बजाय एक टिप्पणी प्रज्ञा (//go: एम्बेड) के पक्ष में एक तर्क: एक टिप्पणी हमें एक पैकेज (या xtest संग्रह) के लिए परीक्षण संग्रह में एक फ़ाइल एम्बेड करने देती है लेकिन पुस्तकालय नहीं परीक्षण के अंतर्गत।

यह वास्तव में एक अच्छा अवलोकन है। हालांकि अगर हम विशेष निर्देशिका नाम के साथ जाना चाहते हैं, तो हम एक परिचित तंत्र का उपयोग कर सकते हैं: static सभी बिल्ड के लिए, static_test परीक्षण बिल्ड के लिए, static_amd64 amd64 बिल्ड के लिए, और जल्द ही। हालांकि, मुझे मनमाने ढंग से बिल्ड टैग समर्थन प्रदान करने का एक स्पष्ट तरीका नहीं दिख रहा है।

स्थिर डीआईआर में एक मेनिफेस्ट फ़ाइल हो सकती है (खाली मैनिफेस्ट दिए जाने पर डिफ़ॉल्ट में मैनिफेस्ट को छोड़कर सबकुछ शामिल होता है) जिसमें ग्लब्स शामिल होते हैं और बिल्ड टैग और शायद बाद में संपीड़न इत्यादि निर्दिष्ट करने की अनुमति देता है।

एक उल्टा यह है कि यदि गो सूची एक मैनिफेस्ट वाले डीआईआर को हिट करती है तो वह उस पेड़ को ला # 30058 . छोड़ सकती है

एक नकारात्मक पहलू यह है कि इसे बहुत ही htacces मिल सकता है और धन्यवाद नहीं

पैकेज में फ़ाइलों को बंडल करने के लिए एक साधारण शून्य-घुंडी तंत्र एक पैकेज निर्देशिका में एक विशेष निर्देशिका go.files हो सकता है (मॉड्यूल में go.mod समान)। एक्सेस उस पैकेज तक ही सीमित रहेगा, जब तक कि वह किसी प्रतीक को निर्यात करने का विकल्प नहीं चुनता।

संपादित करें: एकल-फ़ंक्शन runtime/files प्रस्ताव:

package files

func Open(name string) (io.ReadCloser, error) {
    // runtime opens embedded file based on caller package
    return rc, nil
}

package foo

import "runtime/files"

func ReadPackageFile(name string) ([]byte, error) {
    rc, err := files.Open(name)
    if err != nil {
        return nil, err
    }
    defer rc.Close()
    return ioutil.ReadAll(rc)
}

import "C" दृष्टिकोण ने पहले से ही "जादू" आयात पथ के लिए एक मिसाल कायम की है। IMO इसने बहुत अच्छा काम किया है।

चूंकि मैं इसे उपयोग के मामले के रूप में उल्लेखित नहीं देखता, इसलिए हमें टेम्प्लेट की हमारी निर्देशिका के लिए भी इसका लाभ होगा, जिसे हम template.ParseFiles के माध्यम से एक्सेस करते हैं।

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

मुझे लगता है कि एक एम्बेडेड संसाधन को 'निर्यात' और 'प्रतिस्थापित' करने के लिए कार्यों के साथ एक एपीआई प्रदान करके किया जा सकता है। डेवलपर तब अंतिम उपयोगकर्ता को कुछ कमांड लाइन विकल्प प्रदान कर सकता है (आंतरिक रूप से उल्लिखित एपीआई कॉल का उपयोग करके)।

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

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

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

type EmbedPackage interface {
    Bytes(filename string) []bytes
    BytesCompressed(filename string, config interface{}) []bytes // compressed in-binary as configured by some kind of config struct, memoizes decompression during runtime on first access
    Reader(filename string) io.Reader
    File(filename string) os.File // readonly and contains all metadata
    Dir(filepath string) []os.File 
    Glob(pattern string) []os.File // like filepath.Glob()

    // maybe? this could allow to load JSON, YAML, INI, TOML, etc files more easily
    // but would probably be too much for the std lib implementation
    Unmarshal(filename string, config interface{}, ptr interface{}) 
}

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

// embed a file that is compressed in-binary and automatically decompressed on first access
var LongText = embed.BytesCompressed("legal.html", embed.Config{ Compression: "gzip", CompressionLevel: "9" })

// loads a single file as reader for easy access
var FewLinesOfText = bufio.NewReader(embed.Reader("lines.txt"))
for _, line := range FewLinesOfText.ReadLines() { ... }

// embeds all files in the directory
var PdfFontFiles = embed.Dir("/fonts")

// unmarshals file into custom config
var PdfProcessingConfig MyPdfProcessingConfig
embed.Unmarshal("/pdf_conversion.json", embed.Config{ Encoding: "text/json" }, &PdfProcessingConfig)

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

संकलन प्रक्रिया के दौरान फ़ाइलों तक पहुँचने में विफल रहने पर एक कंपाइलर त्रुटि उत्पन्न होगी।

बाइनरी के पीछे एक ज़िप संग्रह बनाना भी संभव है, ताकि यह प्रभावी रूप से स्वयं निकालने वाला बाइनरी बन सके। शायद यह कुछ उपयोग के मामलों में उपयोगी है? इसे यहाँ एक प्रयोग के रूप में किया: https://github.com/sanderhahn/gozip

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

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

एक और बात जो मुझे स्पष्ट नहीं है। static निर्देशिका की चर्चा के लिए यह मेरे लिए 100% स्पष्ट नहीं है यदि हम static _source_ निर्देशिका, या static निर्देशिका पर चर्चा कर रहे हैं जहां फाइलें उपलब्ध कराई जाएंगी _at रनटाइम_ ?

और यह भेद विशेष रूप से महत्वपूर्ण है क्योंकि यह विकास प्रक्रिया और डिबगिंग कोड से संबंधित है जो विकास में है।

@mikeschinkel यह मूल पोस्ट से बहुत स्पष्ट है कि एम्बेडिंग बिल्ड समय पर होगी:

go install / go build एम्बेडिंग स्वचालित रूप से करें

मूल पोस्ट, और ऊपर दी गई कुछ टिप्पणियां, रन-टाइम पर फ़ाइलों को लोड करने के लिए "देव" मोड होने पर भी चर्चा करती हैं।

@mvdan उत्तर के लिए धन्यवाद। तो आप सोच रहे हैं इसका मतलब है कि प्रस्तावित /static/ निर्देशिका ऐप रेपो, पैकेज रेपो, और/या संभवतः दोनों की जड़ से संबंधित होगी?

और रनटाइम फ़ाइलों का वह स्थान पूरी तरह से इस बात पर निर्भर करेगा कि डेवलपर उन्हें कहाँ रखना चाहता है?

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

उपर्युक्त मॉड्यूल परदे के पीछे कुछ लोग। मुझे लगता है कि इस फीचर के अच्छे डिजाइन के लिए यह एक बेहतरीन लिटमस टेस्ट है।

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

लोगों ने एक ऑप्ट-इन के रूप में go.mod का भी उल्लेख किया।

विचार: go.mod फ़ाइल में विशिष्टता? अन्य टूल्स को पार्स करने के लिए इसे सरल बनाता है।

module github.com/foo/bar

data internal/static ./static/*.tmpl.html

यह फ़ाइल डेटा के साथ संकलन समय पर एक पैकेज तैयार करेगा। ग्लोब सिंटैक्स यहां अच्छा हो सकता है, लेकिन शायद सरलीकरण और केवल निर्देशिका एम्बेड करना ही काफी अच्छा है। (इसके अलावा: ** ग्लोब सिंटैक्स के लिए +1।)

import "github.com/foo/bar/internal/static"

f, err := static.Open("static/templates/foo.tmpl")

स्ट्रिपप्रिफ़िक्स जैसा कुछ यहाँ अच्छा हो सकता है लेकिन आवश्यक नहीं है। एक रैपर पैकेज बनाना आसान है जो आपके इच्छित फ़ाइल पथ का उपयोग करता है।

इसे और सरल बनाया जा सकता है:

module github.com/foo/bar

data ./static/*.tmpl.html

import "runtime/moddata"

moddata.Open("static/foo.tmpl")

लेकिन यह थोड़ा अनपेक्षित है कि कॉलिंग पैकेज/मॉड्यूल के आधार पर मोडडाटा का अलग व्यवहार होगा। यह सहायकों को लिखना अधिक कठिन बना देगा (उदाहरण के लिए, http.Filesystem कनवर्टर)

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

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

ऊपर दिए गए कुछ डिज़ाइनों का मतलब होगा कि मॉड्यूल प्रॉक्सी को यह पता लगाने के लिए उपयोगकर्ता कोड निष्पादित करना होगा कि कौन सी स्थिर फाइलें भी शामिल की जानी चाहिए।

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

मैं इस उपयोग-मामले पर अपने विभिन्न विचारों को कुछ ठोस बनाने की कोशिश कर रहा हूं, और इसलिए @broady ने जो सुझाव दिया है, embed संज्ञा के बजाय data ।

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

2. इसके अलावा, एम्बेडेड फाइलों का एक संग्रह मुझे ऐसा लगता है कि वे अधिक मूल्यवान और पुन: प्रयोज्य होंगे यदि एक पैकेज जिसे एक-ऑफ सिंटैक्स का उपयोग करके गो प्रोजेक्ट में जोड़ा गया कुछ तदर्थ के बजाय शामिल किया जा सकता है। यहां विचार यह है कि यदि एम्बेड को पैकेज के रूप में लागू किया गया था तो लोग जीथब के माध्यम से उन्हें विकसित और साझा कर सकते थे और अन्य उन्हें अपनी परियोजनाओं में उपयोग कर सकते थे। GitHub पर समुदाय-रखरखाव और फ्री-टू-यूज़ पैकेज की कल्पना करें जिसमें शामिल हैं:

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

3. एक नई URL योजना जैसे goembed:// - या शायद एक मौजूदा - जिसका उपयोग पैकेज से फ़ाइलों को खोलने और पढ़ने के लिए किया जा सकता है, इस प्रकार _(all?)_ मौजूदा फ़ाइल हेरफेर एपीआई को नए बनाने के बजाय लीवरेज करने की अनुमति देता है ones, निम्न जैसा कुछ जो वर्तमान पैकेज में निहित एम्बेड के सापेक्ष होगा:

   data, err := ioutil.ReadFile("goembed://postal-codes.txt")    
   if (err != nil) {
     fmt.Println(err)
   }
   

उपरोक्त अवधारणाओं के साथ, _"जादू"_ जैसा कुछ नहीं लगता; सब कुछ एक तंत्र द्वारा सुरुचिपूर्ण ढंग से संभाला जाएगा जो ऐसा महसूस करता है कि यह उद्देश्य के लिए था। बहुत कम विस्तार की आवश्यकता होगी; go.mod में एक नई क्रिया और एक नई URL योजना जिसे गो द्वारा आंतरिक रूप से पहचाना जाएगा। बाकी सब कुछ वैसे ही उपलब्ध कराया जाएगा-जैसा कि गो की ओर से है।

मैं अभी क्या करता हूं

मैं अभी इसके लिए code.soquee.net/pkgzip उपयोग करता हूं (यह statik का एक कांटा है जो वैश्विक स्थिति से बचने और दुष्प्रभावों को आयात करने के लिए एपीआई को बदलता है)। मेरा सामान्य वर्कफ़्लो (कम से कम एक वेब ऐप में) ज़िप फ़ाइल में बंडल की गई संपत्तियों को एम्बेड करना है और फिर golang.org/x/tools/godoc/vfs/zipfs और golang.org/x/tools/godoc/vfs/httpfs का उपयोग करके उनकी सेवा करना है।

जाओ: एम्बेड दृष्टिकोण

दो चीजें हैं जो मुझे go:embed दृष्टिकोण अपनाने से निश्चित रूप से रोकेंगी:

1. जनरेट किया गया कोड दस्तावेज़ीकरण में दिखाई नहीं देगा
2. संपत्ति पूरे कोड आधार पर बिखरी हो सकती है (यह बाहरी उपकरणों और go:generate का उपयोग करने के बारे में भी सच है, यही कारण है कि मैं आम तौर पर निर्माण से पहले संपत्ति के विभिन्न सेट उत्पन्न करने के लिए मेकफ़ाइल का उपयोग करना पसंद करता हूं, फिर मैं मेकफ़ाइल में उन सभी को देख सकते हैं)

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

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

import "forkaweso.me/forkawesome/v2"

एम्बेड पैकेज दृष्टिकोण

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

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

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

हाइब्रिड

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

module forkaweso.me/forkawesome/v2

go 1.15

embed (
    fonts/forkawesome-webfont.ttf
    fonts/forkawesome-webfont.woff2
)

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

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

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

var IconFont = embed.Dir("forkaweso.me/forkawesome/v2/fonts/")
var Logo = embed.File("images/logo.jpg")

जैसा कि ऊपर देखा गया है, संसाधनों को मॉड्यूल में डालने से वांछित होने पर उन्हें उस विशेष मॉड्यूल तक सीमित किया जा सकता है। वास्तविक एपीआई और आप किसी संपत्ति का चयन कैसे करते हैं, इसके लिए कुछ काम करने की आवश्यकता हो सकती है।

फिर भी एक और विचार: embed में go.mod एक नई तरह की क्रिया जोड़ने के बजाय, हम एक नए प्रकार का पैकेज पेश कर सकते हैं, एक डेटा पैकेज, जो आयात हो जाता है और go.mod में उपयोग किया जाता है हमेशा की तरह। यहाँ एक स्ट्रॉ मैन स्केच है।

यदि किसी पैकेज में ठीक एक .go फ़ाइल, static.go , और उस फ़ाइल में केवल टिप्पणियाँ और एक पैकेज क्लॉज़ है, तो एक पैकेज एक डेटा पैकेज है। जब आयात किया जाता है, तो cmd/go पैकेज को निर्यात किए गए कार्यों के साथ पॉप्युलेट करता है जो उसमें निहित फाइलों तक पहुंच प्रदान करता है, जो परिणामी बाइनरी में एम्बेडेड होते हैं।

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

निर्देशिका में सभी गैर .go फ़ाइलों और उप फ़ोल्डरों (बिना वास्तविक कोड नियमों का पालन करते हुए) को स्वचालित रूप से शामिल करने के बारे में क्या?

यदि किसी पैकेज में ठीक एक .go फ़ाइल, static.go , और उस फ़ाइल में केवल टिप्पणियाँ और एक पैकेज क्लॉज़ है, तो एक पैकेज एक डेटा पैकेज है।

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

@flimzy
यह थोड़े से एक टैग के साथ एम्बेडेड फ़ाइलों का उपयोग करने की अनुमति देगा और उसी fns/vars को जेनरेट किए गए पैकेज के रूप में परिभाषित करेगा और फ़ाइलों को किसी अन्य टैग के साथ (शायद रिमोट?)

अच्छा होगा यदि रैपर कार्यों को उत्पन्न करने के लिए एक बिल्ड फ्लैग था तो किसी को केवल रिक्त स्थान भरना होगा।

@ जोशेरियन

यदि किसी पैकेज में ठीक एक .go फ़ाइल, static.go , और उस फ़ाइल में केवल टिप्पणियाँ और एक पैकेज क्लॉज़ है, तो एक पैकेज एक डेटा पैकेज है।

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

मैं "डेटा" पैकेजों को उनकी अपनी डोमेन-विशिष्ट कार्यक्षमता के रूप में देख सकता हूं, जैसे कि पोस्टल-कोड लुकअप।

आप my.pkg/postalcode में कार्यक्षमता को उजागर कर सकते हैं और डेटा को my.pkg/postalcode/data (या my.pkg/postalcode/internal/data) में डाल सकते हैं।

मैं इसे आपके सुझाव के अनुसार करने की अपील देखता हूं, लेकिन यह प्रश्नों का एक समूह उठाता है: पश्चगामी संगतता कैसे काम करती है? आप डेटा पैकेज को इस तरह कैसे चिह्नित करते हैं? यदि पैकेज में ऐसे कार्य हैं जो उन cmd/go के साथ विरोध करेंगे, तो आप क्या करेंगे? (मैं यह नहीं कह रहा हूं कि इनके पास उत्तर नहीं हैं, बस यह आसान है कि इनका उत्तर न दिया जाए।)

@ जोशेरियन , कृपया ऊपर दिए गए टाइप चेकिंग कमेंट पर विचार करें (https://github.com/golang/go/issues/35950#issuecomment-561443566)।

@bradfitz हाँ, यह एक भाषा परिवर्तन होगा, और इसके लिए गो/प्रकार के समर्थन की आवश्यकता होगी।

वास्तव में, भाषा परिवर्तन के बिना ऐसा करने का एक तरीका है- static.go की आवश्यकता होती है जिसमें शरीर-रहित कार्य शामिल होते हैं जो कि cmd/go से बिल्कुल मेल खाते हैं।

शरीर-रहित कार्यों को समाहित करने के लिए static.go की आवश्यकता होती है जो कि cmd/go से बिल्कुल मेल खाता है।

यदि यह सभी embed.File() पकड़ने के बजाय प्रति फ़ाइल फ़ंक्शन उत्पन्न करता है, तो यह आसान प्रति परिसंपत्ति निर्यात नियंत्रण की अनुमति देगा।

तो उत्पन्न सामान की तरह दिखेगा:

EmbededFoo() embed.Asset {...}
embededBar() embed.Asset {...}

एक ब्लॉग पोस्ट मैंने 4 महीने पहले स्थिर फाइलों के बारे में लिखा था। निष्कर्ष में अंतिम वाक्य देखें :-)

@ जोशेरियन

आप my.pkg/postalcode में कार्यक्षमता को उजागर कर सकते हैं और डेटा को my.pkg/postalcode/data (या my.pkg/postalcode/internal/data) में डाल सकते हैं।

वह - जबकि सुरुचिपूर्ण - मेरी चिंताओं को दूर कर सकता है।

पश्चगामी संगतता कैसे काम करती है?

मैं नहीं देखता कि बीसी की चिंताएं यहां कैसे लागू होती हैं। क्या आप विस्तार कर सकते हैं?

आप डेटा पैकेज को इस तरह कैसे चिह्नित करते हैं?

embed स्टेटमेंट के साथ go.mod ?

हो सकता है कि आप जो पूछ रहे हैं मैं उसका पालन नहीं कर रहा हूं।

लेकिन मैं इसे उलट दूंगा; आप केवल डेटा वाले पैकेज को कैसे चिह्नित करते हैं?

यदि पैकेज में ऐसे कार्य हैं जो उन cmd/go के साथ विरोध करेंगे, तो आप क्या करेंगे?

1. प्रस्तावित दृष्टिकोण का उपयोग करते हुए, मुझे नहीं लगता कि इन्हें किसी भी फ़ंक्शन को जोड़ने के लिए cmd/go की आवश्यकता होगी।

2. भले ही cmd/go को फ़ंक्शन जोड़ने की आवश्यकता हो, मुझे लगता है कि _मौजूदा_ पैकेज में विरोध का व्यवहार _undefined_ होगा।

   प्रस्ताव मानता है कि डेवलपर एकल जिम्मेदारी सिद्धांत का पालन करता है और इस प्रकार केवल डेटा-केंद्रित पैकेज होने के लिए डेटा के साथ एक पैकेज बनाना चाहिए और मौजूदा तर्क-केंद्रित पैकेज में डेटा नहीं जोड़ना चाहिए।

   बेशक एक डेवलपर _could_ किसी मौजूदा पैकेज में जोड़ सकता है जिस स्थिति में व्यवहार अपरिभाषित होगा। IOW, यदि कोई डेवलपर मुहावरे की उपेक्षा करता है तो वे अज्ञात क्षेत्र में होंगे।

मैं यह नहीं कह रहा हूं कि इनके पास उत्तर नहीं हैं, बस यह आसान है कि इनका उत्तर न दिया जाए।

सिवाय इसके कि मुझे लगता है कि उत्तर सरल हैं। कम से कम उन लोगों के लिए जिन्हें आपने अब तक पोज दिया है।

मुझे लगता है कि प्रतीकों के लिए प्रतीकों या मूल्यों को जोड़ने वाला कोई भी समाधान पैकेज स्कोप होना चाहिए, मॉड्यूल स्कोप नहीं। क्योंकि गो के लिए संकलन इकाई पैकेज है, मॉड्यूल नहीं।

तो यह आयात करने के लिए फ़ाइलों की सूची निर्दिष्ट करने के लिए go.mod किसी भी उपयोग को छोड़ देता है।

@dolmen यदि अंतिम परिणाम अपने पैकेज में है, तो दायरा स्वयं एक मॉड्यूल होगा।

@urandom नहीं, दायरा वह पैकेज है जो उस जेनरेट किए गए पैकेज को आयात करता है। लेकिन वैसे भी मुझे नहीं लगता कि एक पूर्ण उत्पन्न पैकेज इस प्रस्ताव के दायरे में है।

@urandom नहीं, दायरा वह पैकेज है जो उस जेनरेट किए गए पैकेज को आयात करता है। लेकिन वैसे भी मुझे नहीं लगता कि एक पूर्ण उत्पन्न पैकेज इस प्रस्ताव के दायरे में है।

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

इसके अलावा, go.mod मौजूदा कार्यक्रमों को तोड़े बिना ऐसी सुविधा (कोई जादू टिप्पणी, या जादू निर्देशिका) जोड़ने का सबसे साफ तरीका प्रस्तुत करता है।

यहां कुछ ऐसा है जिसका अभी तक उल्लेख नहीं किया गया है: गो सोर्स प्रोसेसिंग टूल्स (कंपाइलर, स्टैटिक एनालाइजर) के लिए एपीआई रनटाइम एपीआई जितना ही महत्वपूर्ण है। इस प्रकार का एपीआई गो का मुख्य मूल्य है जो पारिस्थितिकी तंत्र को विकसित करने में मदद करता है (जैसे go/ast / go/format और go mod edit )।

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

एक विशेष पैकेज के मामले में, मुझे go.mod पार्सिंग ( go mod टूल्स) या go/ast पार्सर में बदलने के लिए कुछ भी नहीं दिखता है।

@ डोलमेन

_ "मुझे लगता है कि कोई भी समाधान जो प्रतीकों के लिए प्रतीकों या मूल्यों को जोड़ता है, पैकेज स्कोप होना चाहिए, मॉड्यूल स्कोप नहीं। क्योंकि गो के लिए संकलन इकाई पैकेज है, मॉड्यूल नहीं। इसलिए यह सूची निर्दिष्ट करने के लिए go.mod के किसी भी उपयोग को छोड़ देता है आयात करने के लिए फ़ाइलें।"_

मॉड्यूल क्या है? मॉड्यूल _ " संबंधित गो पैकेजों का एक संग्रह है जो एक इकाई के रूप में एक साथ संस्करणित होते हैं ।" इस प्रकार एक मॉड्यूल में एक पैकेज हो सकता है, और एक पैकेज एक मॉड्यूल की संपूर्णता हो सकता है।

जैसे, go.mod आयात करने के लिए फाइलों की सूची निर्दिष्ट करने के लिए सही जगह है, यह मानते हुए कि गो टीम विशेष टिप्पणियों और जादू पैकेजों पर go.mod को अपनाती है। यह तब तक है जब तक कि गो टीम go.pkg फ़ाइल जोड़ने का निर्णय नहीं लेती।

इसके अलावा, यदि गो टीम को एम्बेड फ़ाइलों को निर्दिष्ट करने के स्थान के रूप में go.mod स्वीकार करना था, तो कोई भी व्यक्ति जो फ़ाइलों को एम्बेड करना चाहता है, उसे embed निर्देशों और पैकेज के साथ go.mod प्रदान करना चाहिए। जिसे उस निर्देशिका द्वारा दर्शाया जाता है जिसमें go.mod फ़ाइल रहती है वह वह पैकेज होगा जिसमें एम्बेडेड फ़ाइलें होती हैं।

लेकिन अगर वह नहीं है जो डेवलपर चाहता है तो उन्हें एक और go.mod फ़ाइल बनानी चाहिए और इसे उस पैकेज के लिए निर्देशिका में रखना चाहिए जिसमें वे अपनी एम्बेडेड फाइलें रखना चाहते हैं।

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

@mikeschinkel , एक मॉड्यूल _संबंधित_ पैकेजों का एक संग्रह है। हालांकि, उस मॉड्यूल के भीतर अन्य पैकेजों की ट्रांजिटिव निर्भरता (और डेटा!) को खींचे बिना मॉड्यूल से एक पैकेज का उपयोग करना संभव (और उचित!)

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

@बीसीमिल्स

ऐसा लगता है कि कोई आपके संदेश में 'डेटा फ़ाइलों' को 'मॉड्यूल' से बदल सकता है और यह अभी भी सही रहेगा।
अपने स्वयं के विशिष्ट पैकेजों के लिए निर्भरता के रूप में विशिष्ट मॉड्यूल का होना काफी सामान्य है।
फिर भी हम उन सभी को गो.मोड में रखते हैं।

@urandom , go.mod फ़ाइल में इंगित मॉड्यूल के सभी पैकेज अंतिम बाइनरी में लिंक नहीं हैं। ( go.mod फ़ाइल में एक निर्भरता डालना _not_ प्रोग्राम में उस निर्भरता को जोड़ने के बराबर है।)

मेटा-पॉइंट

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

विचार?

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

हो सकता है कि जब कोई डिज़ाइन दस्तावेज़ हो तो इसे बंद किया जा सकता है।

या इसे बंद करें और #3035 को फिर से खोलें (टिप्पणियों को रोककर) ताकि कम से कम एक खुला मुद्दा इसे ट्रैक कर सके।

बंद करने के बारे में बात करने के ठीक बाद ऐसा करने के लिए खेद है, लेकिन करीबी चर्चा @bcmills की टिप्पणी के ठीक बाद और इससे पहले कि मैं स्पष्ट कर पाता।

"_हालाँकि, मॉड्यूल से एक पैकेज का उपयोग करना संभव है (और उचित!) उस मॉड्यूल के भीतर अन्य पैकेजों की संक्रमणीय निर्भरता (और डेटा!)

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

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

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

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

जब तक ब्रैड और अन्य एक औपचारिक डिज़ाइन दस्तावेज़ तैयार नहीं कर लेते, तब तक होल्ड पर रखें।

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

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

embed ui "./ui/build"

func main() {
  file, err := ui.Open("version.txt")
  if err != nil {
    panic(err)
  }
  version, err = ioutil.ReadAll(file)
  if err != nil {
    panic(err)
  }
  file.Close()

  log.Printf("UI Version: %s\n", bytes.TrimSpace(version))
  http.ListenAndServe(":8080", http.EmbeddedDir(ui))
}

संपादित करें: आपने मुझे इसे हरा दिया, @jayconrod।

यह साफ और पठनीय है, लेकिन मुझे यकीन नहीं है कि गो टीम एक नया कीवर्ड पेश करना चाहेगी

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

एक विशेष निर्देशिका नाम के रूप में static का उपयोग करना थोड़ा भ्रमित करने वाला है और मैं इसके बजाय assets साथ जाना चाहूंगा।
एक और विचार जो मैंने धागे में नहीं देखा वह है assets को पैकेज के रूप में आयात करने की अनुमति देना, उदाहरण के लिए import "example.com/internal/assets" । उजागर एपीआई को अभी भी एक डिजाइन की जरूरत है, लेकिन कम से कम यह विशेष टिप्पणियों या नए runtime/files -स्टाइल पैकेज की तुलना में साफ दिखता है।

एक और विचार जो मैंने धागे में नहीं देखा वह है एक पैकेज के रूप में संपत्तियों को आयात करने की अनुमति देना

यह यहाँ प्रस्तावित किया गया था: https://github.com/golang/go/issues/35950#issuecomment -562966654

एक जटिलता यह है कि टाइपचेकिंग होने में सक्षम होने के लिए, आपको या तो यह एक भाषा परिवर्तन होना चाहिए या cmd/go द्वारा भरे जाने वाले बॉडी-लेस फ़ंक्शन प्रदान करना चाहिए ।

यह समान विचार है, लेकिन static.go डिज़ाइन डेटा पैकेज में एक मनमाना आयात पथ को बदलने की अनुमति देता है, जबकि assets निर्देशिका testdata , internal या vendor तरह अधिक काम करती है। assets हो सकता है जिसमें कोई गो पैकेज न हो (या केवल दस्तावेज़ों को अनुमति दें), यानी अंतर्निहित पिछड़ा संगतता के लिए।

फ़ाइलों को प्राप्त करने के लिए इसे runtime/files -thingy API के साथ भी जोड़ा जा सकता है। अर्थात्, फ़ाइलों के साथ निर्देशिका ट्री को एम्बेड करने के लिए कच्चे import s का उपयोग करना और फिर उन्हें एक्सेस करने के लिए कुछ रनटाइम पैकेज का उपयोग करना। os.Open भी हो सकता है, लेकिन इसके स्वीकार किए जाने की संभावना नहीं है।

shurcooL/vfsgen एक साथ shurcooL/httpgzip में एक अच्छी सुविधा है जहां सामग्री को बिना डीकंप्रेसन के परोसा जा सकता है।

जैसे

    rsp.Header().Set("Content-Type", "image/png")
    httpgzip.ServeContent(rsp, req, "", time.Time{}, file)

सी ++ के लिए एक समान सुविधा प्रस्तावित की जा रही है: std::embed :

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1040r0.html
https://mobile.twitter.com/Cor3ntin/status/1208389050698215427

यह एक डिजाइन के लिए प्रेरणा के रूप में और संभावित उपयोग के मामलों को इकट्ठा करने के लिए उपयोगी हो सकता है।

मुझे पार्टी में थोड़ी देर हो गई है, लेकिन मेरे पास एक विचार था। विशेष टिप्पणियों के बजाय, एक निश्चित विशेष निर्देशिका (स्थिर), या जाहिरा तौर पर go.mod को विस्तारित करने का नो-नो दृष्टिकोण: एक नई मेनिफेस्ट फ़ाइल के बारे में जो प्रति पैकेज है: go.res

• फाइलों की एक सूची शामिल है। कोई पथ या ग्लोब नहीं, वर्तमान पैकेज निर्देशिका में केवल नाम। यदि आपको आवश्यकता हो तो इसे करने से पहले इसे एक ग्लोब से उत्पन्न करें।
  
  
  
  • __संपादित करें __ इसे शीर्ष पर एक package mypackagename लाइन की आवश्यकता हो सकती है, जैसे कि एक गो फ़ाइल में होता। वैकल्पिक रूप से, आप फ़ाइल नाम में पैकेज का नाम शामिल कर सकते हैं (उदा. mypackagename.go.res)। व्यक्तिगत रूप से, मुझे package हेडर लाइन बेहतर लगती है।
  
  
• "संसाधन" या शायद "आईओ/संसाधन" नामक एक नया कोर पैकेज। कम से कम एक फ़ंक्शन है: func Read(name string) (io.Reader, bool) वर्तमान पैकेज में एम्बेडेड संसाधनों को पढ़ने के लिए।
  
  
  
  • __संपादित करें__ सुनिश्चित नहीं है कि कोर पैकेज इस तरह से काम करते हैं। एक उत्पन्न पैकेज निजी कार्य होना पड़ सकता है (उदाहरण के लिए func readresource(name string) (io.Reader, bool) )
  
  
• यदि आप उप निर्देशिका में संसाधन चाहते हैं, तो एक go.res फ़ाइल और कम से कम एक .go फ़ाइल जोड़कर उपनिर्देशिका को एक पैकेज बनाएं। गो फ़ाइल उपनिर्देशिका पैकेज में संसाधनों तक पहुँचने के लिए आपके स्वयं के सार्वजनिक एपीआई को निर्यात करती है। गो फ़ाइल और निर्यातित एपीआई आवश्यक हैं, क्योंकि अन्य पैकेजों के संसाधन स्वचालित रूप से (डिज़ाइन द्वारा) निर्यात नहीं किए जाते हैं। आप यह भी अनुकूलित कर सकते हैं कि उन्हें इस तरह कैसे निर्यात किया जाता है।
  
  
  
  • __संपादित करें__ वैकल्पिक रूप से, यदि आपको निर्देशिका संरचना और/या संपीड़न की आवश्यकता है, तो टार संसाधन का उपयोग करें। यह वेबपैक बंडल जैसी चीज़ों की अनुमति देता है, जिन्हें पहले से ही संकलन की आवश्यकता होती है (और पूर्व-संपीड़न से लाभ हो सकता है)। उन्हें एक टार तक एक कदम आगे ले जाना सरल है।
  
  
• __संपादित करें__ एक मेनिफेस्ट की आवश्यकता है? बस go.res फ़ाइल को संसाधन के रूप में शामिल करें। हमें सूची संसाधन फ़ंक्शन बनाने की भी आवश्यकता नहीं है।

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

__ संपादित करें __ एक जीथब खोज के बाद language:go filename:go.res extension:res , ऐसा लगता है कि go.res उपयोग करने के लिए एक बहुत ही सुरक्षित फ़ाइल नाम होगा। गो रेपो में कोई मैच नहीं होते हैं, और नॉन-गो रेपो में केवल कुछ ही होते हैं।

मुझे @chris.ackermanm का विचार पसंद है। लेकिन मैं एक संयोजन पसंद करूंगा:

एक निर्देशिका के भीतर नाम स्थान निर्दिष्ट करने वाली एक go.res फ़ाइल।

यह अनुमति देता है

• जब तक नाम स्थान भिन्न होता है तब तक एकाधिक शामिल होते हैं
• पहले फाइलों को नहीं जानना और सूची तैयार करना

बाद वाले को वेबपैक के आउटपुट और पसंद से निपटना चाहिए जो अपडेट, विभिन्न विकल्पों के कारण लेआउट बदल सकता है, जो भी आप सोच सकते हैं।

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

बाद में आप फिर से लिखने की अनुमति दे सकते हैं जैसे कि

filename => stored-as.png

बस मेरे 2¢

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

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

नमस्ते

यह प्रस्ताव कमाल का है!

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

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

मैं भाषा डिजाइन या संकलक डिजाइन पर काफी अनुभवहीन हूं। इसलिए मैं ऊपर वर्णित दृष्टिकोण का उपयोग करूंगा और .goassets या अनुभाग नाम के रूप में ऐसा कुछ उपयोग करूंगा। और संपीड़न को वैकल्पिक बनाएं।

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

ऐसा लगता है कि यह elf / pe32 पर काम करता है लेकिन mach-o / plan9 क्या?

एक और मुद्दा यह है कि यह निष्पादन योग्य पर फ़ाइल हैंडल खोलने पर निर्भर करता है, यदि निष्पादन योग्य को ओवरराइट/अपडेट/हटा दिया गया है तो यह अलग डेटा लौटाएगा, सुनिश्चित नहीं है कि यह एक वैध समस्या है या एक अप्रत्याशित सुविधा है।

मुझे खुद थोड़ा सा जाना था ( डिबग/माचो का उपयोग करके), लेकिन मुझे यह काम करने वाला क्रॉस-प्लेटफ़ॉर्म प्राप्त करने का कोई तरीका नहीं दिख रहा है, मैं मैकोज़ पर निर्माण कर रहा हूं और जीएनयू बिनुटिल्स स्थापित सिर्फ mach-o-x86-64 भ्रष्ट प्रतीत होता है mach-o संरचना समझ की कमी हो सकती है और बहुत लंबा हो सकता है क्योंकि मैंने objcopy भी देखा है)।

एक और मुद्दा यह है कि यह निष्पादन योग्य पर फ़ाइल हैंडल खोलने पर निर्भर करता है

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

जो काम करता है उसका पालन क्यों न करें - उदाहरण के लिए जावा इसे कैसे करता है। मुझे चीजों की आवश्यकता होगी जो एक बड़ा गो-ईश हो, लेकिन कुछ पंक्तियों में:

• एक go.res फ़ाइल बनाएँ या go.mod को संशोधित करके उस निर्देशिका को इंगित करें जहाँ संसाधन हैं
• इस निर्देशिका की सभी फाइलें स्वचालित रूप से शामिल हैं, अंतिम निष्पादन योग्य में संकलक द्वारा कोई अपवाद नहीं है
• भाषा इन संसाधनों तक पहुँचने के लिए पथ-समान एपीआई प्रदान करती है

संपीड़न, आदि इस संसाधन बंडलिंग के दायरे से बाहर होना चाहिए और यदि आवश्यक हो तो किसी भी // go:generate स्क्रिप्ट तक होना चाहिए।

क्या किसी ने मार्कबेट्स/पीकेजीईआर को देखा है? यह वर्तमान कार्यशील निर्देशिका के रूप में go.mod का उपयोग करने का एक बहुत ही सरल समाधान है। यह मानते हुए कि index.html को एम्बेड किया जाना है, इसे खोलना pkger.Open("/index.html") । मुझे लगता है कि परियोजना में static/ निर्देशिका को हार्डकोड करने से यह एक बेहतर विचार है।

यह भी उल्लेखनीय है कि जहां तक ​​​​मैं देख सकता था, गो के पास किसी परियोजना के लिए कोई महत्वपूर्ण संरचना आवश्यकता नहीं है। go.mod सिर्फ एक फाइल है और बहुत से लोग कभी भी vendor/ का उपयोग नहीं करते हैं। मैं व्यक्तिगत रूप से नहीं सोचता कि static/ निर्देशिका कोई अच्छी होगी।

चूंकि हमारे पास मौजूदा ldflags लिंक फ्लैग -X importpath.name=value माध्यम से बिल्ड में डेटा (यद्यपि सीमित) इंजेक्ट करने का एक तरीका है, क्या उस कोड पथ को इंजेक्ट करने के लिए -X importpath.name=@filename स्वीकार करने के लिए समायोजित किया जा सकता है बाहरी मनमाना डेटा?

मुझे एहसास है कि यह मूल मुद्दे के सभी घोषित लक्ष्यों को कवर नहीं करता है, लेकिन मौजूदा -X कार्यक्षमता के विस्तार के रूप में क्या यह एक उचित कदम आगे लगता है?

(और अगर यह काम करता है तो go.mod सिंटैक्स को ldflags -X मान निर्दिष्ट करने के एक बेहतर तरीके के रूप में विस्तारित करना एक अगला उचित कदम है?)

यह एक बहुत ही रोचक विचार है, लेकिन मैं सुरक्षा प्रभावों के बारे में चिंतित हूं।

ऐसा करना बहुत आम है -X 'pkg.BuildVersion=$(git rev-parse HEAD)' , लेकिन हम go.mod को मनमानी कमांड चलाने नहीं देना चाहेंगे, है ना? (मुझे लगता है कि गो जनरेट करता है, लेकिन ऐसा कुछ नहीं है जिसे आप आमतौर पर डाउनलोड किए गए ओएसएस पैकेज के लिए चलाते हैं।) यदि go.mod इसे संभाल नहीं सकता है, तो यह एक प्रमुख उपयोग के मामले को याद कर रहा है, इसलिए ldflags अभी भी बहुत आम होगा।

फिर यह सुनिश्चित करने का दूसरा मुद्दा है कि @filename /etc/passwd या जो कुछ भी सिमलिंक नहीं है।

लिंकर का उपयोग WASM के लिए समर्थन को रोकता है, और संभवतः अन्य लक्ष्य जो लिंकर का उपयोग नहीं करते हैं।

यहां चर्चा के आधार पर, @bradfitz और मैंने एक डिज़ाइन तैयार किया जो ऊपर बताए गए दो दृष्टिकोणों के बीच में कहीं बैठता है, जो प्रत्येक के लिए सबसे अच्छा लगता है। मैंने एक मसौदा डिजाइन दस्तावेज़, वीडियो और कोड (नीचे लिंक) पोस्ट किया है। इस मुद्दे पर टिप्पणियों के बजाय, कृपया इस विशिष्ट ड्राफ्ट डिज़ाइन पर टिप्पणियों के लिए Reddit Q & A का उपयोग करें - Reddit थ्रेड्स और स्केल चर्चाएँ GitHub से बेहतर हैं। धन्यवाद!

वीडियो: https://golang.org/s/draft-embed-video
डिज़ाइन: https://golang.org/s/draft-embed-design
प्रश्नोत्तर: https://golang.org/s/draft-embed-reddit
कोड: https://golang.org/s/draft-embed-code

@rsc मेरी राय में, गो: एम्बेड प्रस्ताव संकलन-समय पर _universal_ sandboxed Go कोड निष्पादन प्रदान करने से कम है जिसमें फ़ाइलों को पढ़ना और पढ़ने वाले डेटा को रनटाइम पर खपत के लिए सबसे उपयुक्त _optimal format_ में बदलना शामिल होगा।

@atomsymbol यह इस मुद्दे के दायरे से बाहर कुछ ऐसा लगता है।

@atomsymbol यह इस मुद्दे के दायरे से बाहर कुछ ऐसा लगता है।

मुझे यह मालूम है।

मैंने प्रस्ताव को पढ़ा और कोड को स्कैन किया, लेकिन इसका उत्तर नहीं मिला: क्या इस एम्बेडिंग योजना में डिस्क पर फ़ाइल के बारे में जानकारी होगी (~os.Stat)? या ये टाइमस्टैम्प समय बनाने के लिए रीसेट हो जाएंगे? किसी भी तरह से, ये उपयोगी टुकड़ों की जानकारी है जो विभिन्न स्थानों पर उपयोग की जाती है, उदाहरण के लिए हम इसके आधार पर अपरिवर्तित संपत्तियों के लिए 304 भेज सकते हैं।

धन्यवाद!

संपादित करें: इसे रेडिट थ्रेड में मिला।

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

https://old.reddit.com/r/golang/comments/hv96ny/qa_goembed_draft_design/fytj7my/

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

फ़ाइल डेटा हैश पर आधारित एक ETag शीर्षलेख तारीखों के बारे में कुछ भी जाने बिना उस समस्या को हल कर देगा। लेकिन इसे http.HandlerFS या कुछ काम करने में सक्षम होने के लिए और संसाधनों को बर्बाद न करने के लिए इसे प्रति फ़ाइल केवल एक बार करना होगा।

लेकिन इसे http.HandlerFS या कुछ काम करने में सक्षम होने के लिए और संसाधनों को बर्बाद न करने के लिए इसे प्रति फ़ाइल केवल एक बार करना होगा।

http.HandlerFS को कैसे पता चलेगा कि fs.FS अपरिवर्तनीय था? क्या कोई IsImmutable() bool वैकल्पिक इंटरफ़ेस होना चाहिए?

http.HandlerFS को कैसे पता चलेगा कि fs.FS अपरिवर्तनीय था? क्या कोई IsImmutable() bool वैकल्पिक इंटरफ़ेस होना चाहिए?

मैं कार्यान्वयन विवरण में नहीं जाना चाहता क्योंकि मैं इन चीजों का डिजाइनर नहीं हूं लेकिन http.HandlerFS जांच सकता है कि यह एक एम्बेड है या नहीं। एफएस प्रकार और उस पर एक विशेष मामले के रूप में कार्य करें, मुझे नहीं लगता कि कोई भी चाहता है अभी FS API का विस्तार करें। हैंडलरएफएस के लिए विशेष रूप से एक फाइल सिस्टम को अपरिवर्तनीय मानने के लिए इसे बताने के लिए एक विकल्प तर्क भी हो सकता है। इसके अलावा यदि यह एप्लिकेशन स्टार्ट अप पर किया जाता है और सभी ctime/mtime में शून्य मान हैंडलर है तो उस जानकारी का उपयोग "जानने" के लिए कर सकता है कि फ़ाइल नहीं बदली है, लेकिन फाइल सिस्टम भी हैं जिनमें माइम नहीं हो सकता है या इसे अक्षम कर दिया गया है वहां भी समस्या हो सकती है।

मैं इस मुद्दे पर टिप्पणियां नहीं देख रहा था।

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

@kokes मैं विवरण के बारे में निश्चित नहीं हूँ,
लेकिन हम यह सुनिश्चित करेंगे कि एक एम्बेड की सेवा करना। HTTP पर फ़ाइलें डिफ़ॉल्ट रूप से ईटैग प्राप्त करती हैं।

मैंने जुलाई में पोस्ट किए गए डिज़ाइन ड्राफ्ट को स्वीकार करने के लिए #41191 दायर किया है।
मैं इस मुद्दे को उसी के स्थान पर समाप्त करने जा रहा हूं।
यहां शानदार प्रारंभिक चर्चा के लिए धन्यवाद।