+1 ، تم تأكيده في نظام التشغيل Mac OS X 10.7.3 و Python 2.7.1

نوع من الإزعاج ، سيكون من الرائع الحصول على حل

نحن قادرون على إنشاء Virtualenv بمسافات في الاسم (انظر # 278) ، ولكن easy_install و pip يتعثران لاحقًا:

% 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

أنا هنا أيضًا لأؤكد أن هذه مشكلة في OS X (10.8 هنا). إذا قمت بتحرير متغير VIRTUAL_ENV ووجدت في سلة المهملات ، يمكنك جعله يعمل ، لكن بيئة جديدة تختنق أي مسافات في المسار. وهي مشكلة كبيرة بالنسبة إلى OS X ، نظرًا لأن محرك أقراص التمهيد يسمى عادةً "Macintosh HD" ، لذلك يبدأ كل مسار بـ "/ Volumes / Macintosh HD ..."

الاختراق الذي أستخدمه يعمل على النحو التالي.

بن / تفعيل:

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

bin / pip and bin / easy_install:

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

يبدو أن Pip يعمل بعد هروبه من المساحة الموجودة في المسار.

لماذا تم إغلاق هذا؟ لا تزال مشكلة كبيرة. تحرير خطأي ، لا يزال مفتوحًا

هذه القضية لا تزال تظهر مفتوحة.

تمكنت من الالتفاف حول هذا إنشاء رابط رمزي من دليلي الرئيسي إلى الدليل الذي كنت أرغب في العمل فيه (والذي كان يحتوي على مساحة بداخله).

أنا أرى هذا أيضًا لأن Mac. يمكنني الالتفاف حول هذا عن طريق تحرير سطر shebang يدويًا في البرامج النصية إلى! # / usr / bin / env python وجميع الأعمال. ومع ذلك ، كما ذكر آخرون ، يجب القيام بذلك مع كل بيئة جديدة وأي نصوص إضافية مثبتة في البيئة.
يبدو أن هذا يجب أن يكون إصلاحًا سهلاً في الكود إما للهروب من المساحة أو استخدام / usr / bin / env إذا كان is_darwin. ولكن بما أنني مستجد إلى حد كبير في هذا الأمر ، فقد أكون مخطئًا.

هذا ليس فقط لنظام التشغيل Mac ، إنه في الأساس جزء من مواصفات / سلوك أنظمة * nix.

لا يمكن أن يكون لديك مسافات في الوسيطة الأولى من سطر shebang (سيتم تحويلها إلى حجج منفصلة بدلاً من ذلك) ، وعادةً لا يسمح بالتهريب / الاقتباس أيضًا.

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

أعلم ، واجهت هذه المشكلة مع الأناكوندا أيضًا. إنه مستوطن مع Mac لأن اسم محرك الأقراص به مسافة بيضاء فيه.

يبدو أنه سيتم تصحيح هذا بواسطة # 611. هل كان هناك أي مراجعة لفعالية طلب السحب هذا؟

مزعج للغاية ، يجب إصلاحه في أسرع وقت ممكن.

انظر الرابط Ivoz المنشور ، هذا هو قيود يونكس. # 611 قد تعمل مع بعض متغيرات Unix ، إذا كانت تدعم عمليات الهروب بالخط المائل العكسي في سطر shebang ، لكن ليس من الواضح أي الإصدارات تعمل (والكود يفعل ذلك بشكل أعمى دون التحقق - وهو ما لن يجعل المشكلة _الأسوأ_ ، لكنه فاز " تساعد إما إذا لم تكن مدعومة ...)

من الصحيح حقًا أن هذا نتيجة للطريقة التي يتعامل بها يونكس مع خطوط shebang ، ولكن إذا أدى # 611 إلى حل المشكلة لبعض الأنظمة ولم يؤدي إلى تفاقم المشكلة بالنسبة للآخرين ، فهل سيظل ذلك بمثابة تحسن؟

إذا كان هذا صحيحًا ، فعندئذ نعم. لكن لا يمكنني التعليق على # 611 لأنني لست مطور Unix. قد تكون هناك حالات تجعل الأمور فيها أسوأ ، أنا فقط لا أعرف. آسف لا أستطيع أن أكون أكثر من المساعدة.

عادل بما يكفي. # 611 ربما يحتاج إلى مزيد من الدراسة بعناية واختبار الحالات الهامشية.

والأسوأ من ذلك: على النوافذ ينكسر على مسار Jenkins الافتراضي بنفس الخطأ:
فادح: المسافات البيضاء غير مسموح بها في مسار مترجم بايثون: C: \ Program Files (x86) \ Jenkins \ shiningpanda \ jobs \ c3418983virtualenvs \ d41d8cd9

لقد تأثرت للتو بهذه المشكلة. باتباع الإرشادات التي وجدتها في StackOverflow ، تمكنت من جعل pip يعمل فقط من خلال تعيين السطر الأول على #!/usr/bin/env python

ومع ذلك ، لست متأكدًا مما إذا كان هذا الحل يعمل مع جميع الحالات ... أعني ، لست متأكدًا من نوع Python الذي سيتم تنفيذه

يعني تغيير شيبانج للنصوص المثبتة إلى "env python" أنها ستعمل فقط في virtualenv مفعلة. تم إنشاء البرامج النصية بمسارات مطلقة صريحة بحيث يمكنهم دائمًا استخدام Python في venv ، وبالتالي العثور على الحزم المثبتة التي تحتاجها البرامج النصية.

اقتراحي هو أن يقوم شخص ما (من المحتمل أن يكون هناك شخص متأثر بهذه المشكلة ، ولكن على الأقل شخص ما على نظام أساسي لديه المشكلة ولديه طريقة لحلها أيضًا) يقدم طلب سحب لتنفيذ فحص على غرار:

• إذا كانت لدينا مسافات في اسم المسار ،
• ونحن على المنصة XXX ،
• ثم اكتب سطر shebang مع الهروب التالي للتعامل مع المسافات.
• في جميع الحالات الأخرى ، ارجع إلى السلوك الحالي.

يمكن بعد ذلك إجراء المزيد من الإضافات من قبل الأطراف المهتمة فقط بإضافة اختبارات إضافية للمنصة.

من الناحية المثالية ، سيكون من الجيد تضمين تعليق مع رابط إلى الوثائق التي تؤكد كيف يدعم النظام الأساسي XXX المسارات ذات المسافات ، بحيث يكون لدى المشرفين في المستقبل مرجع للتحقق منه. أنا شخصياً لا أعرف ما الذي يصلح العمل وأين:

1. تشير المناقشة هنا إلى أن علامات الاقتباس المزدوجة تعمل على OSX ، ولكن هل يعتمد ذلك على إصدار OSX الدقيق؟
2. في # 611 تم استخدام مسافات هروب مع خطوط مائلة عكسية ، ولكن لم يكن هناك تأكيد على ما هو نظام التشغيل (Linux؟ إصدار نواة معين؟ توزيعة معينة؟)

لاحظ أنه لا يجب استخدام مثل هذه المتغيرات الخاصة بالنظام الأساسي /usr/bin/env . كما أشار merwok ، ينتج عن ذلك تغيير في السلوك - تتم كتابة shebang عن عمد للسماح بتشغيل البرنامج النصي _ دون _ تنشيط البيئة.

إن إضافة بعض الاختبارات للتأكد من أن السلوك كما هو متوقع (بما في ذلك مبدأ أنه يتراجع عندما لا نكون على منصة معترف بها على وجه التحديد) سيكون مفيدًا للغاية أيضًا ، ولكنه سيكون أيضًا صعبًا ، لأنه قد يتضمن اصطياد القردة السماح باختبار النظام الأساسي XXX عندما لا تعمل بالفعل على هذا النظام الأساسي.

pfmoore كما ذكرت ، لقد تأثرت مؤخرًا بهذه المشكلة وأنا أقوم بتشغيل Linux Mint 18. لم أقم بالمساهمة مطلقًا مع Virtualenv ولكني حاليًا في Python Brasil وسيكون لدينا يوم مخصص للسباقات السريعة ، ربما أعطيها محاولة!

لن يعمل الهروب باستخدام خطوط مائلة عكسية أو علامات اقتباس ، وفقًا لـ https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00052.html

من الناحية التجريبية ، يمكنني التحقق من أن الهروب باستخدام خطوط مائلة عكسية أو علامات اقتباس لا يعمل مع OSX 10.11.6.

يجب على virtualenv الابتعاد عن shebangs التي تعتمد على النواة. لقد تحققت من رموز مصدر Linux و XNU (نواة macOS) و FreeBSD و OpenBSD و NetBSD. لا أحد منهم يمكنه التعامل مع المساحات في شيبانج.

قبل أن يكون هناك حل ، لا تستخدم مسافات.

أرسل تصحيحًا يضيف تحذيرًا لـ venv الجديد من Python 3 ، والذي يشبه إلى حد كبير Virtualenv ولكن تم رفضه بواسطة vsajip : http://bugs.python.org/issue28446. في الواقع ، ليس خطأ بايثون بل خطأ نظام التشغيل. ربما يمكن إغلاق هذه القضية؟

كنقطة بيانات إضافية ، لاحظ السلوك على Windows ، والذي يبدو كما هو متوقع:

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

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" - الإصدار
pip 6.0.8 من C: \ Temp \ aaa bbb \ lib \ site -packs (python 3.4)

C: \ Users \ Vinay> pyzzer -i "\ Temp \ aaa bbb \ Scriptspip.exe"
هناك قاذفة.
شيبانج: #! "C: \ Temp \ aaa bbb \ Scripts \ python.exe"

محتويات الأرشيف:
__الرئيسية__

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scripts \ python" -m pip install -U pip
أنت تستخدم إصدار pip 6.0.8 ، ولكن الإصدار 9.0.1 متاح.
يجب أن تفكر في الترقية عبر الأمر "pip install --upgrade pip".
تجميع النقاط من https://pypi.python.org/ [...] / pip-9.0.1-py2.py3-none-any.whl # md5 = 297 [...]
استخدام pip-9.0.1-py2.py3-none-any.whl المخزن مؤقتًا
تركيب الحزم المجمعة: نقطة
تم العثور على التثبيت الحالي: النقطة 6.0.8
إلغاء تثبيت pip-6.0.8:
تم إلغاء تثبيت pip-6.0.8 بنجاح

تم تثبيت pip-9.0.1 بنجاح

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" - الإصدار
pip 9.0.1 من C: \ Temp \ aaa bbb \ lib \ site -packs (python 3.4)
""

تعمل البرامج النصية لـ Yep virtualenv على Windows حيث يحدد distlib بروتوكول shebang الخاص به في جهاز الكمبيوتر / launcher.c. ربما يمكن أن يكون لـ POSIX شيء مشابه - محلل shebang الخاص بمساحة المستخدم بدلاً من النواة غير الموثوق بها.

محلل Shebang مساحة المستخدم بدلاً من حبات غير موثوقة

لست متأكدًا من سبب عدم تمكن Bash من القيام بذلك (على سبيل المثال) - لا أعتقد أنه شيء يتعلق بفضاء النواة.

يتم التعامل مع Shebangs في مساحة النواة لأنها يجب أن تكون قابلة للاستخدام في الخارج.

تفاصيل تقنية:
في الأنظمة المشابهة لـ UNIX (Linux ، Mac ، * BSD ، ...) ، يتم إنشاء برنامج جديد عبر fork () و exec (). exec () مشابه لـ CreateProcess () على Windows ، والذي يقوم بتشغيل برنامج جديد. في الأنظمة المشابهة لـ UNIX ، يستدعي exec () استدعاء النظام execve (). يتم تنفيذ الوظيفة الأخيرة في الألباب ، لذلك يتم تحليل shebang في الألباب.
لا يمكن تنفيذه في مكتبات C ، أو لن تعمل البرامج أو البرامج المرتبطة الثابتة التي تستخدم مكالمات النظام مباشرة (عبر int 80 أو sysenter ، إلخ).

ربما يجب علينا فقط منع إنشاء بيئة افتراضية مع وجود مسافات في المسار. لن يعمل كما هو متوقع على أي حال

يتم التعامل مع Shebangs في مساحة النواة لأنها يجب أن تكون قابلة للاستخدام خارج الأصداف

نعم ، لكن لا يمكن أن تقوم shell بالتحليل نفسه إذا أرجع استدعاء النظام ENOEXEC ؟ أدرك أنه قد يكون علبة ديدان ...

معلومة مثيرة للاهتمام - يبدو أن وظيفة kernel على نظام Linux

كانت هذه الصفحة أيضًا قراءة ممتعة: http://www.in-ulm.de/~mascheck/various/shebang/

نعم ، لكن لا يمكن أن تقوم shell بالتحليل نفسه إذا أرجع استدعاء النظام ENOEXEC ؟

قد تؤدي دلالات IMO المختلفة بين الأصداف والنواة الأساسية إلى حدوث الكثير من الارتباك للمستخدمين وكذلك المطورين. في الوقت الحالي ، يتم تحليل bash و zsh على الأقل عند فشل execve () ، ولكن فقط من أجل تحسين الإبلاغ عن الأخطاء ، وعدم توفير احتياطي.

معلومة مثيرة للاهتمام - يبدو أن وظيفة kernel على Linux قد تمت كتابتها من قبل ملتزم Python منذ فترة طويلة Martin von Löwis :-)

