अपने Go कोड को GitHub से न जोड़ें
Go में fully qualified URLs (अक्सर GitHub paths) को import identifiers की तरह उपयोग करने की प्रथा long-term stability, vendor lock-in, और repositories के move होने पर होने वाले painful migrations को लेकर चिंता पैदा कर रही है। Commenters custom domains, internal proxies, और vendoring जैसे विकल्पों पर विचार करते हैं, और resilience, security, convenience, तथा maintainers पर operational burden के बीच trade-offs बताते हैं। कई लोग मानते हैं कि कोई भी namespace पूरी तरह failure-proof नहीं होता, इसलिए असली चुनौती ऐसे tooling और workflows बनाना है जो hosting changes और dependency preservation को समय के साथ manageable बना दें।
Go import paths और GitHub coupling
- Go का “import == network path” डिज़ाइन repository host को API surface का हिस्सा बना देता है।
- कई लोगों को यह fragile लगता है: GitHub से किसी और forge पर जाना (या सिर्फ org rename) का मतलब कई repos और historical tags में import paths बदलना है, जिससे पुराने builds टूट सकते हैं।
- दूसरों का तर्क है कि समस्या को बढ़ा-चढ़ाकर देखा जा रहा है: rare migration के साथ search/replace या
go.mod replaceस्वीकार्य overhead है।
Custom domains / vanity URLs
- Pro–vanity domain विचार: अपना domain उपयोग करने से identity किसी एक forge से अलग हो जाती है; आप बाद में DNS या simple web handlers (nginx, Hugo templates, vanity URL servers) को नए hosts पर retarget कर सकते हैं, या यहाँ तक कि artifact registry पर भी।
- आलोचकों को चिंता है कि इससे बस SPOF कहीं और चला जाता है: domains expire हो सकते हैं, registrars TLDs हटा सकते हैं या prices बढ़ा सकते हैं, और छोड़े गए domains को takeover करके abuse किया जा सकता है।
- closed/internal code के लिए domain control को अधिक उचित माना जाता है; लंबे समय तक चलने वाले OSS के लिए कुछ लोग GitHub जैसे “stable big host” को प्राथमिकता देते हैं।
Vendoring, proxies & reproducibility
- कुछ लोग हर Go project के लिए dependencies vendoring की वकालत करते हैं: इससे offline builds, upstream के गायब होने के खिलाफ resilience, और supply-chain control बेहतर होता है।
- दूसरे इसके नुकसान बताते हैं: बड़े repos, धीमे git operations और CI, manual update work, recursive dependency complexity।
- Go का module proxy (
proxy.golang.org) और internal mirrors middle ground के रूप में उल्लेखित हैं: एक बार cache करें, फिर GitHub को सीधे hit किए बिना build करें।
Migration pain & organizational scale
- कई commenters वास्तविक migrations (GitHub → other host, domain changes) को scale पर “horrible” बताते हैं, खासकर जब बहुत सारे repos और versions एक-दूसरे पर निर्भर हों।
- Simple search/replace तब टूट जाता है जब historical versions को rebuild करने की क्षमता बनाए रखनी हो; अंततः पुराने commits को फिर से rewrite करने के लिए branching/tagging करनी पड़ती है।
- Monorepos, जहाँ हर dependency का एक ही version होता है, इससे कुछ हद तक बचाते हैं लेकिन अपनी लागतें भी लाते हैं।
Security, integrity & package-system design
- इन चिंताओं को लेकर:
- Dead या hijacked domains/hosts का malicious code serve करना।
- Go का स्थिर identifiers या content addressing के बजाय locations पर निर्भर रहना।
- सुझाए गए सुधार: content-addressable imports,
go.modमें hashes (सिर्फgo.sumनहीं), signed modules, बेहतर redirect/alias mechanisms, या Software Heritage जैसी archives पर fallback। - कुछ लोग Go की package story को एक underdesigned system मानते हैं जिसमें features (modules, proxies,
replace) धीरे-धीरे जुड़ते गए, बजाय एक coherent registry-based design के।