2013-07-09 5 views
87

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

myproject/ 
├── binary1.go 
├── binary2.go 
├── package1.go 
└── package2.go 

मैं कई तरीके की कोशिश की, लेकिन मैं package1.gobinary1.go या binary2.go और इतने पर में काम करने के लिए कैसे मिलता है?

उदाहरण के लिए; मैं import "package1" में सक्षम होना चाहता हूं और फिर go build binary1.go चलाने में सक्षम होना चाहता हूं और त्रुटि को फेंकने के बिना सबकुछ ठीक काम करता है कि पैकेज GOROOT या GOPATH पर नहीं पाया जा सकता है। मुझे इस तरह की कार्यक्षमता की आवश्यकता क्यों है बड़े पैमाने पर परियोजनाओं के लिए; मैं कई अन्य पैकेजों को संदर्भित नहीं करना चाहता हूं या उन्हें एक बड़ी फ़ाइल में रखना नहीं चाहता हूं।

+2

आपको प्रत्येक बाइनरी के लिए अपनी निर्देशिका में स्रोत फ़ाइलों को रखना होगा। – fuz

उत्तर

103

संपादित करें 2: विक्रेता विधि अभी भी वैध है और बिना किसी समस्या के काम करती है। vendor परियोजनाओं का प्रबंधन करने के लिए defacto तरीका है। हालांकि, यह काफी हद तक एक मैन्युअल प्रक्रिया है, इस वजह से आपके लिए आपके विक्रेता पैकेजों का प्रबंधन करने के लिए एक नया टूल आया है: dep

depwill be part of the toolchain in the future; यह कुछ तृतीय-पक्ष टूल नहीं है जिसे मैं अनुशंसा कर रहा हूं। यह भविष्य है :)। यह उपयोग करने के लिए एक बहुत ही सरल उपकरण है; documentation देखें।


संपादित करें 1: मेरा पुराना तरीका काम करता है, यह अब करने के लिए "सही" तरीका नहीं है। आपको विक्रेता क्षमताओं का उपयोग करना चाहिए जो डिफ़ॉल्ट रूप से Go 1.6 में सक्षम हैं; see। आप मूल रूप से vendor निर्देशिका में अपने "बाहरी" या "आश्रित" पैकेज जोड़ते हैं; संकलन पर संकलक पहले इन पैकेजों का उपयोग करेंगे।


मिला।

binary1.go

... 
import (
     "./package1" 
    ) 
... 

तो मेरे वर्तमान निर्देशिका संरचना इस तरह दिखता है: मैं package1 का एक सबफ़ोल्डर बनाने और फिर binary1.go में import "./package1" साथ आयात और इस तरह binary2.go स्क्रिप्ट द्वारा GOPATH साथ सक्षम आयात स्थानीय पैकेज था:

myproject/ 
├── binary1.go 
├── binary2.go 
├── package1/ 
│ └── package1.go 
└── package2.go 

मुझे यह भी ध्यान रखना चाहिए कि सापेक्ष पथ (कम से कम 1.5 में) भी काम करते हैं; उदाहरण के लिए:

import "../packageX" 
+3

यह तब तक ठीक काम करता है जब तक आपके पास दो उपफोल्डर नहीं होते हैं, जिनमें से किसी एक का जिक्र होता है। उदाहरण के लिए, यदि पैकेज 2 एक उपफोल्डर भी था और इसे पैकेज 1 की आवश्यकता थी, तो प्रणाली टूट जाती है। – Carl

+6

'आयात" ../ पैकेज 1 "' –

+8

सापेक्ष आयात पथ एक [बुरा विचार] हैं (https://golang.org/cmd/go/#hdr-Relative_import_paths)। –

42

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

बस

import "myproject/packageN" 

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

आयात रास्तों की अवधारणा कुछ महत्वपूर्ण गुण होते हैं:

  • आयात रास्तों वैश्विक रूप से अद्वितीय होना हो सकता है।
  • GOPATH के साथ संयोजन के रूप में, आयात पथ को एक निर्देशिका पथ में संगत रूप से अनुवादित किया जा सकता है।
  • GOPATH के तहत कोई भी निर्देशिका पथ अनजाने में आयात पथ में अनुवाद किया जा सकता है।

उपर्युक्त सभी संबंधित सापेक्ष आयात पथों का उपयोग करके बर्बाद हो गए हैं। ऐसा मत करो।

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

+1

के साथ शुरू होना चाहिए, मैं ** परिचय ** और ** GOPATH ** की बेहतर समझ के लिए इस परिचय वीडियो को देखने की अनुशंसा करता हूं। https://www.youtube.com/watch?v=XCsL89YtqCs –

+4

मुझे लगता है कि यह बुरी सलाह है। यदि आप वर्जनिंग के लिए gopkg.in का उपयोग कर समाप्त करते हैं, उदाहरण के लिए, ऊपर वर्णित अनुसार, आप अपने "मिनी" पैकेजों के लिए पूर्ण आयात पथ के साथ भाग्य से बाहर हैं। या तो आप स्रोत रेपो तोड़ते हैं या संस्करण वाला बेकार हो जाता है। – Greg

+0

'आयात" myproject/packageN "'। 'myproject' फ़ोल्डर का नाम है जो मेरी परियोजना रखता है? – securecurve

30

शायद आप अपने पैकेज को मॉड्यूलर करने का प्रयास कर रहे हैं। मुझे लगता है कि package1 और package2 एक ही पैकेज के हिस्से में हैं, लेकिन पठनीयता के लिए आप उन्हें कई फाइलों में विभाजित कर रहे हैं।

यदि पिछला मामला तुम्हारा था, तो आप उसी पैकेज नाम का उपयोग उन गुणक फ़ाइलों में कर सकते हैं और ऐसा होगा जैसे एक ही फ़ाइल थी।

यह एक उदाहरण है:

add.go

package math 

func add(n1, n2 int) int { 
    return n1 + n2 
} 

subtract.go

package math 

func subtract(n1, n2 int) int { 
    return n1 - n2 
} 

donothing.go

package math 

func donothing(n1, n2 int) int { 
    s := add(n1, n2) 
    s = subtract(n1, n2) 
    return s 
} 

मैं एक जाओ विशेषज्ञ नहीं हूँ और यह StackOveflow में मेरी पहली पोस्ट है , इसलिए यदि आपके पास कुछ सलाह है तो यह अच्छी तरह से प्राप्त होगा।

3

अपनी परियोजना में "स्थानीय" पैकेज जोड़ने के लिए, एक फ़ोल्डर जोड़ें (उदाहरण के लिए "package_name")। और उस फ़ोल्डर में अपनी कार्यान्वयन फाइलें डाल दें।

src/github.com/GithubUser/myproject/ 
├── main.go 
└───package_name 
     └── whatever_name1.go 
     └── whatever_name2.go 

अपने package main में ऐसा करते हैं:

import "github.com/GithubUser/myproject/package_name" 

कहाँ package_name फ़ोल्डर का नाम है और यह पैकेज फ़ाइलें में इस्तेमाल किया नाम से मेल खाना चाहिए whatever_name1.go और whatever_name2.go। दूसरे शब्दों में उप-निर्देशिका वाली सभी फाइलें एक ही पैकेज के होनी चाहिए।

जब तक आप आयात में मूल फ़ोल्डर को पूरा पथ निर्दिष्ट करते हैं, तब तक आप अधिक उपनिर्देशिकाएं घोंसला कर सकते हैं।

संबंधित मुद्दे