+1, मैक ओएस एक्स 10.7.3 और पायथन 2.7.1 के साथ पुष्टि की गई

परेशान करने की तरह, एक तय करने के लिए बहुत अच्छा होगा

हम नाम में रिक्त स्थान (# 278 देखें) के साथ एक virtualenv बनाने में सक्षम हैं, लेकिन बाद में easy_install और इस पर ठोकर खाते हैं:

% virtualenv "foo bar"
New python executable in foo bar/bin/python
Installing setuptools............done.
Installing pip...............done.
% ./foo\ bar/bin/easy_install nose
zsh: ./foo bar/bin/easy_install: bad interpreter: "/tmp/cfl/foo: no such file or directory
127 % ./foo\ bar/bin/pip install nose 
zsh: ./foo bar/bin/pip: bad interpreter: "/tmp/cfl/foo: no such file or directory

मैं यह भी पुष्टि करने के लिए यहां हूं कि यह ओएस एक्स (10.8 यहां) के साथ एक मुद्दा है। यदि आप बिन में VIRTUAL_ENV चर और शेलबैंग को संपादित करते हैं, तो आप इसे काम करने के लिए प्राप्त कर सकते हैं, लेकिन एक रास्ते में किसी भी स्थान पर एक ताजा एनवी चोक। जो OS X के लिए एक बड़ी समस्या है, यह देखते हुए कि बूट ड्राइव को आमतौर पर "Macintosh HD" नाम दिया गया है, इसलिए हर पथ "/ वॉल्यूम / Macintosh HD ..." से शुरू होता है

मैं जिस हैक का उपयोग कर रहा हूं वह इस प्रकार है।

बिन / सक्रिय:

VIRTUAL_ENV='/Volumes/Macintosh\ HD/path/to/my/project'

बिन / पाइप और बिन / easy_install:

#!"/Volumes/Macintosh\ HD/path/to/my/project/venv/bin/python"

पथ में अंतरिक्ष से बचने के बाद पिप काम कर रहा है।

इसे बंद क्यों किया गया? यह अभी भी बहुत मुद्दा है। मेरी गलती को संपादित करें , यह अभी भी खुला है

यह समस्या अभी भी खुलती है।

मैं इसे अपने घर निर्देशिका से एक प्रतीकात्मक लिंक बनाने के चारों ओर प्राप्त करने में सक्षम था, जिसे मैं काम करना चाहता था (जिसमें अन्यथा इसमें एक स्थान था)।

मैं यह भी देख रहा हूँ क्योंकि मैक। मैं इसे लिपियों में मैन्युअल रूप से शेबंग लाइन को संपादित करके प्राप्त करता हूं! # / Usr / bin / env python और सभी काम करता है। हालांकि, जैसा कि दूसरों ने उल्लेख किया है, यह प्रत्येक नए एनवी और एनवी में स्थापित किसी भी अतिरिक्त स्क्रिप्ट के साथ किया जाना है।
लगता है कि यह कोड में एक आसान फिक्स होना चाहिए ताकि स्पेस से बच सकें या उपयोग करें / usr / bin / env यदि is_darwin है। हालाँकि जब से मैं इस पर बहुत ज्यादा शोर कर रहा हूं मैं गलत हो सकता हूं।

यह सिर्फ मैक के लिए नहीं है, यह मूल रूप से * nix सिस्टम के विनिर्देशन / व्यवहार का हिस्सा है।

आपके पास शेलबैंग लाइन के पहले तर्क में स्थान नहीं हो सकते हैं (वे इसके बजाय अलग-अलग तर्कों में बदल जाएंगे), और आम तौर पर या तो भागने / उद्धृत करने की अनुमति नहीं है।

http://lists.gnu.org/archive/html/bug-bash/2008-05/msg00053.html

मुझे पता है, मैं एनाकोंडा के साथ इस समस्या में भाग गया। मैक के साथ टी की सिर्फ स्थानिकता है क्योंकि ड्राइव नाम में व्हाट्सएप है।

ऐसा लगता है कि यह # 611 द्वारा सही किया जाएगा। क्या उस पुल अनुरोध की प्रभावकारिता की कोई समीक्षा की गई है?

इसलिए कष्टप्रद, को ठीक करना चाहिए।

लिंक @Ivoz पोस्ट देखें, यह एक यूनिक्स सीमा है। # 611 कुछ यूनिक्स वेरिएंट के लिए काम कर सकता है, अगर वे बैकबॉश का समर्थन एक शबंग रेखा में करते हैं, लेकिन यह स्पष्ट नहीं है कि कौन से संस्करण करते हैं (और कोड सिर्फ नेत्रहीन रूप से जाँच किए बिना करता है - जो कि समस्या को _vorse_ नहीं बनाएगा, लेकिन जीता ' टी मदद या तो अगर यह समर्थित नहीं है ...)

यह वास्तव में सच है कि यह उस तरीके का एक परिणाम है जो यूनिक्स शेबंग लाइनों को संभालता है, लेकिन अगर # 611 कुछ सिस्टम के लिए समस्या को ठीक करता है और दूसरों के लिए समस्या को बदतर नहीं करता है, तो क्या यह अभी भी सुधार होगा?

अगर यह सच है तो हाँ। लेकिन मैं # 611 पर टिप्पणी नहीं कर सकता क्योंकि मैं यूनिक्स डेवलपर नहीं हूं। ऐसे मामले हो सकते हैं जहां यह चीजों को बदतर बनाता है, मुझे अभी पता नहीं है। क्षमा करें, मैं और अधिक मदद नहीं कर सकता।

काफी उचित। # 611 को शायद अधिक ध्यान से देखने की जरूरत है और फ्रिंज मामलों के लिए परीक्षण किया गया है।

इससे भी बदतर: खिड़कियों पर यह एक ही त्रुटि के साथ डिफ़ॉल्ट जेनकींस पथ पर टूट जाता है:
FATAL: Python दुभाषिया के रास्ते में व्हॉट्सएप की अनुमति नहीं है: C: \ Program Files (x86) \ Jenkins \ shiningpanda \ jobs \ c3418983virtualenvs \ d41808cd9

मैं सिर्फ इस मुद्दे से प्रभावित था। स्टैकऑवरफ़्लो पर मुझे मिले निर्देशों के बाद, मैंने पहली पंक्ति को #!/usr/bin/env python सेट करके pip कार्य करने में कामयाबी हासिल की

मुझे यकीन नहीं है, हालांकि, अगर वह समाधान सभी मामलों के लिए काम करता है ... मेरा मतलब है, मुझे यकीन नहीं है कि पायथन को निष्पादित किया जाएगा

इंस्टॉल की गई स्क्रिप्ट्स के शेबबेंज को "env python" में बदलने का मतलब है कि वे केवल एक सक्रिय वर्चुअन में काम करेंगे। लिपियों को स्पष्ट निरपेक्ष रास्तों के साथ उत्पन्न किया गया था ताकि वे हमेशा वेव में पायथन का उपयोग करें, और इस प्रकार स्क्रिप्ट द्वारा स्थापित पैकेजों को ढूंढें।

मेरा सुझाव यह होगा कि कोई व्यक्ति (संभवत: इस मुद्दे से प्रभावित कोई व्यक्ति हो, लेकिन कम से कम एक मंच पर कोई ऐसा व्यक्ति जिसके पास समस्या है और इसे हल करने का एक तरीका भी है) एक चेक अनुरोध लागू करें:

• यदि हमारे पास पथनाम में रिक्त स्थान है,
• और हम मंच पर हैं XXX,
• फिर रिक्त स्थान को संभालने के लिए निम्नलिखित भागने के साथ Shebang लाइन लिखें।
• अन्य सभी मामलों में, वर्तमान व्यवहार पर वापस आते हैं।

इसके बाद अतिरिक्त जोड़ केवल अतिरिक्त प्लेटफ़ॉर्म चेक जोड़कर इच्छुक पार्टियों द्वारा किए जा सकते हैं।

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

1. यहाँ चर्चा से पता चलता है कि दोहरे भाव OSX पर काम करते हैं, लेकिन क्या यह सटीक OSX संस्करण पर निर्भर करता है?
2. # 611 में बैकस्लैश के साथ बचने वाले स्थानों का उपयोग किया गया था, लेकिन इस बात की कोई पुष्टि नहीं थी कि यह किस ओएस के लिए था (लिनक्स? एक विशिष्ट कर्नेल संस्करण? एक विशिष्ट डिस्ट्रो?)

ध्यान दें कि ऐसा कोई भी प्लेटफ़ॉर्म-विशिष्ट संस्करण /usr/bin/env उपयोग नहीं करना चाहिए। जैसा कि @merwok ने बताया है, कि व्यवहार में परिवर्तन होता है - स्क्रिप्ट को _without_ पर्यावरण को सक्रिय करने की अनुमति देने के लिए जानबूझकर लिखा जाता है।

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

@pfmoore जैसा कि मैंने उल्लेख किया है, मैं हाल ही में इस मुद्दे से प्रभावित था और मैं लिनक्स मिंट 18 चला रहा हूं। मैंने

https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00052.html के अनुसार, बैकस्लैश या उद्धरण के साथ भागने से काम नहीं चलेगा

प्रयोगात्मक रूप से, मैं सत्यापित कर सकता हूं कि बैकस्लैश या उद्धरण के साथ बचना OSX 10.11.6 के साथ काम नहीं करता है।

वर्चुअन को कर्नेल-निर्भर शेबंग से दूर रहना चाहिए। मैंने Linux, XNU (macOS का कर्नेल), FreeBSD, OpenBSD और NetBSD स्रोत कोड की जाँच की है। उनमें से कोई भी शबंग में रिक्त स्थान नहीं संभाल सकता है।

ठीक करने से पहले, रिक्त स्थान का उपयोग न करें।

मैं एक पैच प्रस्तुत करता हूं जो पायथन 3 के नए वेनव के लिए एक चेतावनी जोड़ता है, जो वर्चुअनव के समान है, लेकिन @vsajip : http://bugs.python.org/issue28446 द्वारा अस्वीकार कर दिया गया है

अतिरिक्त डेटा बिंदु के रूप में, विंडोज पर व्यवहार पर ध्यान दें, जो उम्मीद के मुताबिक लगता है:

`` `C: \ Users \ Vinay> \ python34 \ python -m venv" \ Temp \ aaa bbb "

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" --version
सी से 6.0.8 पाइप: \ Temp \ aaa bbb \ lib \ साइट-संकुल (अजगर 3.4)

C: \ Users \ Vinay> pyzzer -i "\ Temp \ aaa bbb \ Scriptspp.exe"
एक लांचर है।
शेबंग: #! "C: \ Temp \ aaa bbb \ Scripts \ python.exe"

पुरालेख सामग्री:
__main__.py

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scripts \ python" -m pip install -U pip
आप पाइप संस्करण 6.0.8 का उपयोग कर रहे हैं, हालांकि संस्करण 9.0.1 उपलब्ध है।
आपको 'पाइप इंस्टॉल - अपग्रेड पाइप' कमांड के माध्यम से अपग्रेड करने पर विचार करना चाहिए।
Https://pypi.python.org/ [...] / पाइप-9.0.1-py2.py3-none-any.whl # md5 = 297 [...] से पाइप एकत्रित करना
कैश्ड पाइप-9.0.1-py2.py3-none-any.whl का उपयोग करना
एकत्रित पैकेजों को स्थापित करना: पाइप
मौजूदा स्थापना मिली: 6.0.8 पाइप
अनइंस्टॉलिंग पाइप-6.0.8:
पाइप-6.0.8 की सफलतापूर्वक स्थापना रद्द की गई

सफलतापूर्वक स्थापित पाइप-9.0.1

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" --version
सी। से 9.0.1 पाइप: \ Temp \ aaa bbb \ lib \ साइट-संकुल (अजगर 3.4)
`` `

Windows पर yep virtualenv स्क्रिप्ट, डिस्टलिब के रूप में पीसी / लॉन्चर। हो सकता है कि POSIX में कुछ समान हो सकता है - अविश्वसनीय कर्नेल के बजाय एक उपयोगकर्ता स्थान शेलबंग पार्सर।

एक उपयोगकर्ता अंतरिक्ष अप्रतिबंधित गुठली के बजाय परबंग पार्सर

मुझे यकीन नहीं है कि बैश ऐसा क्यों नहीं कर सकता (उदाहरण के लिए) - मुझे नहीं लगता कि यह एक कर्नेल-स्पेस चीज़ है।

शेबंग को कर्नेल स्पेस में संभाला जाता है क्योंकि यह शेल के बाहर प्रयोग करने योग्य होना चाहिए।

तकनीकी जानकारी:
UNIX- जैसी प्रणालियों (लिनक्स, मैक, * बीएसडी, ...) पर, एक नया कार्यक्रम कांटा () और निष्पादन () के माध्यम से बनाया गया है। निष्पादन () विंडोज पर CreateProcess () के समान है, जो एक नया प्रोग्राम चलाता है। UNIX जैसी प्रणालियों पर, निष्पादन () अंततः सिस्टम कॉल निष्पादित () कहता है। उत्तरार्द्ध फ़ंक्शन को गुठली में लागू किया जाता है, इसलिए किन्नर पार्सिंग को गुठली में किया जाता है।
इसे सी लाइब्रेरी में लागू नहीं किया जा सकता है, या तो, या स्टैटिक लिंक्ड प्रोग्राम या प्रोग्राम जो सीधे सिस्टम कॉल का उपयोग करता है (int 80 या sysenter, आदि के माध्यम से) काम नहीं करेगा।

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

शेबंग को कर्नेल स्पेस में संभाला जाता है क्योंकि यह शेल के बाहर प्रयोग करने योग्य होना चाहिए

हां, लेकिन यदि सिस्टम कॉल ENOEXEC लौटाता है, तो कोई शेल स्वयं पार्स नहीं कर सकता है? मुझे लगता है यह कीड़े का एक हो सकता है ...

दिलचस्प tidbit - लिनक्स पर कर्नेल की कार्यक्षमता लंबे समय से पाइथन कॉमिटर मार्टिन वॉन लॉनव्यू :-)

