Virtualenv: पाइप निष्पादन योग्य में शेबांग की लंबाई पार हो गई है

मैं भी इस मुद्दे का अनुभव कर रहा हूं।

मैं भी।

उपाय के लिए धन्यवाद!

ध्यान दें कि रैपर स्क्रिप्ट वास्तव में setuptools (यदि आप sdist से इंस्टॉल करते हैं) या distlib (यदि आप व्हील से इंस्टॉल करते हैं) द्वारा जेनरेट की जाती हैं। तो इस मुद्दे के लिए कोई भी समाधान वास्तव में उन परियोजनाओं से अनुरोध किया जाना चाहिए।

लेकिन अगर यह एक ओएस सीमा है, तो शायद एक व्यवहार्य फिक्स _is't_ नहीं है? मुझे याद है कि एक समय में, पर्ल ने स्क्रिप्ट निष्पादित करने के लिए एक जादू मंत्र का इस्तेमाल किया था (थोड़ा सा गुगल्स ...) हां, ऐसा कुछ (पायथन के लिए अनुवादित)

#!/bin/sh
eval 'exec /the/long/interpreter/path/to/python $0 ${1+"$@"}'

आपको कुछ अतिरिक्त सामान की आवश्यकता होगी ताकि पायथन ने eval-exec लाइन को निष्पादित करने का प्रयास न किया हो, लेकिन यह काम कर सकता है।

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

तो, जब पथ, जहां एक पायथन वर्चुअलएन्व बनाया जाता है, बहुत लंबा हो जाता है, उस वर्चुअलएन्व के पाइप का उपयोग करने से काम नहीं चलेगा।

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

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

मुझे @ बी-लॉन्ग का सुझाव पसंद है; अगर virtualenv एक ऐसा रैपर बनाने जा रहा है जो मौजूदा सिस्टम पर काम नहीं करता है, तो उसे कम से कम उपयोगकर्ता को चेतावनी देनी चाहिए, अगर फ्लैट-आउट विफल नहीं होता है।

यह स्पष्ट नहीं है कि कैसे virtualenv इस स्थिति का पता लगा सकता है। हम वास्तव में सी हेडर से एक मूल्य का उपयोग नहीं कर सकते हैं, और मुझे नहीं पता कि हम कैसे पता लगाएंगे कि हम इस सीमा के साथ एक सिस्टम पर हैं (विंडोज में यह नहीं है, ओएसएक्स करता है?)

मैं इस मुद्दे को ओएस सीमा के रूप में बंद करने के इच्छुक हूं, वर्चुअलएन्व समस्या नहीं।

इसके लायक क्या है, कुछ विचार ...

1. क्या ctypes ऐसा कर सकता है?
2. कैसे कुछ के रूप में सरल के बारे में:

# on Linux, BINPRM_BUF_SIZE == 128, giving us a maximum shebang length of 127
# 2 bytes for #!, 11 bytes for '/bin/python' leaves us with 114
if sys.platform() == 'Linux' and len(home_dir) > 114:
    log.warn("bin/activate may not work your system, as the length of the shebang line will exceed 128 characters")

1. कोई विचार नहीं, क्षमा करें।
2. मैं एक विंडोज़ उपयोगकर्ता हूं इसलिए मेरी कोई राय नहीं है। यदि आपको लगता है कि यह उचित है, तो मेरा सुझाव है कि एक पीआर बढ़ाएं और देखें कि लिनक्स के लोग क्या सोचते हैं ...

मुझे यकीन है कि अन्य उपयोगकर्ता भी मेरे द्वारा सुझाए गए बदलाव की सराहना करेंगे। क्या हम इसे टिप्पणी के लिए खुला छोड़ सकते हैं और एक पीआर को प्रेरित कर सकते हैं? धन्यवाद @jantman और @pfmoore : मुस्कान:

BINPRM_BUF_SIZE को कर्नेल हेडर में परिभाषित किया गया है, और ऐसा लगता है कि केवल कुछ मुट्ठी भर कर्नेल फ़ंक्शंस द्वारा उपयोग किया जाता है। मुझे विश्वास नहीं है कि प्रोग्रामेटिक रूप से इसका पता लगाने का कोई तरीका है (हेडर में पढ़ने की कमी, जो कहीं भी संभव नहीं है)।

ऐसा कहा जा रहा है, मुझे लगता है कि यह मानना ​​​​उचित है कि यह जल्द ही किसी भी समय नहीं बदलेगा ( यहां अधिकतम शेबैंग लंबाई का त्वरित अवलोकन execve(2) मैन पेज के "नोट्स" खंड में दी

मुझे लगता है कि सभी पॉज़िक्स-संगत ऑपरेटिंग सिस्टम में किसी प्रकार की सीमा होती है, हालांकि ऐसा लगता है कि उनमें से कुछ, विशेष रूप से बीएसडी वेरिएंट में 8,000 वर्णों की सीमा हो सकती है।

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

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

मेरे पास यह जांचने के लिए कुछ सरल प्रूफ-ऑफ-कॉन्सेप्ट कोड है कि दिया गया पथ एक स्वीकार्य शी-बैंग लंबाई है या नहीं, लेकिन यह बदसूरत है क्योंकि यह डिस्क पर एक फ़ाइल लिखता है और फिर आउटपुट को कैप्चर करने के लिए फ़ाइल को निष्पादित करता है। उदाहरण और आउटपुट यहाँ है: https://gist.github.com/jantman/ba39f98936643bc948bd

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

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

दोहराना:

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

इस मुद्दे को बंद करना, क्योंकि यह वर्चुअलएन्व समस्या नहीं है (आप एक पूर्ण पायथन दुभाषिया को एक लंबी निर्देशिका नाम पर स्थापित करके समान प्रभाव प्राप्त कर सकते हैं) ..

हमने अभी इस मुद्दे को मारा है।

पथ से अजगर का उपयोग क्यों नहीं करें? वर्चुअलएन्व पहले से ही इसे बिन डीआईआर के साथ तैयार करता है।

#!/usr/bin/env python

वर्चुअलएन्व पहले से ही इसे बिन डीआईआर के साथ तैयार करता है

केवल अगर आप वर्चुअलएन्व को सक्रिय करते हैं। Virtualenv सक्रियण के बिना उपयोग किए जाने का समर्थन करता है।

अगर किसी को यह भ्रमित लगता है:

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

इसका मतलब है कि pip install -r requirements.txt बजाय python -m pip install -r requirements.txt