Virtualenv: उपप्रक्रिया के तहत गलत शेबैंग के साथ स्थापित स्क्रिप्ट

करता है

$ env/bin/pip uninstall pytest
$ env/bin/pip install pytest
$ head -n 1 env/bin/py.test

समान, या अलग परिणाम दें?

और इसी सवाल के साथ

$ env/bin/python -m pip install pytest

?

पर संभवतः एक प्रतिगमन किसी भी तरह https://github.com/pypa/virtualenv/issues/322 / https://github.com/pypa/virtualenv/pull/541

किस मामले में, क्या आप परीक्षण कर सकते हैं कि क्या

subprocess.Popen(sys.argv[1:], env={}).wait()

मदद करता है या नहीं?

हम्म, शायद इससे निपटने के लिए पाइप/डिस्टलिब में कोड था, लेकिन एक साल पहले इस पर टिप्पणी की गई थी-

https://github.com/pypa/pip/blob/7cea748d0fb2e8980c2676304607426585550b41/pip/_vendor/distlib/util.py#L157 -L165

समान, या अलग परिणाम दें?

दोनों ही मामलों में, pip को सीधे लागू करने से एक उचित शेबंग होता है:

$ env/bin/pip install pytest
Collecting pytest
  Using cached pytest-2.8.5-py2.py3-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): py>=1.4.29 in ./env/lib/python3.5/site-packages (from pytest)
Installing collected packages: pytest
Successfully installed pytest-2.8.5
$ head -n 1 env/bin/py.test
#!/Users/jaraco/Dropbox/code/public/aspen/env/bin/python3
$ env/bin/pip uninstall -y pytest
Uninstalling pytest-2.8.5:
  Successfully uninstalled pytest-2.8.5
$ env/bin/python -m pip install pytest
Collecting pytest
  Using cached pytest-2.8.5-py2.py3-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): py>=1.4.29 in ./env/lib/python3.5/site-packages (from pytest)
Installing collected packages: pytest
Successfully installed pytest-2.8.5
$ head -n 1 env/bin/py.test
#!/Users/jaraco/Dropbox/code/public/aspen/env/bin/python

साथ ही, एक खाली एनवी कार्यों के साथ आह्वान करना:

$ cat invoke.py 
import sys
import os
import subprocess

env = dict(os.environ)
env.pop('__PYVENV_LAUNCHER__')
env = {}

subprocess.Popen(sys.argv[1:], env=env).wait()
$ python -m virtualenv env
Using base prefix '/Library/Frameworks/Python.framework/Versions/3.5'
New python executable in /Users/jaraco/Dropbox/code/public/aspen/env/bin/python3
Also creating executable in /Users/jaraco/Dropbox/code/public/aspen/env/bin/python
Installing setuptools, pip, wheel...done.
$ python invoke.py env/bin/pip install pytest
Collecting pytest
  Using cached pytest-2.8.5-py2.py3-none-any.whl
Collecting py>=1.4.29 (from pytest)
  Using cached py-1.4.31-py2.py3-none-any.whl
Installing collected packages: py, pytest
Successfully installed py-1.4.31 pytest-2.8.5
$ head -n 1 env/bin/py.test
#!/Users/jaraco/Dropbox/code/public/aspen/env/bin/python3

कमिट के अनुसार, पाइप 6.0 में जारी डिस्टलिब 0.2.0 को शामिल करने के साथ उस वर्कअराउंड पर टिप्पणी की गई थी।

वह प्रतिबद्ध संदर्भ pip 2031 ।

इसके अलावा, मैंने python.org मैक इंस्टॉलर से पायथन स्थापित किया है, होमब्रे या अन्य तरीकों से नहीं।

इस कमिट में कोड को

मुझे लगता है कि यह "अपेक्षित" होना चाहिए कि आपका प्रारंभिक $ python __VENV_LAUNCHER__ और उसके बाद अन्य स्क्रिप्ट/निष्पादन योग्यों को बेवकूफ़ बना रहा है। दुर्भाग्य से मेरे पास डिबग करने के लिए OS X नहीं है कि वास्तव में "मूर्खतापूर्ण" की प्रक्रिया कैसे चलती है।

#620 . में रिपोर्ट की गई समान / समान समस्या भी हो सकती है

@jaraco यह एक pip को संशोधित करने के लायक हो सकता है ताकि उल्लिखित डिस्टलिब लाइनों को असम्बद्ध किया जा सके और यह देखने के लिए कि क्या गलत अजगर को लिखने के लिए पाइप के व्यवहार को ठीक करना प्रतीत होता है