مثير للإعجاب! لم ألاحظ ذلك :) أيضًا شكرًا على المواد الإضافية. أثناء قراءة التعليمات البرمجية المصدر لـ kernel هي أسرع طريقة ، تظل هذه المستندات مفيدة.

حول فكرة fbidu :

ربما يجب علينا فقط منع إنشاء بيئة افتراضية مع وجود مسافات في المسار. لن يعمل كما هو متوقع على أي حال

يعد إنشاء بيئات افتراضية بمسارات هشة مفيدًا لاختبار حالات الزاوية في معالجة المسار. في هذا المثال يوضح كيفية كسر النواة. فكرتي هي إضافة التحذيرات بدلاً من الحظر ، تمامًا مثل التصحيح الذي نشرته على http://bugs.python.org/issue28446

أعتقد أن # 994 "فشل Pip مع وجود مساحة في مسار virtualenv" هو تكرار لهذه المشكلة.

أريد أن أكرر التعليق من https://github.com/pypa/virtualenv/issues/997#issuecomment -270681253 ، "virtualenv مكسورة بسبب التحليل الهش لـ kernel shebang." وبهذه الروح ، يعد # 1014 "غير متوافق مع دليل يحتوي على رموز تعبيرية في مساره" مثالًا آخر على كسر Virtualenv بواسطة تحليل نواة shebang الهش. أراهن أن المشكلة تحدث مع أي أحرف غير ASCII في المسار ، في الواقع.

