माना। निर्भरता-लिंक के लिए पाइप का वर्तमान व्यवहार वास्तव में बेकार है।

4295

3610

[#3939 में लिखा, मेरी टिप्पणी को यहां ले जा रहा हूं]

तो, यहां मुख्य मुद्दा है: अगर मैं requirements.txt फ़ाइल का उपयोग नहीं करना चाहता (क्योंकि, कहें, मुझे setup.cfg में निर्दिष्ट सभी घोषणात्मक निर्भरताएं चाहिए), मुझे कैसे निर्दिष्ट करना चाहिए a निर्भरता के रूप में यूआरएल?

यह काम नहीं करता है:

[options]
install_requires = 
  requests==2.18.4
  https://github.com/example/example_lib/archive/master.zip

मुझे यह भी लगता है कि निर्भरता लिंक अजीब और ड्रॉप करने के लिए ठीक हैं, लेकिन कैनोनिक रूप से यह उपयोग केस कैसे परोसा जाता है यदि उनके साथ नहीं?

एक और मुद्दा यह है कि dependency_links स्पष्ट रूप से setup.cfg में निर्दिष्ट नहीं किया जा सकता है, केवल setup.py तर्क के रूप में। यदि उन्हें पदावनत किया जाना है, तो इसे ठीक किया जाना चाहिए।

क्या इस बारे में कोई खबर है? क्या कोई विकल्प प्रगति पर है? निर्भरता_लिंक्स_ पुस्तकालयों के आंतरिक/निजी वितरण के लिए एकमात्र विकल्प प्रतीत होता है।

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

मुझे नहीं लगता कि हम अकेले हैं: https://stackoverflow.com/questions/3472430/how-can-i-make-setuptools-install-a-package-thats-not-on-pypi

devpi तरह @robertour उपकरण वर्षों के बाद से एक और अधिक स्पष्ट दृष्टिकोण अब समर्थन

@dstufft btw - मैं यह तर्क देना चाहूंगा कि देवपी का अस्तित्व निर्भरता लिंक को अनावश्यक बनाने की समस्या का अधिक स्वच्छ समाधान प्रदर्शित करता है

IMHO इंडेक्स इनहेरिटेंस + व्हाइट लिस्टिंग/ब्लैकलिस्टिंग एक ऑप्स स्तर पर अधिक सुसंगत और अधिक समझने योग्य है

@RonnyPfannschmidt , सुझाव के लिए धन्यवाद, ऐसा लगता है कि मुझे कुछ महत्वपूर्ण याद आ रहा है (इस reddit से अधिक सहमत नहीं हो सकता:

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

आदर्श रूप से, मुझे एक ऐसा विकल्प चाहिए जो मुझे मेरी लाइब्रेरी में एक फ़ाइल जोड़ने, या setup.py में कुछ पंक्तियों को जोड़ने से अधिक नहीं लेगा।

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

4175 का मतलब है कि पीईपी 508 यूआरएल समर्थन पीआईपी 10 में होगा। मुझे लगता है कि इसे बंद किया जा सकता है।

विचार @pfmoore @dstufft?

मैंने सोचा था कि https://github.com/pypa/pip/pull/4175/commits/86b07792e7ae762beeaeb471ab9db87e31bc285d का मतलब है कि निर्भरता के लिए @ सिंटैक्स का उपयोग नहीं किया जा सकता है, इसलिए इसका मतलब है कि #4175 इस समस्या का समाधान नहीं है . वहाँ पर टिप्पणियाँ यह थीं कि हमें निर्भरता के लिए @ समर्थन को लागू नहीं करना चाहिए जब तक कि PyPI इसका उपयोग करने वाले अपलोड को ब्लॉक करने में सक्षम नहीं था (क्योंकि हम PyPI से कुछ स्थापित नहीं करना चाहते हैं ताकि मनमाने URL से सामान हड़प सकें) , संभवतः)।

इसे तब तक पदावनत नहीं किया जाना चाहिए जब तक कि कोई विकल्प मौजूद न हो, अर्थात PEP 508 समर्थन। तब तक बहुत से लोग इसका इस्तेमाल कर रहे हैं।

इसके लिए उचित कार्यप्रवाह क्या है?

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

अब मेरे सभी उपयोगकर्ताओं को पाइप के साथ मेरा टूल इंस्टॉल करते समय --प्रोसेस-निर्भरता-लिंक जोड़ना होगा, जो एक बहिष्कृत और यहां तक ​​​​कि एक बार हटाए गए ध्वज है?

क्या setup.py में कोई विकल्प है जो मुझे याद आ रहा है या वास्तव में इसके आसपास कोई रास्ता नहीं है? ऐसा लगता है कि ऐसा करने का एकमात्र व्यवहार्य तरीका एक फोर्कड पीपीआई पैकेज को धक्का देना है। एक बार जब आपका पुल अनुरोध विलय हो जाता है, तो यह उपयोगकर्ता के भ्रम को जोड़ने वाला है।

आइए इस पर आते हैं।

--process-dependency-links पास आज वास्तव में कोई विकल्प नहीं है। इसलिए, मैं सुझाव दूंगा कि हम आगे बढ़ें और इसे हटा दें।

हालांकि, ध्वज का मतलब यह है कि पाइप मनमाने ढंग से यूआरएल तक पहुंच जाएगा - इसके बारे में इसके साथ एक चेतावनी संलग्न होनी चाहिए।

@pradyunsg जब तक कि इसे अच्छे के लिए मारने की कोई वास्तविक योजना न हो, मैं दृढ़ता से सुझाव देता हूं कि उस ज़ोंबी को आराम करने दें या हटा दें

मुझे नहीं लगता कि जिन लोगों को वास्तव में इसकी आवश्यकता है, उनके पास स्थिति को ठीक करने के लिए कोई प्रोत्साहन है, जब तक कि पाइप कहता है "नहीं, मैं आपका कर्ज नहीं लेता"

एक पाइप रखरखाव के रूप में, मेरी चिंता पीआईपी को शोषण के लिए वेक्टर बनने की इजाजत नहीं दे रही है। पिप डिफ़ॉल्ट सूचकांक के रूप में PyPI को मानता है, इसलिए वहाँ PyPI में निहित विश्वास है। तो मेरे पहले प्रश्न हैं:

1. क्या PyPI पर पैकेज मौजूद हैं जिनमें dependency_links मेटाडेटा है?
2. क्या dependency_links (या यह पहले से ही ऐसा करता है) के साथ परियोजनाओं के अपलोड से इनकार करने के लिए पीईपीआई को संशोधित किया जा सकता है?
3. वैकल्पिक रूप से, क्या पाइप केवल PyPI से डाउनलोड किए गए पैकेजों के लिए निर्भरता लिंक (चाहे विकल्प सेट हो) को संसाधित करने से मना कर सकता है?

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

तो, निम्नलिखित परिवर्तनों के साथ:

1. पिप कभी भी पीईपीआई से निर्भरता लिंक को संसाधित नहीं करेगा (या तो स्पष्ट रूप से, या सिर्फ इसलिए कि हम जानते हैं कि वे वहां नहीं हैं)
2. --process-dependency-links ध्वज अप्रचलित है, लेकिन केवल कस्टम अनुक्रमणिका के लिए काम करता है।

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

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

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

क्या आपका मतलब #4175 है? जो 86b0779 की वजह से ब्लॉक है? हो सकता है कि हम https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L167 को संशोधित कर सकते हैं ताकि केवल त्रुटि दे सकें यदि comes_from PyPI है?

फिर हम --process-dependency-links लिए मूल्यह्रास चेतावनी को यह कहने के लिए बदल सकते हैं कि उपयोगकर्ताओं को @ सिंटैक्स पर स्विच करना चाहिए, और उचित मूल्यह्रास अवधि के बाद --process-dependency-links को छोड़ देना चाहिए (हमें शुरू करना होगा घड़ी उस बिंदु से टिक जाती है जहां @ सिंटैक्स उपलब्ध हो जाता है)।

@pfmoore हाँ ठीक यही है, और यह आगे बढ़ने के संभावित रास्ते की तरह लगता है।

ठीक है। अगर कोई और इसे पहले नहीं पाता है, तो मैं पीआर लिखने के बारे में देखूंगा।

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

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

इसका मतलब होगा:

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

मैंने वह कल टाइप किया था लेकिन नहीं भेजा। अब मुझे एहसास हुआ कि यह मूल रूप से @pfmoore की आखिरी टिप्पणी जैसा ही है।

_वाह!

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

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

मुझे सुरक्षा बनाम उपयोग में आसानी के सवालों पर अपने फैसले पर भरोसा नहीं है।

मेरा झुकाव इस ओर है: "डिफ़ॉल्ट रूप से सुरक्षित रहें" और कम सुरक्षित व्यवहार के लिए ऑप्ट-इन करें।

इससे पहले कि हम स्विच को आगे बढ़ाना शुरू करें, परियोजनाओं को निर्भरता लिंक से @ सिंटैक्स पर कैसे स्विच करना चाहिए, इस पर स्पष्ट दस्तावेज़ीकरण

मुझे अच्छा लगता है।

मेरा झुकाव इस ओर है: "डिफ़ॉल्ट रूप से सुरक्षित रहें" और कम सुरक्षित व्यवहार के लिए ऑप्ट-इन करें।

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

मेरे विचार से, "यदि पैकेज किसी ऐसे सर्वर से आ रहा है जिसे आपने स्पष्ट रूप से उपयोग करने का विकल्प चुना है" URL लिंक की अनुमति देने के लिए पर्याप्त ऑप्ट इन है।

देखो? ऐसा नहीं है कि मेरे पास राय नहीं

उपयोग के मामलों वाले लोगों के रास्ते में अतिरिक्त बाधाएं न डालें जो उनके वर्कफ़्लो के लिए स्पष्ट रूप से महत्वपूर्ण हैं, लेकिन जहां हम उन ट्रेड-ऑफ को ठीक से नहीं समझते हैं जो उन्हें करना है।

काफी उचित। यदि कुछ उपयोगकर्ता अपने वर्कफ़्लो में अंतर्दृष्टि प्रदान कर सकते हैं, तो यह अच्छा होगा।

"यदि पैकेज किसी ऐसे सर्वर से आ रहा है जिसे आपने स्पष्ट रूप से उपयोग करने का विकल्प चुना है" URL लिंक की अनुमति देने के लिए पर्याप्त ऑप्ट इन है।

मुझे यहाँ यकीन नहीं है। :/

देखो? ऐसा नहीं है कि मेरी कोई राय नहीं है, बस मुझे यकीन नहीं है कि मेरे पूर्वाग्रह दिखाई नहीं दे रहे हैं

हेहे।

काफी उचित। यदि कुछ उपयोगकर्ता अपने वर्कफ़्लो में अंतर्दृष्टि प्रदान कर सकते हैं, तो यह अच्छा होगा।

मेरे विचार से, "यदि पैकेज किसी ऐसे सर्वर से आ रहा है जिसे आपने स्पष्ट रूप से उपयोग करने का विकल्प चुना है" URL लिंक की अनुमति देने के लिए पर्याप्त ऑप्ट इन है।

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

इसे तब तक ऑप्ट-इन किया जा सकता है, जब तक इसे एक लाइन में किया जा सकता है।

यह वास्तव में सीधे लिंक (HTTPS/आदि मानकर) का उपयोग करने के लिए एक सुरक्षा समस्या नहीं है, यह केवल एक उपलब्धता है। चूँकि हम उन्हें PyPI से अस्वीकृत कर रहे हैं, तो मैं कहूंगा कि यह काफी अच्छा है और हमें दूसरे ध्वज की आवश्यकता नहीं है।

मेरे काम में हम @pfmoore उल्लेखित कुछ उपयोग मामलों में
हालाँकि, मुझे फ़ाइल सिस्टम स्थान का संदर्भ देने वाले किसी व्यक्ति के संभावित उपयोग का मामला भी दिखाई देता है ...
क्या श्वेतसूचीबद्ध मेजबानों/स्थानों की सूची प्रदान करना उचित होगा? ध्वज का नाम IMO होना चाहिए, जैसा कि @pradyunsg ने सुझाव दिया है, उपयोगकर्ता को इसमें शामिल जोखिमों से अवगत कराने के लिए पर्याप्त वर्णनात्मक होना चाहिए। शायद --whitelisted-host ?

@masdeseiscaracteres मुझे लगता है कि आपने गलत समझा होगा - मैं सुझाव दे रहा था कि यदि कोई पैकेज पीईपीआई से पुनर्प्राप्त किया गया था, तो हम असफल हो जाएंगे यदि इसकी कोई निर्भरता @ संदर्भ के माध्यम से निर्दिष्ट की गई हो। लेकिन पीईपीआई पर वैसे भी ऐसा कोई मामला नहीं होना चाहिए (हम किसी बिंदु पर उन्हें अस्वीकार करने की उम्मीद कर रहे हैं, हम अभी तक इसे सेट अप करने में सक्षम नहीं हैं)। @ संदर्भों के अन्य सभी उपयोग ठीक रहेंगे।

ऐसा लगता है कि हम एक पीआर के साथ आगे बढ़ने जा रहे हैं जो कि https://github.com/pypa/pip/issues/4187#issuecomment -389846189 में @pfmoore द्वारा वर्णित है।

पीआर का स्वागत है। :)

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

अगर कोई ऐसे टेस्ट केस का उदाहरण प्रदान कर सकता है जो बेहद मददगार होगा।

एक मौजूदा परीक्षण test_install_pep508_with_url_in_install_requires जो इसे प्रदर्शित करता है।

जहां तक ​​पीईपीआई से इंस्टाल करते समय गलती करने की बात है, तो मुझे यूआरएल की आवश्यकता वाले पीईपीआई पर वास्तव में कुछ अपलोड करने से बेहतर विकल्प नहीं दिख रहा है। मैंने इस उद्देश्य के लिए PyPI पर एक पैकेज अपलोड किया है। https://pypi.org/project/pep-508-url-deps/

एक और बात है -- comes_from कोई URL या पथ नहीं है, यह 'box==0.1.0 from file:///private/tmp/box' की तर्ज पर एक स्ट्रिंग है। जो कोई भी इस मुद्दे को ठीक करना चाहता है, उसे अब त्रुटि को दूर करने का एक बेहतर तरीका निकालना होगा, ताकि हमें इस बारे में जानकारी हो कि पैकेज कहां से आता है। :)