यह पृष्ठ भी एक दिलचस्प पढ़ा गया था: http://www.in-ulm.de/~mascheck/various/shebang/

हां, लेकिन यदि सिस्टम कॉल ENOEXEC लौटाता है, तो कोई शेल स्वयं पार्स नहीं कर सकता है?

IMO गोले और अंतर्निहित कर्नेल के बीच अलग-अलग शब्दार्थों के साथ-साथ डेवलपर्स के लिए बहुत भ्रम लाएगा। वर्तमान में कम से कम बैश और zsh निष्पादित करते हैं (जब) ​​विफल हो जाता है, लेकिन केवल बेहतर त्रुटि रिपोर्टिंग के लिए, एक वापसी नहीं प्रदान करता है।

दिलचस्प tidbit - लिनक्स पर कर्नेल की कार्यक्षमता लंबे समय तक पायथन कॉमिटर मार्टिन वॉन लॉनव्यू :-) द्वारा लिखी गई प्रतीत होती है

दिलचस्प है! मैंने ध्यान नहीं दिया कि :) अतिरिक्त सामग्री के लिए भी धन्यवाद। जबकि कर्नेल स्रोत कोड पढ़ना सबसे तेज़ तरीका है, ऐसे दस्तावेज़ अभी भी सहायक हैं।

