Pipenv: استخدم venv بدلاً من virtualenv إذا كان ذلك متاحًا

لا أعتقد ذلك ، أفضل استخدام الأمر virtualenv شخصيًا

ربما من الممكن جعل كلا الخيارين يتعايشان على الرغم من ذلك؟ عند تصفح المصدر بشكل عرضي ، لا أرى أي شيء مقترنًا على وجه التحديد بـ Virtualenv باستثناء الأمر المستخدم لإنشاء البيئة المحيطة. يمكن أن يكون Virtualenv دائمًا هو الافتراضي ، ولكن يمكن للمستخدم (على سبيل المثال) تمرير --venv لإنشاء .venv مع python3 -m venv بدلاً من virtualenv .

سأكون بصراحة أعتمد فقط على pipenv ولن أهتم إذا تم استخدام virtualenv أو venv ، لكنني اعتقدت أنه يمكننا الاستفادة من البنايات عند توفرها.

أحث @ kennethreitz على إعادة النظر في تعليقه هنا. يوصى باستخدام venv في الوقت الحاضر.

bulletmark الآن بعد أن قام Pipenv بتفويض جميع إدارة Virtualenv تقريبًا إلى Pew ، أصبح التبديل أكثر صعوبة ، ولكن هناك خطة لدعم Pew venv ومع ذلك (berdario / pew # 67) لذلك لا تزال هناك فرصة. إذا تمكنت Pew من تشغيلها ، فسيكون من الأسهل كثيرًا (وسيكون أكثر منطقية بالنسبة لي على الأقل) تنفيذ دعم venv في Pipenv.

uranusjr تبدو رائعة!

أنا شخصياً لم أستخدم أبدًا venv ، ومن هنا أتخوف من ذلك. أنا متأكد من أنه جيد ، رغم ذلك.

الأمور تعمل بشكل جيد الآن. لا حاجة لتغيير الأشياء التي لم تنكسر.

وأخيرا وجدت هذا الموضوع لأنه كسر نظام بلدي.

إذا أنشأت بيئة باستخدام virtualenv في Python 3.X ، ثم قمت بالترقية إلى Python 3.Y ، فإن virtualenv معطلة لأنك تعلم أن لديك المكتبات المشتركة التي تحتاجها Python. باستخدام venv يمكنك فقط تشغيل python3 -m venv --upgrade .

ستكون هذه ميزة جميلة.

سيكون هذا بالتأكيد رائعًا ويشعر بأنه يتماشى مع اتجاه بايثون

يعد عدم استخدام venv (وبدلاً من ذلك استخدام virtualenv) بمثابة أداة عرض كاملة بالنسبة لي - لا يمكنني استخدام Pipenv. لا يمكنني استخدام virtualenv بسبب سلوكه المحبط لنسخ ثنائي Python ومع ذلك يعتمد على libs المشتركة - كما وجد dhouck أعلاه لاستيائه أعلاه. هذا يكسر Virtualenvs طوال الوقت (كلما تم تحديث نظام python ، تاركًا الثنائي المتدلي) ، ونسخ ثنائي Python بدون أي فائدة على الإطلاق.

إذا كان pipenv هو مستقبل Python ، فيجب أن يكون استخدام venv افتراضيًا على Python 3 (ويحذر عند عدم استخدامه). إنه مدمج في Python 3 ، والأداة الموصى بها. من الغريب جدًا أن Pipenv هي الآن أداة موصى بها ولكنها لا تستخدم venv.

venv بطبيعتها كونها جزءًا من Python نفسها لديها إمكانية الوصول إلى العناصر الداخلية لـ Python مما يعني أنها تستطيع القيام بالأشياء بالطريقة الصحيحة مع عدد أقل بكثير من الاختراقات. على سبيل المثال ، يجب على Virtualenv نسخ ثنائي مترجم Python في البيئة الافتراضية لخداعها للاعتقاد بأنها معزولة ، بينما يمكن لـ venv فقط استخدام ملف التكوين الذي يقرأه ثنائي Python في موقعه الطبيعي حتى يعرف أنه من المفترض أن يعمل كما لو كانت في بيئة افتراضية. لذلك يمكن التفكير في أن venv تم القيام به بشكل صحيح ، بمباركة ودعم مطوري Python.

المصدر: https://www.reddit.com/r/learnpython/comments/4hsudz/pyvenv_vs_virtualenv/

لقد بدأت berdario / pew # 173 ، لكن لم يكن لدي الكثير من الوقت لإحراز تقدم. كما ذكر أعلاه ، سوف يدعم Pipenv هذا تلقائيًا بمجرد قيام Pew بذلك. أود بعض المساعدة إذا كان أي شخص مهتم بجلب venv إلى Pipenv. القضية الرئيسية الآن هي جعل الاختبارات تمر.

تحديث سريع لدعم venv: لن يحدث ، على الأقل في المستقبل القريب. venv ليس جيدًا بما يكفي لتحقيق ذلك. إذا كنت مهتمًا بهذا الأمر حقًا ، فتوجه إلى متتبع أخطاء Python وساعده. خلافًا لذلك ، التزم بـ virtualenv .

venv هي الأداة الموصى بها في Python ، وهي ليست معطلة ، مثل virtualenv (إعادة: نسخ ملف python الثنائي ثم ينكسر عند تحديث python libs). الخطأ الذي ربطته يدور حول الجمع بين venv و virtualenv ، وهو ليس ما نطلبه؟

لسوء الحظ ، من الشائع جدًا أن تبني الأدوات على virtualenv. يستخدم Travis ، على سبيل المثال ، virtualenv لإنشاء بيئة بناء لك ، كما ذكر المراسل الأصلي. إنه أيضًا أساس Pipenv ، والذي إذا كان أحد الطرق الموصى بها لتثبيت Pipenv. إذا كان venv لا يعمل بشكل جيد بداخله. إنه موجود في الكثير من الأماكن دون علمك. سوف ينكسر دعم Venv إلى النصف وسوف يعضك بطرق غير متوقعة إذا لم يكن يعمل بشكل جيد مع virtualenv.

أنا أفهم ذلك ، ولكن في هذه المرحلة يوصى بـ Pipenv ، ويوصى باستخدام venv ، وهما في حالة تعارض نوعًا ما. انها حالة غريبة جدا.

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

ربما لن يكون من الجنون إبقاء هذه المشكلة مفتوحة بعد ذلك؟

هذه مشكلة بيو وليست مشكلة بيبينف.

إن venv ليس جيدًا بما يكفي لتحقيق ذلك. إذا كنت مهتمًا بهذا الأمر حقًا ، فتوجه إلى متتبع أخطاء Python وساعده.

انها ليست مشكلة venv ، ولكن virtualenv. لقد قمت بنشر بعض الشرح تحت تعقب المشكلة.
ccuranusjr

هناك كلمة حول ->
استخدم venv لإنشاء virtualenv أولاً ، ثم قم بتشغيل pipenv install . فمثلا:

mkdir -p /tmp/try
cd /tmp/try
python3 -m venv .venv
pipenv --venv  # /tmp/try/.venv
pipenv install xxx

🙈

مجرد ملاحظة:

يعمل الحل أعلاه في الغالب ، ولكن فشل pipenv run ... لأنه لا يوجد activate_this.py تحت .venv/bin . إذا تم تصديق العدد 21496 ، فلا توجد خطة لإضافة هذا الملف إلى venv. لذا ، حتى إذا تم إصلاح هذا الأمر من قبل pew ، فمن المحتمل أن لا تزال هناك مشكلة في pipenv.

باستخدام Virtualenv ، يعد استخدام وحدة نظام tk في نظام macOS أمرًا مستحيلًا. لكن باستخدام venv ، هذا ممكن.
أريد بشدة استخدام venv مع pipenv (قد يكون اختياريًا).

أنظر أيضا: # 1416

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

(حاولت أنا وكينيث وربما إيرين ونيت أيضًا القيام بذلك باستخدام venv في وقت مبكر جدًا من المشروع وفشلت أيضًا بسبب أسباب التوافق)

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

أود أن أوضح سببًا آخر يجعل من المحتمل أن يكون venv خيارًا أفضل من virtualenv:

أحد الجوانب الأكثر قبحًا في تطبيق virtualenv هو أنه يجب أن يكون لديه نسخته الخاصة من وحدة الموقع ، والتي تُستخدم لجميع Virtualenvs بغض النظر عن إصدار Python الذي تم إنشاؤه باستخدامه.
- من https://github.com/pypa/virtualenv/issues/228#issuecomment -4165148

هذا يعني ، على سبيل المثال ، أن rlcompleter معطل افتراضيًا وهذا خسارة كبيرة في سهولة الاستخدام في رأيي.

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

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

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

techalchemy إذا فهمت بشكل صحيح ، فإن pypa / virtualenv # 1095 هو المكان الصحيح لمناقشة هذا الأمر؟

يبدو صحيحًا ، لقد رأيت أن السم لديه حل بديل ، لذلك ربما ينجح ذلك إذا استدار شخص ما

بيو! يا له من مناقشة .. إذا لم يكن هذا الشيء مهمًا ، فهل سيكون من الممكن إسقاطها تمامًا مع Virtualenv والسماح لـ pipenv و venv و python بالعمل جنبًا إلى جنب ، حيث يوصون جميعًا ببعضهم البعض؟

إدارة التبعية / حلول البيئة الافتراضية للبيثون هي الكثير من التضاريس البرية في الوقت الحالي ، ويجب تقديم بعض التضحيات ، imho.

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

doganmeh يمكننا التخلي عن Virtualenv تمامًا ، وبناء منتج مكافئ لدعم Python 3.3 أو أعلى فقط ، ولكن أعتقد أنه سيكون من الأسهل إنشاء هذا المشروع الآخر.

مجرد ملاحظة:

يعمل الحل أعلاه في الغالب ، ولكن فشل pipenv run ... لأنه لا يوجد activate_this.py تحت .venv/bin . إذا تم تصديق العدد 21496 ، فلا توجد خطة لإضافة هذا الملف إلى venv. لذا ، حتى إذا تم إصلاح هذا الأمر من قبل pew ، فمن المحتمل أن لا تزال هناك مشكلة في pipenv.

هل ذلك ضروري؟ بمجرد إنشاء بيئة افتراضية باستخدام venv ، لن تحتاج إلى تنشيطها لاستخدامها. يمكنك ببساطة تشغيل باستخدام ملف Python الثنائي من دليل venv / bin.

FWIW ، هذا مرتبط (وما جلبني هنا): http://matplotlib.org/faq/osx_framework.html

في virtualenv ، يتم استخدام بنية غير إطار حتى عندما يتم إنشاء البيئة من بنية إطار ( خطأ في virtualenv # 54 ، خطأ في virtualenv # 609 ).

الحل هو عدم استخدام virtualenv ، ولكن بدلا من ذلك stdlib's venv ، والذي يوفر وظائف مماثلة ولكن دون إظهار هذه المشكلة.

لا يبدو إسقاط دعم Python 2.7 / virtualenv لي كفكرة رهيبة بشكل خاص ، إذا كان يسمح لـ pipenv بالاعتماد على stdlib لإصدار Python الذي لن ينتهي دعمه على وشك الانتهاء. طالما أنه لن يفسد أي جزء آخر من سلسلة الأدوات pipenv التي لا يمكن إصلاحها بسهولة للمشرفين. ربما حتى نقل 2.7 دعم إلى فرع / حزمة منفصلة؟

أود أن أكون قادرًا على المساهمة في الكود الفعلي ، لكنني لا أعتقد أن لدي الخبرة اللازمة للقيام بذلك أو الوقت: عبوس: أفضل ما يمكنني فعله هو إضافة إلى المناقشة في الوقت الحالي.

أضف صوتي هنا. لقد أصبت بهذا بسبب نفس المشكلة مثل

ألجأ حاليًا إلى تجاهل pipenv تمامًا لهذا المشروع عندما يكون على جهاز Mac الخاص بي ، وجعل البيئة يدويًا مع venv في الوقت الحالي.

+1 لاستخدام venv.
Virtualenv لديها العديد من أخطاء wontfix .
pipenv مفيدة تمامًا على نظام التشغيل Windows 10 مع Python 3.7 من متجر Windows ( خطأ في Virtualenv

ينتقل Virtualenv إلى نموذج venv - راجع https://github.com/pypa/virtualenv/issues/1366 ، الذي سيولد pyvenv.cfg وجميع الأشياء الجيدة ، لذلك يجب حل ذلك من خلال ذلك.

---------- الرسالة المعاد توجيهها ---------
من: Dan Ryan [email protected]
التاريخ: الاثنين ، 26 نوفمبر ، 2018 ، 2:39 مساءً
الموضوع: Re: [pypa / pipenv] استخدم venv بدلاً من virtualenv إذا كان متاحًا (# 15)
إلى: pypa / pipenv [email protected]
نسخة إلى: اكتتبت [email protected]

يبدو صحيحًا ، لقد رأيت أن السم لديه حل بديل ، لذلك ربما ينجح ذلك إذا
شخص ما استدارها

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/pypa/pipenv/issues/15#issuecomment-441533872 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AqyQvrs-RNNTb1YhxaDCWDLpRxrZLKoxks5uy4ydgaJpZM4Lqk2f
.