ربما يجب علينا جمع الجوانب الثلاثة لتحليل kernel shebang الهش في مشكلة واحدة ، حتى نتمكن من التأكد من أن الإصلاح الواحد يمكنه معالجة المسافات والطول والأحرف غير ASCII في مسار virtualenv؟ أنا أرشح هذا العدد لأنه الأقدم.

أثناء عملنا على إصلاح ، أعتقد أنه سيكون من الجيد لـ virtualenv طباعة تحذير عندما يُطلب منك إنشاء بيئة في مسار أ) به مسافات ، ب) طويل جدًا ، أو ج) يحتوي على أحرف غير ASCII. جملة في بعض الوثائق قد تساعد أيضا.

أراهن أن المشكلة تحدث مع أي أحرف غير ASCII في المسار ، في الواقع.

أعتقد أن سبب # 1014 هو في Virtualenv بدلاً من kernel. لديّ تصحيح يعمل على إصلاح مشكلة مشابهة تمامًا في # 900.

تحية للجميع،
هذا أمر مزعج للغاية ومضيعة كبيرة للوقت بسبب شيء يبدو بسيطًا جدًا (سبب بسيط على الأقل).

ماذا عن إعادة التسمية (عندما يكون ذلك ممكنًا) ، أو استخدام الروابط (إنشاء دليل مثل /virtualenvs/python3.5 بدون مساحة ، ثم ترك هذا رابطًا بسيطًا للدليل الأصلي؟)