@Fbidu के विचार के बारे में:

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

नाजुक पथ के साथ आभासी वातावरण बनाना पथ हैंडलिंग में कोने के मामलों के परीक्षण के लिए उपयोगी है। इस उदाहरण में यह दर्शाता है कि गुठली कैसे टूटी है। मेरे विचार में मना करने के बजाय चेतावनी जोड़ना है, जैसे पैच मैंने http://bugs.python.org/issue28446 पर पोस्ट किया है

मुझे लगता है कि # 994 "वर्चुअनवैल रास्ते में अंतरिक्ष के साथ पिप विफल रहता है" इस मुद्दे का एक डुप्लिकेट है।

मैं https://github.com/pypa/virtualenv/issues/997#issuecomment -270681253 से टिप्पणी दोहराना चाहता हूं, "virtualenv नाजुक कर्नेल शेबंग पार्सिंग के साथ टूट गया है।" और उस भावना में, # 1014 "अपने पथ में इमोजी होने वाली निर्देशिका के साथ संगत नहीं है" वर्चुअलबेनव का एक और उदाहरण नाजुक कर्नेल शेबंग पार्सिंग द्वारा तोड़ा जा रहा है। मुझे यकीन है कि समस्या पथ में किसी भी गैर- ASCII वर्ण के साथ होती है, वास्तव में।