@pfmoore यह मुद्दा मेरे दिल के करीब और प्रिय है 😄 क्या @pradyunsg का अपलोड आपको वह देता है

@bstrdsmkr नहीं, और जैसा कि @pradyunsg कहते हैं, यह उतना आसान नहीं है जितना मैंने सोचा था, क्योंकि comes_from स्रोत URL नहीं है। इसलिए मुझे नहीं पता कि मेरे पास अब समय कब होगा (इस सुविधा के लिए मेरे पास कोई व्यक्तिगत उपयोग नहीं है, इसलिए यह मेरी प्राथमिकता सूची में उच्च नहीं है)।

जैसा कि ऊपर उल्लेख किया गया है, पीआर का स्वागत है :-)

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

मेरी समझ यह है कि वांछित सुधार कुछ ऐसा है:

if req.url and is_like(req.url, PYPI.url):
    raise

https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L172 में
जहां is_like() रिटर्न True अगर यूआरएल एक ही डोमेन पर रूट करता है। क्या वो सही है?

हां। मुझे भी ऐसा ही लगता है। वह कोड परिवर्तन होगा।

और, हमें परीक्षण और एक समाचार प्रविष्टि जोड़ने/अपडेट करने की आवश्यकता होगी।

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

एक पाइप रखरखाव के रूप में, मेरी चिंता पीआईपी को शोषण के लिए वेक्टर बनने की इजाजत नहीं दे रही है। पिप डिफ़ॉल्ट सूचकांक के रूप में PyPI को मानता है, इसलिए वहाँ PyPI में निहित विश्वास है।