إنشاء دليل مثل /virtualenvs/python3.5 بدون مسافة

قام مشروع آخر virtualenvwrapper بعمل شيء مشابه تمامًا.

شيء يبدو بسيطًا جدًا (سبب بسيط على الأقل).

كلاهما ليس بسيطا. يرتبط السبب برموز تحليل kernel ويتطلب الحل البديل معالجة shebang مساحة المستخدم.

لا تزال مشكلة بعد 6 سنوات؟

لقد أوقفتني هذه المشكلة منذ أسبوعين. نعم ، لا تزال مشكلة.

لاحظ أنه نظرًا لأنها مشكلة في نظام التشغيل Unix وليست مشكلة افتراضية ، فمن غير المرجح أن يتم "إصلاحها" ما لم تتم إزالة قيود Unix kernel ...

أول خطأ في virtualenv هو أن virtualenv اختار تنفيذ ملفات قابلة للتنفيذ باستخدام خاصية Unix kernel معينة ، على الرغم من أن هذه الميزة لها قيود تسبب بشكل روتيني مشاكل لمستخدم virtualenv. يمكن لبرنامج Virtualenv إصلاح هذا باستخدام آلية مختلفة لملفات shell القابلة للتنفيذ. الخطأ الثاني في virtualenv هو عدم وجود وثائق حول كيفية استخدام المستخدمين لـ virtualenv من أجل التغلب على الخطأ الأول (إنشاء Virtualenv فقط على مسارات قصيرة مع أحرف ASCII فقط وبدون مسافة بيضاء). الخطأ الثالث في Virtualenv هو أنه لا يوجد لديه آلية تكتشف الحالات التي يختار فيها المستخدم مسار virtualenv الذي سيطلق الخطأ الأول ، ويطبع رسالة تحذير مفيدة. هناك الكثير مما يمكن أن يفعله مساهمو virtualenv لتحسين الوضع.