हो सकता है कि हम एक समस्या में नाजुक कर्नेल शेबिंग पार्सिंग के सभी तीन पहलुओं को इकट्ठा करें, ताकि हम यह सुनिश्चित कर सकें कि एक फिक्स virtualenv पथ में रिक्त स्थान, लंबाई और गैर- ASCII वर्णों को संबोधित कर सकता है? मैं इस मुद्दे को नामांकित करता हूं, क्योंकि यह सबसे पुराना है।

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

मुझे यकीन है कि समस्या पथ में किसी भी गैर- ASCII वर्ण के साथ होती है, वास्तव में।

मेरा मानना ​​है कि # 1014 का कारण कर्नेल के बजाय वर्चुअनव में है। मेरे पास एक पैच है जो # 900 पर काफी समान समस्या को ठीक करता है।

नमस्ते,
यह सुपर कष्टप्रद है और समय की इतनी बड़ी बर्बादी किसी चीज के कारण इतनी सरल (कम से कम सरल कारण) प्रतीत होती है।

नाम बदलने के बारे में कैसे (जब संभव हो), या लिंक का उपयोग कर (अंतरिक्ष के बिना /virtualenvs/python3.5 जैसी निर्देशिका बनाना, तो यह मूल निर्देशिका के लिए एक नरम लिंक हो सकता है?)