मैंने उस वेनव डिटेक्शन कोड को इस कमिट में वापस ढूंढ लिया, जो दुर्भाग्य से विचार की उत्पत्ति को स्पष्ट नहीं करता है।

ऐसा लगता है कि कोई भी इस env var का अर्थ नहीं जानता है ।

मुझे यह स्पष्टीकरण मिला

मेरा झुकाव वैसा ही था जैसा रोनाल्ड ने यहां सुझाया था ।

@vsajip क्या आप कोई सलाह दे सकते हैं?

कुछ विचार:

• __PYVENV_LAUNCHER__ जोड़ा गया था क्योंकि पायथन के पुराने संस्करणों के लिए (<3.3, रोनाल्ड के अनुसार) लेकिन बाद के संस्करणों के लिए नहीं, ओएस एक्स पर पायथन के site.py को फ्रेमवर्क एक्जिक्यूटिव से स्टब लॉन्चर के स्थान को अलग करने की आवश्यकता थी। नेड डेली की इस टिप्पणी के अनुसार, sys.executable अब स्टब लॉन्चर की ओर इशारा करता है, और यही कारण है कि distlib ने __PYVENV_LAUNCHER__ का उपयोग करना बंद कर दिया। इसका एकमात्र उपयोग अब site.py - यदि उपलब्ध हो, तो OS X पर, इसका उपयोग pyvenv.cfg फ़ाइल का पता लगाने के लिए किया जाता है।
• यह देखने के लायक हो सकता है कि क्या होता है उदाहरण के लिए पायथन 3.4, यह देखने के लिए कि क्या किसी प्रकार का प्रतिगमन है, या क्या सभी पायथन> = 3.3 का व्यवहार समान है।
• मेरा अनुमान है कि कुछ, कहीं, os.path.realpath() कॉल कर रहा है जब यह नहीं होना चाहिए। ऐसा नहीं लगता कि यह distlib ऐसा कर रहा है। अगर (नेड की टिप्पणी के अनुसार) sys.executable और env var हमेशा समान होते हैं, तो इससे कोई फर्क नहीं पड़ता; लेकिन अगर कोई realpath sys.executable करता है और परिणाम के माध्यम से पायथन को निष्पादित करता है, तो इसके परिणामस्वरूप एक अप्रत्याशित शेबैंग होगा (क्योंकि sys.executable तब एक संदर्भित पथ होगा)।

A(Nother) समस्या का सरल प्रदर्शन, जिसे Homebrew ने https://github.com/Homebrew/homebrew-core/pull/8129 में फिर से खोजा:

$ virtualenv -p python3 test
$ test/bin/python3 -c 'import sys; print(sys.executable)'
/Users/tim/test/bin/python3

$ /usr/local/bin/python3 -c 'import subprocess; subprocess.call(["/Users/tim/test/bin/python3", "-c", "import sys; print(sys.executable)"])'
/usr/local/bin/python3

$ /usr/local/bin/python3 -c 'import subprocess, os; del os.environ["__PYVENV_LAUNCHER__"]; subprocess.call(["/Users/tim/test/bin/python3", "-c", "import sys; print(sys.executable)"])'
/Users/tim/test/bin/python3

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

मुझे लगता है कि मैं इस मुद्दे की अधिक गंभीर अभिव्यक्ति से प्रभावित हुआ हूं।

मैंने xonsh को अपने दैनिक खोल के रूप में उपयोग करना शुरू कर दिया है।

लेकिन जब मैं xonsh के तहत virtualenv का उपयोग करने का प्रयास करता हूं, तो यह अनुपयोगी होता है:

~ $ cd ~/draft
draft $ virtualenv --version
16.0.0
draft $ virtualenv .env
Using base prefix '/Library/Frameworks/Python.framework/Versions/3.7'
New python executable in /Users/jaraco/draft/.env/bin/python3
Also creating executable in /Users/jaraco/draft/.env/bin/python
Installing setuptools, pip, wheel...done.
draft $ .env/bin/pip install paver
Collecting paver
  Using cached https://files.pythonhosted.org/packages/98/1e/37ba8a75bd77ea56a75ef5ae66fe657b79205bbc36556c9456cd641782a4/Paver-1.3.4-py2.py3-none-any.whl