JDLH حول "الخطأ" الأول الخاص بك: لا يتم التعامل معه بواسطة Virtualenv ولكن distlib ، وهناك تطبيق على https://bitbucket.org/pypa/distlib/pull-requests/31/. آمل أن يكون لدي الوقت لدراسة الأجزاء الداخلية من distlib والرد على تعليقات Vinay Sajip بشكل صحيح ولكن للأسف لا أفعل.

أول خطأ في Virtualenv هو أن virtualenv اختار تنفيذ ملفات قابلة للتنفيذ باستخدام خاصية Unix kernel معينة

JDLH هذا ليس خاصًا بـ virtualenv - _all_ ملفات Unix النصية (أي الملفات ذات خطوط shebang) تستخدم ميزة kernel هذه - ولا يوجد سبب مقنع لإعادة اختراع virtualenv (أو أي شيء آخر) طريقة جديدة تمامًا لإرسال البرامج النصية ، عندما تكون الآلية الحالية مستخدمة على نطاق واسع ومفهومة جيدًا. إذا كتبت نصًا يدويًا يحتوي على مسافات في مسار المترجم الفوري (لا يوجد virtualenv متضمنًا) فسيواجه نفس المشكلة.

هناك الكثير مما يمكن أن يفعله مساهمو virtualenv لتحسين الوضع.

ربما تكون هناك مكالمات عديدة في وقت المساهمين. تؤثر هذه المشكلة على العدد الصغير نسبيًا من الحالات التي يتم فيها استخدام مسارات / مسارات طويلة ذات مسافات. ربما يمكن لبعض هؤلاء المستخدمين المتأثرين مساعدة المساهمين لمساعدتهم من خلال اقتراح تصحيح يساعد في الكشف عن رسائل التحذير؟ مجرد فكرة.

@ yan12125 distlib يسمح للشخص بتحديد الملف القابل للتنفيذ في سطر shebang كما يريد المرء. ربما لن يتم إصلاح قيود kernel على المسافات البيضاء / الأسطر الطويلة من قِبل مطوري Linux بسبب التوافق مع الإصدارات السابقة. يمكن للمرء فقط توفير سلسلة مخصصة لـ shebang القابل للتنفيذ (يتضمن مكافئًا معممًا لاختراق برنامج Mozilla النصي) ويجب أن يكتبه distlib في البرنامج النصي ، بحيث يمكن للمرء تجربته تمامًا مثل distlib مستخدم

هذا ليس خاصًا بـ virtualenv

vsajip هذا بيان صحيح - تستخدم البرامج الأخرى نفس آلية shebang التي اختارها virtualenv - لكنها تخطئ الهدف من هذه المشكلة. لا يوجد شيء حول القيمة التي تقدمها virtualenv التي تتطلب استخدام shebang. يمكن لـ virtualenv استخدام آلية مختلفة ، لكنها اختارت shebang ، وبالتالي فإن virtualenv حقًا ترث حدود shebang.