अंतरिक्ष के बिना /virtualenvs/python3.5 जैसी निर्देशिका बनाना

एक अन्य प्रोजेक्ट virtualenvwrapper ने कुछ ऐसा ही किया है।

कुछ प्रतीत होता है इतना सरल (कम से कम सरल कारण)।

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

यह 6 साल बाद भी एक मुद्दा है?

इस मुद्दे ने मुझे 2 सप्ताह पहले उलझा दिया। हां, यह अभी भी एक मुद्दा है।

ध्यान दें कि जैसा कि यह एक यूनिक्स मुद्दे के बजाय एक यूनिक्स मुद्दा है, यह संभावना नहीं है कि यह "निश्चित" हो जाएगा जब तक कि यूनिक्स कर्नेल सीमा को हटा नहीं दिया जाता है ...

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

@JDLH आपके पहले "बग" के बारे में: यह virtualenv द्वारा नहीं बल्कि डिस्टलिब द्वारा नियंत्रित किया जाता है, और https://bitbucket.org/pypa/distlib/pull-requests/31/ पर एक कार्यान्वयन है

पहला वर्चुअनव बग यह है कि वर्चुअनव ने एक निश्चित यूनिक्स कर्नेल सुविधा का उपयोग करके शेल-निष्पादन योग्य फ़ाइलों को लागू करने के लिए चुना है

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

बहुत कुछ है कि virtualenv योगदानकर्ता स्थिति को सुधारने के लिए कर सकते हैं।

योगदानकर्ताओं के समय पर संभवतः कई कॉल हैं। यह समस्या उन मामलों की अपेक्षाकृत कम संख्या को प्रभावित करती है जहां रिक्त स्थान के साथ लंबे पथ / रास्तों का उपयोग किया जाता है। शायद उन उपयोगकर्ताओं में से कुछ जो प्रभावित हैं वे योगदानकर्ताओं को एक पैच का प्रस्ताव देकर उनकी मदद करने में मदद कर सकते हैं जो पता लगाने और चेतावनी संदेशों के साथ मदद करेंगे? एक विचार है।

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