नहीं, स्पष्ट विश्वास है। और निर्भरता में बाहरी स्रोतों का उपयोग करने के खिलाफ सुरक्षा उपायों को जोड़ने से IMHO स्थिति में सुधार नहीं करेगा: सार्वजनिक रूप से उपलब्ध VCS की तुलना में pypi में मैलवेयर छिपाना अधिक सुविधाजनक है।

IMHO एक बेहतर तरीका यह होगा कि डेवलपर के VCS को प्राथमिक स्रोतों के रूप में उपयोग करें और उन्हें एक रजिस्ट्री के रूप में pypy और कुछ मजबूत क्रिप्टोग्राफ़िक प्रमाण के साथ एक कैशिंग प्रॉक्सी रखें कि VCS में सामग्री pypy से प्राप्त सामग्री के समान है। मेरा मतलब है

0 पंजीकरण

dev -- public key --> pypa

1 अपलोडिंग

setuptools -- git+https:/.... --> pypa
pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks the signature matches the dev

2 निष्क्रिय:

pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks it

2 पुनः प्राप्त करना

flips a coin
if coin == 1:
  pip -- give me package git+https:/... --> pypi
  pip <-- signature || content -- pypi
  pip -- give me the signature --> vcs
  pip <-- signature -- vcs