لا يوجد سبب مقنع لـ Virtualenv (أو أي شيء آخر) لإعادة اختراع طريقة جديدة تمامًا لإرسال البرامج النصية

أعتقد أن ما تقوله هو أن المشاكل التي واجهها الأشخاص الذين واجهوا هذه المشكلة على مر السنين ليست "قاهرة". أعتقد أن السبب الذي جعل الكثير من الناس يجدون ويعلقون على هذه المسألة على مر السنين هو أنهم يجدون المشاكل "مقنعة". أنا بالتأكيد أفعل.

ربما يمكن لبعض هؤلاء المستخدمين المتأثرين مساعدة المساهمين لمساعدتهم من خلال اقتراح تصحيح يساعد في الكشف عن رسائل التحذير؟ مجرد فكرة.

اخترت كلمة "مساهمون" لتضمين كل من أصحاب العمل الراسخ الذين يقومون بمعظم العمل على virtualenv ، والزائرين مثلي الذين يجدون هذه المشكلة مقنعة بما يكفي للعمل على تقليل تأثيرها. من العدل أن نقول إننا الذين نجد أن المشكلة مقنعة يجب أن نساهم في تصحيحها.

سيكون من المفيد أن يقترح أصحاب النفوذ الذين يعرفون Virtualenv جيدًا أساليب واعدة. إذا كنت أرغب في إدراج رسالة تحذير للمستخدم الذي يكتب virtualenv ~/my\ long\ path\ with\ spaces ، فأين يجب أن يكون هذا الرمز أفضل مكان؟ هل توجد قيود غير واضحة على مثل هذه الرقعة ، والتي يمكن أن يشاركها القوى القوية ، لإزالة عقبة من الزائر الذي يعمل على مساهمته الأولى؟ هل لدى الرواد اعتراضات تاريخية على قبول مثل هذه الرقعة؟ (أعني ، لا يمكنني أن أكون أول شخص يفكر في إضافة رسالة تحذير. يجب أن يكون هناك سبب لعدم حدوث ذلك بعد.)

يوجد مسار واحد مشهور يحتوي على مسافات ولا يمكن تعديله: /Users/iulian/Library/Mobile Documents/com~apple~CloudDocs . لذا فإن أي شخص يريد الاحتفاظ ببعض البرامج النصية مُدارة باستخدام virtualenv في iCloud يصطدم بهذه المشكلة.

سيكون من المفيد أن يقترح أصحاب النفوذ الذين يعرفون Virtualenv جيدًا أساليب واعدة.