यह virtualenv के लिए विशिष्ट नहीं है

@vsajip यह एक सत्य कथन है - अन्य सॉफ़्टवेयर उसी शेलबैंग तंत्र का उपयोग करता है जिसे virtualenv ने चुना है - लेकिन यह इस मुद्दे की बात को याद करता है। Virtualenv द्वारा प्रदान किए गए मूल्य के बारे में कुछ भी नहीं है जो मांग करता है कि वह शेबंग का उपयोग करे। वर्चुअनव एक अलग तंत्र का उपयोग कर सकता है, लेकिन इसने शबंग को चुना, और इस प्रकार वर्चुअन वास्तव में शबंग की सीमा को प्राप्त करता है।

वर्चुअलाइजेशन (या कुछ और) के लिए कोई आकर्षक कारण नहीं है कि डिस्पैचिंग स्क्रिप्ट की पूरी तरह से नई पद्धति को फिर से स्थापित किया जाए

मुझे लगता है कि आप जो कह रहे हैं वह यह है कि वर्षों से जिन लोगों ने इस मुद्दे का सामना किया है, वे "सम्मोहक" नहीं हैं। मुझे लगता है कि ऐसा क्यों है कि इतने सारे लोग इस मुद्दे पर वर्षों से ढूंढते हैं और टिप्पणी करते हैं कि वे समस्याओं को "सम्मोहक" पाते हैं। मैं निश्चित रूप से कर दूंगा।

शायद उन उपयोगकर्ताओं में से कुछ जो प्रभावित हैं वे योगदानकर्ताओं को एक पैच का प्रस्ताव देकर उनकी मदद करने में मदद कर सकते हैं जो पता लगाने और चेतावनी संदेशों के साथ मदद करेंगे? एक विचार है।

मैंने "योगदानकर्ता" शब्द चुना, जिसमें दोनों स्टालवार्ट शामिल हैं जो virtualenv पर अधिकांश काम करते हैं, और मेरे जैसे आगंतुक जो इस समस्या को कम करने के लिए मजबूर करते हैं, जो इसके प्रभाव को कम करने के लिए पर्याप्त काम करते हैं। यह कहना उचित है कि हम जो समस्या को हल करते हैं, उसे एक पैच योगदान देना चाहिए।

यह उपयोगी होगा यदि स्टेलवर्ट्स जो वर्चुअलेनव को अच्छी तरह से जानते हैं, आशाजनक दृष्टिकोण सुझा सकते हैं। अगर मैं virtualenv ~/my\ long\ path\ with\ spaces टाइप करने वाले उपयोगकर्ता के लिए एक चेतावनी संदेश सम्मिलित करना चाहता था, तो उस कोड को सबसे अच्छा कहाँ रहना चाहिए? क्या इस तरह के पैच पर गैर-स्पष्ट बाधाएं हैं, जो कि स्टालवार्ट्स साझा कर सकते हैं, अपने पहले योगदान पर काम कर रहे आगंतुक से एक बाधा को दूर करने के लिए? क्या आढ़तियों को इस तरह के पचड़े को स्वीकार करने में कुछ ऐतिहासिक आपत्ति है? (मेरा मतलब है, मैं पहला व्यक्ति नहीं हो सकता, जिसने एक चेतावनी संदेश जोड़ने के बारे में सोचा था। एक कारण होना चाहिए कि यह अभी तक नहीं हुआ है।)

एक प्रसिद्ध मार्ग है जिसमें रिक्त स्थान होते हैं और उन्हें संशोधित नहीं किया जा सकता है: /Users/iulian/Library/Mobile Documents/com~apple~CloudDocs । तो जो भी कुछ स्क्रिप्ट रखना चाहता है, वह इस समस्या में iCloud धक्कों में virtualenv साथ प्रबंधित होता है।