Collecting six (from paver)
  Using cached https://files.pythonhosted.org/packages/67/4b/141a581104b1f6397bfa78ac9d43d8ad29a7ca43ea90a2d863fe3056e86a/six-1.11.0-py2.py3-none-any.whl
Installing collected packages: six, paver
Successfully installed paver-1.3.4 six-1.11.0
  The script paver is installed in '/Users/jaraco/draft/.env/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
draft $ .env/bin/paver --help
Traceback (most recent call last):
  File ".env/bin/paver", line 7, in <module>
    from paver.tasks import main
ModuleNotFoundError: No module named 'paver'
draft $ head -n 1 .env/bin/paver
#!/Library/Frameworks/Python.framework/Versions/3.7/bin/python3

ऐसा लगता है कि सभी स्थापित स्क्रिप्ट सिस्टम उपसर्ग प्राप्त कर रहे हैं, वर्चुअलएन्व उपसर्ग नहीं।

यह शायद इस तथ्य से उपजा है कि xonsh पायथन 3.7 (सिस्टम उपसर्ग) के तहत चल रहा है और इसलिए यह env में है:

draft $ env | grep LAUNCHER
__PYVENV_LAUNCHER__=/Library/Frameworks/Python.framework/Versions/3.7/bin/python3

अगर मैं इसके बजाय zsh लॉन्च करता हूं और वही कमांड चलाता हूं या यदि मैं पहली बार del $__PYVENV_LAUNCHER__ आह्वान करता हूं, तो पेवर अपेक्षित रूप से चलता है और शेबैंग लाइन वर्चुअलएन्व को इंगित करती है।

क्या xonsh शुरू होने पर उस पर्यावरण चर को साफ़ करना चाहिए?

https://github.com/python/cpython/pull/9516 पर एक संभावित बगफिक्स है

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

मैं अभी भी Mojave पर Python 3.7.6 (Homebrew के माध्यम से स्थापित) के साथ यही व्यवहार देखता हूं।

क्या आप पुनर्लेखन शाखा से जांच कर सकते हैं?

@gaborbernat rewrite शाखा (fbdd782257d8eace7f5440a2b665f2ddb72e9db6) बनाने का प्रयास करने से मुझे python3 setup.py build से बिल्ड त्रुटि मिलती है।

...src/virtualenv/__init__.py", line 3, in <module>
    from .version import __version__
ModuleNotFoundError: No module named 'virtualenv.version'

जो इस मुद्दे से असंबंधित दिखता है।

पुनर्लेखन शाखा (fbdd782) बनाने का प्रयास करने से मुझे python3 setup.py बिल्ड से एक बिल्ड त्रुटि मिलती है।

आपको निर्माण करने के लिए पाइप का उपयोग करना चाहिए - pip wheel . - क्योंकि पुनर्लेखन शाखा निर्माण प्रक्रिया को परिभाषित करने के लिए pyproject.toml का उपयोग करती है।

आपको जो त्रुटि मिल रही है, वह यह कहने का तरीका है कि मैं अजगर पुस्तकालयों (PEP-517/518) के निर्माण के नए मानक तरीके का समर्थन नहीं करता। यह सबसे अच्छा एक सेटपूल बग है, लेकिन जैसा कि @pfmoore ने बताया कि आपको पहिया बनाने के लिए पाइप का उपयोग करना चाहिए, या इसे स्थापित करने के लिए वर्चुअलएन्व फ़ोल्डर में इंगित करने के लिए इससे भी बेहतर (यह स्वचालित रूप से एक पहिया का निर्माण करेगा और इसे एक बार में स्थापित करेगा)।

परीक्षण का मामला:

#!/bin/bash
rm -rf venv-test
virtualenv --python python3 venv-test
python3 -c 'import subprocess; subprocess.check_call(["./venv-test/bin/pip3", "install", "markdown"])'
shebang=$(head -1 venv-test/bin/markdown_py)
expected_shebang="#!$(pwd)/venv-test/bin/python"
if [ "$shebang" == "$expected_shebang" ]; then
    echo "PASSED"
else
    echo "FAILED: \"$shebang\" != \"$expected_shebang\""
    exit 1
fi

यह python3+virtualenv 16.7.9 के तहत विफल रहता है, और python3+virtualenv-16.7.10.dev11+gfbdd782 (यानी, rewrite शाखा) के अंतर्गत गुजरता है।

ऊपर के अनुसार पुनर्लेखन में निश्चित।