حسنًا ، إذا عرفنا أيًا منها ، فربما لم نترك هذه المشكلة دون حل لفترة طويلة ، نظرًا لمقدار النقد الذي يبدو أننا نواجهه للقيام بذلك :-(

إذا أردت إدراج رسالة تحذير للمستخدم الذي يكتب virtualenv ~ / my \ long \ path \ with \ space ، فأين يجب أن يكون هذا الرمز أفضل مكان؟

يمكنك البدء بالنظر في كود تحليل الوسيطة ، وإضافة فحص بمجرد تحديد المسار.

هل توجد قيود غير واضحة على مثل هذه الرقعة ، والتي يمكن أن يشاركها القوى القوية ، لإزالة عقبة من الزائر الذي يعمل على مساهمته الأولى؟

أنها يمكن أن معظمها يمكن العثور عليها عن طريق البحث في قائمة المسألة هنا لمختلف الملاحظات التي أبديت حول هذا الموضوع وقضايا أخرى على مر السنين، ولكن في البداية، عليك أن لا ترفض مسارات عندما ستعمل - وهذا يعني العمل على ما القيود على OS يفرض. هذه تختلف بشكل كبير بين الأنظمة. يسمح Windows بمسافات وأسماء ملفات طويلة ، وبعض أنظمة Unix تسمح بمسافات ، وبعضها يحتاج إلى مسارات بها مسافات ليتم اقتباسها ، وبعضها له حدود طول قصيرة جدًا (32 حرفًا؟) بعضها أطول ، ... العديد من القيود غير موثقة جيدًا ، وقليل جدًا يمكن للمساهمين الوصول إلى أنظمة كافية ليكونوا قادرين على اختبار كل الاحتمالات الكافية لتكملة المستندات المتاحة.

هل لدى الرواد اعتراضات تاريخية على قبول مثل هذه الرقعة؟

لا ، بخلاف "لا تفترض أن الأمر بسيط كما تعتقد للوهلة الأولى ، ولا تتجاهل جميع الأنظمة المختلفة (الغامضة أحيانًا) التي يتعين علينا دعمها".

إذا كان شخص ما يريد أن يأخذ طعنة في هذا - ويجب أن يدرك أنه ليس شيئًا أوصي به شخصيًا باعتباره "مساهمة أولى" - فعليه البدء بقراءة كل السجل المتاح في مختلف القضايا (بعضها مرتبط من هذا ، والبعض الآخر ربما لا ، وبعضها على الأرجح على متتبع الأنابيب وربما حتى متتبع distlib أو setuptools) ويلخص في العلاقات العامة الجديدة القيود التي تفرضها أنظمة تشغيل مختلفة. افترض أنه كتصحيح توثيق ينص على أنه "ما لم يتم استيفاء هذه الشروط ، فإن رؤوس shebang المستخدمة بواسطة 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 ؟ لا أفهم لماذا يتعين علينا استخدام shebang مباشرة.

@ raxod502 أفترض أنك تدرك أن هذا لن يعمل على Windows. أيضًا ، أعتقد أن التعويذة "العادية" المطلوبة في السطر الثاني أكثر تعقيدًا من تلك التي تقدمها (على الرغم من أنني لا أعرف السبب شخصيًا). ربما يمكنك العثور على الطريقة الصحيحة من خلال البحث على الويب. باستخدام منهجك ، ماذا سيحدث للمسارات التي تحتوي على أحرف " أو $ فيها؟

بافتراض أنه يمكنك معالجة هذه الأنواع من القضايا ، أعتقد أن الخطوة التالية ستكون بالنسبة لك إرسال بيان عام (وفقًا للتعليقات أعلاه) ويمكننا مناقشة التفاصيل حول ذلك. ستحتاج إلى الحصول على واحد على الأقل من الملتزمون الأساسيون في Virtualenv والذين يعملون على Unix - بصفتي مستخدم Windows ، لن أكون على استعداد لدمج العلاقات العامة الخاصة بـ Unix مثل هذا بنفسي.

تضمين التغريدة
الحل المقترح من قبل @ raxod502 يمكن أن يعمل أيضًا على windows مع ملف نصي .bat ، afaik؟

@ gst إجابة قصيرة ، لا. الجواب طويل هو في http://paul-moores-notes.readthedocs.io/en/latest/wrappers.html وكانت هناك العديد من المناقشات حول هذه النقطة على مر السنين، وفي كل مرة شخص ما لديه التوصل إلى حل خلاف غلاف exe ، كان لديه مشاكل.

في هذه الحالة ، يرجى تذكر أن هذه المشكلة غير موجودة على Windows . لذلك لا يوجد سبب مطلقًا لتغيير أي شيء في بيئة Windows - يجب أن يقتصر أي تغيير على نظام التشغيل Unix فقط.

شكرا على الاجابة الجيدة :)

بخلاف غلاف exe ، كان به مشاكل.

أنا شخصياً أستطيع التعايش مع ذلك (إذا كان عليّ ذلك).

لقد قمت بتحديث distlib للتعامل مع المسارات الطويلة والمسارات بمسافات. لم أستخدم رقعة Harald Nordgren مباشرةً (كانت بها بعض المشكلات - على سبيل المثال لا توجد اختبارات) ولكن النهج هو نفسه - باستخدام "/ bin / sh" باعتباره الملف القابل للتنفيذ. pip / virtualenv قد يرغب المشرفون على الصيانة في الاختبار بعد البيع المحلي للإصدار الحالي من المستودع distlib .

النسخة التطويرية من النقطة تقوم الآن ببيع هذا الإصدار الأحدث من distlib ، مما يعني أن النقطة تتعامل الآن مع المسافات في أسماء الدلائل على ما يرام.

كما أفهمها ، بمجرد إصدار الإصدار التالي من النقطة وإصدار virtualenv ، سيتم إصلاح هذه المشكلة - أي نظام افتراضي جديد يتم إنشاؤه سيدعم المساحات الموجودة في المسار ، وكذلك الثنائيات التي يتم تثبيتها بواسطة نقطة (باستثناء ربما في بعض الحالات الغريبة مثل setuptools أغلفة لم يتم تثبيتها مباشرة بواسطة نقطة).