यह उपयोगी होगा यदि स्टेलवर्ट्स जो वर्चुअलेनव को अच्छी तरह से जानते हैं, आशाजनक दृष्टिकोण सुझा सकते हैं।

ठीक है, अगर हम किसी को जानते थे, तो शायद हम इस मुद्दे को इतने लंबे समय तक अनसुलझे नहीं छोड़ेंगे, हमें ऐसा करने के लिए जितनी आलोचना मिल रही है, उसे देखते हुए :-(

अगर मैं virtualenv ~ / my \ long \ path \ with \ space टाइप करने वाले उपयोगकर्ता के लिए एक चेतावनी संदेश सम्मिलित करना चाहता था, तो उस कोड को कहाँ रहना चाहिए?

आप मार्ग को निर्धारित करने के बाद, चेक पार्सिंग कोड को देखकर शुरू कर सकते हैं।

क्या इस तरह के पैच पर गैर-स्पष्ट बाधाएं हैं, जो कि स्टालवार्ट्स साझा कर सकते हैं, अपने पहले योगदान पर काम कर रहे आगंतुक से एक बाधा को दूर करने के लिए?

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

क्या आढ़तियों को इस तरह के पचड़े को स्वीकार करने में कुछ ऐतिहासिक आपत्ति है?

नहीं, इसके अलावा, "यह मत मानो कि यह उतना ही सरल है जितना आप पहली नज़र में सोचते हैं, और सभी विभिन्न (कभी-कभी बहुत अस्पष्ट) सिस्टम को अनदेखा नहीं करते हैं, जिसका हमें समर्थन करना है"।

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

तब आपको अपने पैच की समीक्षाओं को उन लोगों से प्राप्त करने की आवश्यकता होगी जो आपके द्वारा कवर किए गए सिस्टम तक पहुँच के साथ हैं - जैसा कि उल्लेख किया गया है, कोर देवता वास्तव में यहाँ मदद नहीं कर सकते क्योंकि हम में से कोई भी उपयोग नहीं करता है (उदाहरण के लिए) FreeBSD, या OpenBSD, या Solaris, या ...

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

क्या उससे मदद हुई?

शायद मुझे कुछ समझ में नहीं आता है, लेकिन (उदाहरण के लिए) bin/pip होने से इस समस्या को हल नहीं किया जा सकता है

#!/bin/sh
"/my/long path/with spaces/pythonx.y" "/path/to/my project/with spaces/venv/bin/real-pip" "$@"

और फिर वर्तमान pip स्क्रिप्ट को real-pip स्थानांतरित करना? मैं यह नहीं देखता कि हमें सीधे शेबंग का उपयोग क्यों करना है।

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

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

@pfmoore
@ raxod502 द्वारा प्रस्तावित समाधान भी .bat स्क्रिप्ट फ़ाइल, afaik के साथ खिड़कियों पर काम कर सकता है?

@ उत्तर छोटा उत्तर, नहीं। दीर्घ उत्तर http://paul-moores-notes.readthedocs.io/en/latest/wrappers.html पर है। पिछले कुछ वर्षों में इस बिंदु पर कई चर्चाएं हुई हैं, और हर बार जब कोई व्यक्ति समाधान के अलावा आया है exe आवरण, यह समस्या थी।

इस मामले में, कृपया याद रखें कि यह समस्या विंडोज पर मौजूद नहीं है । इसलिए विंडोज वातावरण में कुछ भी बदलने का कोई कारण नहीं है - कोई भी परिवर्तन केवल यूनिक्स तक सीमित होना चाहिए।

अच्छे उत्तर के लिए thx :)

एक exe आवरण के अलावा, यह समस्या थी।

व्यक्तिगत रूप से मैं उसके साथ रह सकता हूं (यदि मुझे था)।

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

पाइप का विकास संस्करण अब डिस्टलिब के इस नए संस्करण को विक्रेता करता है, जिसका अर्थ है कि पाइप अब निर्देशिका नामों में रिक्त स्थान को ठीक से संभालता है।

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

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