else:
  pip -- give signature of package git+https:/... --> pypi
  pip <- signature -- pypi
  pip --> Tor --> give me that commit --> vcs
  pip <-- Tor <-- here -- vcs


pip checks if the signature matches the public key and signature from pypa
pip -- give me public key --> keyserver
pip <-- PK -- keyserver
pip checks signature given by VCS against the sdist given by pypy
pip caches public key and repo location

1 स्थापित स्रोत हस्ताक्षर के कारण वीसीएस में मेल खाते हैं
2 लेखक भी मेल खाता है
3 pypa नए उपयोगकर्ताओं के साथ धोखा कर सकता है, लेकिन पुराने लोगों द्वारा धोखाधड़ी का पता लगाया जा सकता है
4 लेखक pypy को दिए गए वेब इंटरफ़ेस शाखा में दिखाकर धोखा दे सकता है और pypy को दूसरी शाखा भेज सकता है। अगर हम शाखा को यूआरआई का अनिवार्य हिस्सा बना दें तो यह ठीक से काम नहीं करेगा।

@KOLANICH मुझे लगता है कि जब आप pypy/pypa कहते हैं तो आपका मतलब PyPI (पायथन पैकेजिंग इंडेक्स) से है। PyPy, Python का एक वैकल्पिक कार्यान्वयन है। PyPA (पायथन पैकेजिंग अथॉरिटी) स्वयंसेवकों का एक समूह है जो पायथन पैकेजिंग स्पेस में प्रमुख परियोजनाओं को बनाए रखता है। कृपया, परिवर्णी शब्दों को सही करें या उनका उपयोग करने से परहेज करें।

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

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