لقد بدأت للتو في استخدام gvfs لتركيب مشاركات samba في مساحة المستخدم والعثور على Virtualenv / pip وما إلى ذلك تم إلغاؤه بسبب التلاعب في مسارات التحميل التي تم إنشاؤها بواسطة gvfs.

لا توجد مسافات في المسارات ، ولكن هناك الكثير من الأشياء الأخرى لجلب Virtualenv / pip وما إلى ذلك على ركبتيهم في محاولة للركض في مسار يشبه

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

بقدر ما أستطيع أن أرى ، لا يوجد خيار حاليًا في gvfs لمنع علامات الترقيم في مسارات نقاط التحميل التي تم إنشاؤها. الحل الوحيد بالنسبة لي هو عدم إنشاء Virtualenv على حامل gvfs ، والذي يبدو محزنًا بعض الشيء

pradyunsg هل هناك أي جدول زمني لإصدار النقطة التالي؟ كان آخرها منذ أكثر من عام ، ويبدو من الغباء الانتظار طويلاً حتى يظهر هذا الإصلاح البسيط حقًا في virtualenv.

مرحبا @ raxod502!

نعم ، نريد أن نخرجه قريبًا. الشيء هو أننا لا نمتلك وقتًا للمطور لإخراج PEP 518 من الباب ، وهو شيء نريد القيام به. قد يحدث فقط أن هناك نقطة 10 بدون PEP 518 ولكن مرة أخرى ، يعتمد الأمر على إيجاد الوقت لتسوية الخطة على ذلك.

يبدو أن هذا الخطأ قد تم إصلاحه بواسطة النقطة 10.0.0 ، الصادرة في 2018-04-14. بالمعنى الدقيق للكلمة الإصلاح كان في distlib 0.2.6 ، الذي vendored إلى نقطة مع هم PR4819 في أكتوبر 2017، والتي ظهرت للمرة الأولى في 10.0.0b2 نقطة.

يبدو أن الإصلاح الأساسي موجود في 9285cca في Distlib . كما علق vsajip هنا في 28 مايو 2017 ، يتبع النهج فكرة Harald /bin/sh exec بدلاً من ذلك ، والذي يمكنه التعامل مع المسارات الطويلة أو التي تحتوي على مسافات.

لقد أجريت اختبارًا سريعًا على نظام التشغيل Mac OS X 10.11.6 ، حيث صنعت بيئة افتراضية في مسار طويل به مسافات ، ثم استدعت pip3 install ، ويبدو أنه نجح. لم أختبر تمامًا أن كل شيء موصوف في هذا الخطأ قد تم إصلاحه في كل نظام تشغيل.

بعد ترقية النقطة من 9.0.1 إلى 18.1 (تحولوا إلى الإصدار المستند إلى التقويم) و virtualenv من 15.0.1 إلى 16.0.0 باستخدام Ubuntu 16.04.5 LTS ، يبدو أن المشكلة قد ولت:

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

الآن تعمل جميع أوامر pip بشكل صحيح في Virtualenvs التي تحتوي على مسافات في مسار الجذر.

كما أكد JLDH و gandie ، تم حل هذه المشكلة الآن ؛ مع أحدث إصدارات من pip و virtualenv معًا تعمل بشكل صحيح عندما يكون جذر Virtualenv به مسافات.

إغلاق هذا! شكرا للعمل على الإصلاح الأساسي vsajip!

التذكرة القديمة: ولكن لم لا

! / usr / bin / env python؟

rirl ، أعتقد أن ترك تعليق على إصدار مغلق من غير المرجح أن يجذب انتباه فكرتك. تم حل المشكلة. إذا كنت تعتقد أن Virtulenv الجديدة ، مع هذا الحل ، سيتم تحسينها من خلال القيام بالأشياء بشكل مختلف ، فأنت تقترح تغييرًا جديدًا. ضع في اعتبارك فتح عدد جديد ، وقل ما هو التغيير الذي تعتقد أنه يجب أن يحدث ، وقدم حجة عن سبب كون التغيير أفضل من Virtualenv الجديدة.