रास्तों में कोई जगह नहीं है, लेकिन बहुत सी अन्य चीजों को अपने घुटनों पर चलाने के लिए वर्चुअनव / पाइप आदि लाने की कोशिश की जाती है जैसे

/run/user/1000/gvfs/smb-share:server=bolt,share=eng/projects/msp/mrfbus/land

जहाँ तक मैं देख सकता हूँ कि gvfs में वर्तमान में कोई विकल्प नहीं है कि इससे उत्पन्न माउंट पॉइंट्स के पथों में विचलन को रोका जा सके। मेरा एकमात्र काम यह है कि एक gvfs माउंट पर virtualenv कभी न बनाएं, जो थोड़ा दुखद लगता है

@pradyunsg क्या अगली पाइप रिलीज़ के लिए कोई समयरेखा है? पिछले एक साल पहले खत्म हो गया था , और यह थोड़े गूंगा लगता है कि यह वास्तव में वर्चुअन में दिखाने के लिए बहुत आसान है।

हाय @ raxod502!

हाँ, हम इसे जल्द से जल्द निकालना चाहते हैं। बात यह है कि हम पीईपी 518 को दरवाजे से बाहर करने के लिए डेवलपर समय पर कम हैं, जो कि हम करना चाहते हैं। यह सिर्फ ऐसा हो सकता है कि पीईपी 518 के बिना एक पाइप 10 है लेकिन फिर से, यह उस योजना को प्राप्त करने के लिए समय खोजने पर निर्भर करता है।

ऐसा प्रतीत होता है कि यह बग पाइप 10.0.0 द्वारा तय किया गया है, 2018-04-14 को जारी किया गया है। कड़ाई से ठीक बोल में था distlib 0.2.6 , जो उनके साथ पिप में vendored था PR4819 अक्टू 2017 में, जो पहले पिप 10.0.0b2 में दिखाई दिया।

अंतर्निहित सुधार डिस्टलिब की प्रतिबद्ध 9285cca में प्रतीत होता है। जैसा कि 28 मई, 2017 को vsajip ने यहां टिप्पणी की , यह दृष्टिकोण हैराल्ड नॉर्डग्रेन के विचार का अनुसरण करता है: सरल मामलों के लिए एक साधारण शेलबैंग का उपयोग करते रहें (ओएस पॉज़िक्स नहीं है, या पथ काफी छोटा है और कोई स्थान नहीं है), लेकिन गैर-सरल मामलों के लिए उपयोग करें इसके बजाय एक /bin/sh exec कमांड, जो लंबे या अंतरिक्ष युक्त रास्तों को संभाल सकता है।

मैंने मैक ओएस एक्स 10.11.6 पर एक त्वरित परीक्षण किया, जिसमें रिक्त स्थान के साथ एक लंबे रास्ते में एक आभासी एनवी बना, फिर pip3 install आह्वान किया, और यह काम करने लगता है। मैंने पूरी तरह से परीक्षण नहीं किया है कि इस बग में वर्णित सब कुछ हर ओएस पर तय किया गया है।

9.0.1 से 18.1 तक पाइप को अपग्रेड करने के बाद (उन्होंने कैलेंडर आधारित संस्करण पर स्विच किया) और 15.0.1 से 16.0.0 तक Ubuntuen 16.04.5 LTS का उपयोग करके समस्या दूर हो गई लगती है:

sudo pip install --upgrade pip
sudo pip install --upgrade virtualenv

अब सभी pip आदेश अपने रूट पथ में रिक्त स्थान वाले virtualenvs में ठीक से काम करते हैं।

जैसा कि @JLDH और @gandie द्वारा पुष्टि की गई है, यह मुद्दा अब हल हो गया है; जब एक virtualenv की जड़ में रिक्त स्थान है पाइप और virtualenv के नवीनतम संस्करणों के साथ ठीक से काम कर रहा है।

इसे बंद करना! अंतर्निहित फिक्स @vsajip पर काम के लिए धन्यवाद!

पुराना टिकट: लेकिन क्यों नहीं

/ usr / bin / env अजगर

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