कम नहीं, यह इस चर्चा के लिए सही जगह नहीं है। यदि आप पीईपीआई के नए स्वरूप का प्रस्ताव करना चाहते हैं, तो मेरा सुझाव है कि आप https://github.com/pypa/warehouse पर एक चर्चा शुरू

सुझाव के लिए धन्यवाद।

देखें #5571 -- इसके लिए पीआर कि इसे बाद में रिलीज करने के लिए क्यों धकेला गया है।

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

इसके अलावा, यह और भी भ्रमित करने वाला है: जब आप PyPI कहते हैं तो आपका क्या मतलब होता है? क्या आपका मतलब किसी ऐसे सर्वर से है जो PyPI इंटरफ़ेस (जैसे। आर्टिफ़ैक्टरी) को लागू करता है, या, विशेष रूप से, pypi.org?

अब, जाहिर है, कोई व्यक्ति जो setuptools (उर्फ रनिंग setup.py install ) के माध्यम से और pip install का उपयोग करके पैकेज स्थापित करने में दोनों का समर्थन करना चाहता है, अब अचार में होगा। कई अन्योन्याश्रित पैकेजों से निपटने के लिए इस स्थिति में किसी के लिए निर्भरता लिंक निर्दिष्ट करना एकमात्र तरीका है।

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

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

@ wvxvw-traiana मुझे लगता है कि आप पीआर #5571 से चूक गए हैं
इससे पहले पीआर (और वर्तमान रिलीज में - 18.0) पाइप पीईपी 508 सिंटैक्स के माध्यम से निर्दिष्ट किसी भी निर्भरता को स्थापित करने से इंकार कर देगा।

उसके बाद पीआर (पहले से विलय हो गया है तो 18.1+ में होना चाहिए) पीआईपी केवल ऐसी निर्भरताओं को मना कर देगा यदि पैकेज जो उन पर निर्भर करता है वह pypi.org से आता है।

यदि आप अपने निजी रेपो से एक पैकेज स्थापित करते हैं जो कि पीपीआई से सामान पर निर्भर करता है, तो जाहिर है कि यह ठीक है।
यदि आप pypi.org से एक पैकेज स्थापित करते हैं जो आपके निजी रेपो से सामान पर निर्भर करता है, तो वह विफल हो जाता है।
यदि आप अपने निजी रेपो से एक पैकेज स्थापित करते हैं जो आपके निजी रेपो में सामान पर निर्भर करता है, तो यह ठीक है।

आशा है कि यह चीजों को स्पष्ट करने में मदद करता है

@bstrdsmkr क्या यह वही मूल है या pypi एक विशेष मामला है? अर्थात

यदि आप अपने निजी रेपो से एक पैकेज स्थापित करते हैं जो एक अलग निजी रेपो से सामान पर निर्भर करता है।

इसके पीछे के कारणों पर कुछ और संदर्भ जोड़ने के लिए:

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

कोई है जो setuptools (उर्फ रनिंग setup.py install) के माध्यम से पैकेज स्थापित करने और पाइप इंस्टॉल का उपयोग करके दोनों का समर्थन करना चाहता है, अब अचार में होगा।

अगर सही है, तो ऐसा इसलिए है क्योंकि setuptools ने सीधे यूआरएल लिंक के लिए समर्थन लागू नहीं किया है, जो एक सहमत मानक है। उनके साथ इसे उठाने के लिए स्वतंत्र महसूस करें।

यदि आप अपने निजी रेपो से एक पैकेज स्थापित करते हैं जो एक अलग निजी रेपो से सामान पर निर्भर करता है।

यह ठीक काम करता है। पीपीपीआई शामिल नहीं है।

ठीक है, इसलिए, एक ओर, मुझे खुशी है कि इसका मुझ पर कोई प्रभाव नहीं पड़ा।

दूसरी ओर, यह "फिक्स" लगता है, मैंने इसे कैसे रखा ... काम करना बहुत आसान है।

echo "not-pypi 151.101.61.63" >> /etc/hosts
pip install --index-url not-pypi

मेरा व्यवसाय नहीं, वास्तव में, लेकिन वास्तव में सतह-स्तर के दृष्टिकोण की तरह लगता है। (अन्य हमले वेक्टर का उल्लेख अन्य टिप्पणियों में किया गया था, जहां आप setup.py में जो चाहें डाउनलोड कर सकते हैं)।

यह उपयोगकर्ताओं के लिए https://github.com/pypa/pip/pull/4175#issuecomment -266305694 देखें।

@dpwrussell pypi.org एक विशेष मामला है। किसी भी निजी रेपो के लिए कोई भी निजी रेपो परिवर्तन के बाद ठीक काम करता है।

@ wvxvw-traiana यह आपको स्वयं ऐसा करने से रोकने के लिए नहीं है। यह किसी और को आपके साथ ऐसा करने से रोकने के लिए है जब आपको लगता है कि आप सिर्फ pypi.org से एक पैकेज स्थापित कर रहे हैं

वर्तमान चर्चा से असंबंधित, मैं इसे फिर से खोल रहा हूं क्योंकि हमने वास्तव में इसके लिए बहिष्करण चेतावनी को अपडेट नहीं किया है।

5726 पीईपी 508 यूआरएल के उपयोग का सुझाव देने वाली भाषा जोड़ता है, जो आईएमओ इसके लिए आखिरी बिट है।

ठीक है फिर। मुझे संक्षेप में बताएं:

• निर्भरता लिंक अभी भी बहिष्कृत हैं और अब पाइप 19.0 में हटाने के लिए निर्धारित हैं।
• इसके लिए मानक समर्थित प्रतिस्थापन पीईपी 508 यूआरएल निर्भरता है
• PyPI से स्थापित करते समय, यदि किसी पैकेज में PEP 508 URL निर्भरताएँ हैं, तो इसके परिणामस्वरूप पाइप स्थापना को निरस्त कर देगा।

@pfmoore ने इन फैसलों के कारणों को यहां विस्तार से बताया है: https://github.com/pypa/pip/issues/4187#issuecomment -415067034

@pradyunsg setup.py में install_requires में PEP 508 URL निर्भरता की अनुमति कब दी जाएगी? क्या कोई तिथि निर्धारित है?

पिप की अगली रिलीज़ में -- वह 18.1 है, जो अक्टूबर के लिए निर्धारित है। आप https://pip.pypa.io/en/latest/Development/release-process/ पर पाइप के 3 महीने के रिलीज चक्र के बारे में अधिक पढ़ सकते हैं। :)

पीईपी 508 यूआरएल निर्भरता एक व्यवहार्य विकल्प बनने से पहले https://github.com/pypa/wheel/issues/249 को संबोधित करने की जरूरत है।

पीईपी 508 यूआरएल निर्भरता एक व्यवहार्य विकल्प बनने से पहले pypa/wheel#249 को संबोधित करने की जरूरत है।

इस संबोधित किया गया है।

पिप 18.1 रिलीज नोट्स में यह कहता है

PEP 508 URL आवश्यकताओं को निर्भरता के रूप में उपयोग करने की अनुमति दें।

एक सुरक्षा उपाय के रूप में, यदि वे पैकेज PyPI पर होस्ट नहीं किए गए पैकेज पर निर्भर करते हैं, तो PyPI से पैकेज स्थापित करते समय pip एक अपवाद उठाएगा। भविष्य में, PyPI ऐसे बाहरी URL निर्भरता वाले पैकेजों को सीधे अपलोड करने से रोक देगा। (#4187)

तो इसका मूल रूप से मतलब है कि निर्भरता को URL का उपयोग करके निर्दिष्ट किया जा सकता है, लेकिन यदि वे PyPI URL नहीं हैं तो पैकेज को पाइप का उपयोग करके स्थापित नहीं किया जा सकता है? हो सकता है कि मैं इसे पूरी तरह गलत कर रहा हूं, लेकिन फिर यूआरएल निर्भरताओं का उपयोग कैसे किया जाना चाहिए?

@JarnoRFB पैकेज जो PyPI पर होस्ट किए गए हैं, उनमें url निर्भरताएँ नहीं हो सकती हैं।

पैकेज जो PyPI पर होस्ट नहीं किए गए हैं उनमें url निर्भरताएं हो सकती हैं। यदि आप सीधे जीथब (उदाहरण के लिए) से पैकेज स्थापित करते हैं तो यूआरएल निर्भरता हल हो जाएगी और स्थापित हो जाएगी। ऐसी स्थापना का एक उदाहरण:

pip install git+https://github.com/bstrdsmkr/some_package.git

अनिवार्य रूप से, यदि आप यूआरएल से स्थापित करते हैं, तो यह यूआरएल पर निर्भर हो सकता है, अन्यथा यह नहीं हो सकता है। और केवल स्पष्टता के लिए, इसमें url और गैर-url दोनों निर्भरताएँ भी हो सकती हैं

एक मामूली जोड़:

...यदि आप किसी url से इंस्‍टॉल करते हैं, तो यह urls पर निर्भर हो सकता है

...यदि आप किसी URL (VCS या अन्य) या किसी स्थानीय फ़ाइल या पैकेज अनुक्रमणिका से स्थापित करते हैं जो PyPI नहीं है, तो यह...

तो क्या पाइप का एक संस्करण है जो उपरोक्त विवरण के अनुसार install_requires को संसाधित करता है? मैं ऊपर दिए गए टैग को समाप्त नहीं कर सकता कि अंतिम स्थिति क्या थी और वर्तमान पाइप प्रलेखन install_requires प्रलेखन को setuptools में इंगित करता है जो अभी भी dependency_links का उपयोग करने के लिए कहता है।

स्वयं दस्तावेज़ों से बात नहीं कर सकता, लेकिन गैर-पीईपीआई पैकेजों को यूआरएल से निर्भरता स्थापित करने की अनुमति देने के लिए यह "छूट" पाइप 18.0 में जारी की गई थी

AFAIK, install_requires में URL निर्भरता पाइप 18.1 के बाद से समर्थित है:

PEP 508 URL आवश्यकताओं को निर्भरता के रूप में उपयोग करने की अनुमति दें।

स्रोत: रिलीज नोट्स

उह, मेरी ओर से टाइपो - @pietrodn स्पष्ट रूप से सही है

मैं यहां उन लोगों के लिए एक छोटा लेकिन सफल उदाहरण छोड़ना चाहता हूं जो पहली बार इस मुद्दे पर आए थे (मेरी तरह) इस बारे में कि क्या करना है - प्रक्रिया-निर्भरता-लिंक। इस वर्कफ़्लो का उपयोग करते हुए, मेरे उपयोगकर्ता अब GitHub या स्थानीय स्रोतों (PyPI नहीं) से पाइप इंस्टाल करने में सक्षम हो गए हैं, या pip install आवश्यकताएँ.txt, या python setup.py install, और ट्रैविस-सीआई पर पाइप के साथ काम कर सकते हैं। संस्करण 18+, इसलिए मुझे लगता है कि इसमें बहुत सारे आधार शामिल हैं। मुझे आशा है कि यह किसी के लिए उपयोगी है, और अगर यह दूसरों के लिए ऑफ-विषय लगता है तो मेरी माफ़ी:

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

scipy>=0.17
matplotlib>=2.0
foo @ git+https://github.com/foo-organization/foo@dev#egg=foo-9999

आपकी setup.py फ़ाइल में:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

कुछ लोग कहेंगे कि install_requires और requirements.txt को मिलाना अनुचित है, और एक जारी संस्करण के लिए, मैं सहमत हूं, लेकिन मुझे लगता है कि यह विकास के लिए अच्छा काम करता है।

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

मैंने आज सुबह यह भी पढ़ा कि install_requires अपने आप में थोड़े खराब थे क्योंकि वे इंस्टालेशन सेटप्टूल द्वारा किए गए थे, जिसका अर्थ है कि किसी भी पाइप विकल्प को नजरअंदाज कर दिया गया था, लेकिन मुझे नहीं पता कि क्या वह जानकारी पुरानी है ...

मैंने आज सुबह यह भी पढ़ा कि install_requires अपने आप में थोड़े खराब थे क्योंकि वे इंस्टालेशन सेटप्टूल द्वारा किए गए थे, जिसका अर्थ है कि किसी भी पाइप विकल्प को नजरअंदाज कर दिया गया था, लेकिन मुझे नहीं पता कि क्या वह जानकारी पुरानी है ...

आप install_requires को setup_requires साथ भ्रमित कर रहे हैं।

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

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

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

@rgerkin हाय, मैं बिना किसी लाभ के आपके निर्देशों का पालन करने की कोशिश कर रहा हूं,

PACKAGE@ git+ ssh://[email protected] :OWNER/PACKAGE खोज रहे हैं। git@शाखा
पढ़ना https://pypi.org/simple/PACKAGE/
'पैकेज' के लिए अनुक्रमणिका पृष्ठ नहीं मिला (शायद गलत वर्तनी?)
सभी पैकेजों की स्कैनिंग इंडेक्स (इसमें कुछ समय लग सकता है)
पढ़ना https://pypi.org/simple/

पैकेज @ git+ ssh://[email protected] :स्वामी/पैकेज। git@शाखा , यह install_requires में है।

क्या आपको अंदाजा होगा कि मुझे उपरोक्त क्यों मिल रहा है?

@KevinMars मेरे उदाहरण और आपके पास जो कुछ है, उसके बीच कुछ अंतर हैं, जिसमें git_ssh, bitbucket, a.git प्रत्यय, एक नामित शाखा और कोई संस्करण टैग शामिल नहीं है। हो सकता है कि उनमें से एक या अधिक चीजें आपके यूआरएल के बजाय पीईपीआई पर खोज करने के लिए पीआईपी का नेतृत्व कर रही हों। आप पीआईपी का किस संस्करण का उपयोग कर रहे हैं?

कुछ है कि मैंने पाया टिप्पणी करने के लिए: का प्रयोग setup.py के साथ पैकेज स्थापित करने के लिए python setup.py install अभी भी में बाहरी निर्भरता की घोषणाओं की आवश्यकता है dependency_links ।

आपकी setup.py फ़ाइल में:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

@rgerkin इस समाधान को साझा करने के लिए धन्यवाद। लेकिन क्या होगा अगर मैं अपने पायथन पैकेज को सेटअप करने के लिए पीबीआर का उपयोग कर रहा हूं? पीबीआर फिट करने के लिए इसे कैसे अनुकूलित करें?

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

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