Pipenv: كيف يعرف Pipenv Virtualenv للمشروع الحالي؟

اسم virtualenv هو اسم الدليل الجذر للمشروع ، بالإضافة إلى تجزئة المسار الكامل إلى جذر المشروع. هذا يضمن أن يكون الاسم فريدًا ويمكن التنبؤ به طالما أنك لا تنقل المشروع. (AFAICT هذا منطق إنشاء الاسم هو تفاصيل تنفيذ لا ينبغي الاعتماد عليها.)

لتثبيت إصدار معين من الحزمة ، استخدم نفس الصيغة كما تفعل مع النقطة و requirements.txt ، على سبيل المثال pipenv install django==1.11.0 .

uranusjr هذا يعني أنه إذا قمت بإعادة تسمية الدليل ، فسيتم فقد virtualenv لمشروعي. هذا سيء. يمكن أن تكون إعادة تسمية دليل حالة استخدام شائعة وقد يقع المستخدمون في هذا الأمر ويتساءلون كيف توقفت بيئتهم عن العمل.

أود أن أقترح إصلاحه وإدخال Pipfile إذا كان ذلك ممكنًا. أو قم بإنشاء ملف .pipenv آخر لتخزين هذه البيانات الوصفية في كل دليل مشروع.

ماذا تقترح ؟

شكرا للإجابة على كلا السؤالين!

مرحبًا @ sachinjain024 ، لقد أجرينا بعض المناقشات حول ملف البيانات الوصفية المحلي ولكن إجماع المشرف كان على أن pipenv لن يدعم ذلك في الوقت الحالي.

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

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

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

إذن ماذا علي أن أفعل في هذه الحالة؟

1. أعد ضبط البيئة لأن لدي Pipfile بالفعل يحتوي على معلومات الحزم لذلك سيكون من السهل إعادة ضبط البيئة.
2. بطريقة ما إعادة تسمية دليل virtualenv أيضا
3. ؟؟؟

ماذا تقترح في هذه الحالة؟ مجرد فضول في حال دخلت في هذا الموقف في المستقبل.

يمكنك استخدام pew cp لنسخ Virtualenv الحالي بسهولة ، ولكن أعتقد أن 1. ستكون الطريقة الأكثر "قانونية" للقيام بذلك.

@ sachinjain024 ، كلما احتجت إلى نقل دليل مشروعك ، ما عليك سوى تشغيل pipenv install للعودة إلى حالة العمل. سيؤدي هذا إلى إنشاء بيئة لك باستخدام التجزئة الجديدة وإعادة تثبيت كل شيء من ملف القفل بشكل مماثل إلى التثبيت السابق الذي تم إنشاؤه باستخدامه.

إذا وجدت نفسك تفعل هذا كثيرًا ، فقد تحتاج إلى استخدام pew rm old_project-a3de90 للتنظيف.

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

بفضلnateprewitturanusjr. إغلاق هذه التذكرة.

هذه واحدة من أسوأ الأفكار التي ظهرت من pipenv حتى الآن. هذا هو السبب:

أنا أعمل في شركة ، حيث يتم استخدام Python لاختبار أتمتة الكثير من المشاريع الداخلية. يعمل أحد المختبرين عادةً على عشرات من هؤلاء. حسب الاصطلاح ، فإن كل كود الاختبار لمشروع ما موجود في دليل يسمى tests . هذا يعني أن كل مختبِر لديه الآن مجموعة من البيئات الافتراضية تسمى جميعها شيئًا مثل ~/.local/share/virtualenvs/tests-hKjFddnZ - رائع! من الطبيعة البشرية أن تنسى تبديل البيئة الافتراضية ، لذلك ، كل بضعة أيام يتم استدعائي إلى محطة عمل مختلفة لأن الشخص في محطة العمل تلك يعتقد أنهم قاموا بتثبيت الحزمة التي يحتاجونها ، قاموا بتشغيل pipenv install ، لكن الواردات في الكود لا تعمل. ليس ذلك فحسب ، فالبيئات الافتراضية اليتيمة تتراكم بمرور الوقت ، ولكن نظرًا لأن جميعها لها أسماء غير موصوفة ، فلا توجد طريقة لمعرفة ما إذا كنت أقوم بحذف البيئة غير المستخدمة ، أو تلك التي تم استخدامها بالفعل. هذا يعني أنه في CI ، نقوم بإنشاء العشرات ، إن لم يكن المئات من البيئات الافتراضية يوميًا. لا توجد طريقة يمكن لأي شخص من خلالها تتبع البيئات التي لها أسماء عشوائية بشكل أساسي ، وهناك الكثير منها ، لذلك يتعين علينا حذفها جميعًا مرة واحدة على الأقل يوميًا. نحن ندفع ثمناً باهظاً في أوقات الانتظار فقط بسبب هذا القرار الفائق الذكاء الذي اتخذه pipenv وشخص في شركتنا قرر استخدامه ...

قم بتعيين export PIPENV_VENV_IN_PROJECT=1 في تهيئة bashrc / shell.
(أو قم بتغيير نصوص شل لإنشاء ملف venv على $ PROJECT / .venv ثم
سوف يكون لدى pipenv ذلك)
في يوم الإثنين ، 19 مارس 2018 ، الساعة 6:28 صباحًا ، كتب wvxvw [email protected] :

هذه واحدة من أسوأ الأفكار التي خرجت من بيبينف حتى الآن. هذا هو السبب:

أنا أعمل في شركة ، حيث يتم استخدام Python في الكثير من اختبارات التشغيل الآلي
مشاريع داخلية. يعمل أحد المختبرين عادةً على عشرات من هؤلاء. بواسطة
اصطلاحًا ، كل كود الاختبار لمشروع ما موجود في دليل يسمى الاختبارات.
هذا يعني أن كل مختبِر لديه الآن مجموعة من البيئات الافتراضية كلها
يسمى شيء مثل ~ / .local / share / virtualenvs / الاختبارات-hKjFddnZ -
مدهش! من الطبيعة البشرية أن تنسى تبديل البيئة الافتراضية ، لذلك ،
كل بضعة أيام يتم استدعائي إلى محطة عمل مختلفة لأن الشخص
في محطة العمل تلك يعتقدون أنهم قاموا بتثبيت الحزمة التي يحتاجونها ، فهم
تم تشغيل تثبيت pipenv ، لكن الواردات في الكود لا تعمل. ليس فقط
ذلك ، البيئات الافتراضية اليتيمة تتراكم بمرور الوقت ، ولكن منذ كل شيء
منها أسماء غير موصوفة ، ولا توجد طريقة لمعرفة ما إذا كنت أقوم بحذفها
البيئة غير المستخدمة ، أو تلك التي تم استخدامها بالفعل. هذه
يعني أنه في CI ، نقوم بإنشاء العشرات ، إن لم يكن المئات من البيئات الافتراضية
اليومي. لا توجد طريقة يمكن لأي شخص من خلالها تتبع البيئات التي لديها
أسماء عشوائية بشكل أساسي ، وهناك عدد كبير جدًا منهم ، لذا يتعين علينا ذلك
احذفها جميعًا مرة واحدة على الأقل يوميًا. ندفع ثمناً باهظاً في أوقات الانتظار
فقط بسبب هذا القرار الفائق الذكاء الذي اتخذه pipenv وشخص آخر
شركتنا التي قررت استخدامه ...

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

jtratner فلماذا أحتاج إلى pipenv إذا كنت سأقوم بإنشاء بيئة افتراضية يدويًا؟

البيئة الافتراضية هي جزء من العمل في حد ذاتها. إنه ضعيف في كل مكان ومتعطل على Windows (يفترض أنه في MS Windows ، من بين جميع الأماكن ، يسمى الدليل الرئيسي الافتراضي "~"). كنت آمل أنه إذا قام شخص ما بإعادة PIP والبيئة الافتراضية ، فإنهم ، كما تعلمون ، سيصلحون الأخطاء الواضحة لأسلافهم ... بدلاً من ذلك ، هناك هذه الفوضى تتضاعف بطبقة من عدم التوافق.

أنت تضع افتراضات خاطئة. لا يعيد Pipenv إما virtualenv أو pip. إنه يبني عليهم.

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

إعادة البيئة الافتراضية و PIP هو الهدف المعلن للمشروع.

أين قال أي شخص هذا؟

لقد وجدت أيضًا أن هذا السلوك غريب ، كنت أتوقع pipenv لاختيار اسم قياسي لدليل virtualenv ووضع الدليل في الدليل الحالي ، بشكل مماثل للطريقة التي يستخدمها npm node_modules .

Flimm export PIPENV_VENV_IN_PROJECT=1 . اقرأ الوثائق.

uranusjr لقد قرأت كل https://docs.pipenv.org و https://docs.pipenv.org/basics/ ، وما لم أفقدها ، فلن تذكر أبدًا مكان تثبيت الدلائل virtualenv ، كما أنه لا يحذر أي شخص من أن إعادة تسمية أو نقل دليل المشروع سيؤدي إلى إعادة إنشاء الدليل virtualenv .

PIPENV_VENV_IN_PROJECT مُربك ، نظرًا لأن pipenv لا يستخدم venv يتم شحنه في المكتبة القياسية ، فهو يستخدم virtualenv ، وهو مشروع مختلف.

أحاول فقط تقديم ملاحظات حول الأشياء التي تعثرت فيها لأنني أعرف نفسي بهذا المشروع.

Flimm الهدف هو تجريد هذه المعلومات. إذا كنت تعرف كيفية عمل الأدوات الأخرى التي تدير Virtualenvs ، فيجب أن تعلم بالفعل أن نقل مجلد virtualenvs يجعلها غير قابلة للبحث. إذا لم تكن مألوفًا ، فمن المحتمل أنك لن تبحث عن هذا في المقام الأول.

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

متغير البيئة متاح بسهولة في المستندات: http://pipenv.readthedocs.io/en/latest/advanced/#configuration -with-environment-variables لذا ربما لم تقرأها كلها إذا لم ترها هو - هي

techalchemy بواسطة أدوات أخرى أعتقد أنك تعني شيئًا مثل virtualenvwrapper . ذهبت لسنوات دون استخدام virtualenvwrapper . أعتقد أن عدد مطوري Python الذين هم على دراية بنمط Node / NPM node_modules أكبر من عدد مطوري Python الذين هم على دراية بـ virtualenvwrapper أو pipenv نمط إخفاء دليل البيئة. لكن هذا تخمين. بالنسبة لأولئك الذين ليسوا على دراية بأي من هذه الأدوات ، أعتقد أنه سيكون من المربك عدم معرفة مكان انتهاء الملفات المثبتة. لقد أشرت إلى أن هذا موضح فقط في القسم المتقدم من المستندات ضمن القسم الفرعي متغيرات البيئة ، وأعتقد أنه يجب شرحه في المستندات قبل ذلك بكثير. ربما سأقدم طلب سحب.

لقد علقت على الإشارة المربكة إلى venv بدلاً من virtualenv في تسمية PIPENV_VENV_IN_PROJECT في إصدار آخر # 1919. يكفي القول ، أنا لا أشغل المنصب الذي أعتقد أنك أشغله تمامًا.

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

أتفهم أن هذا هو الجمهور الخطأ ، ولكن بما أن هذه المناقشة مستمرة ... حسنًا ، لا أعتقد أن node_modules كان مصدر إلهام لـ pipenv ، وليس لـ virtualenv . قد يكون تخميني غير صحيح من الناحية التاريخية ، ولكن اضطراري للعمل مع كل من rbenv و virtualenv ، يمكنني أن أخبرك أن virtualenv يبدو وكأنه نسخة سيئة بدون فهم ، أو ربما يكون نموذجًا أوليًا مبكرًا ، تم تحسينه بمقدار rbenv . في كلتا الحالتين ، يعد virtualenv سهمًا مضحكًا مقارنة بـ rbenv ، وإليك السبب:

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

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

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

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

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

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

تحرير: فعلت بعض الحفر. تم إصدار الإصدار الأولي لـ Virtualenv ، 0.8 ، في عام 2007 ، والذي كان عام 2011 لـ rbenv (0.1) ، لذلك يفصل بينهما أربع سنوات ، وليس خمس سنوات.

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

حصلت على نفس المشكلة بعد تغيير مسار المشروع وفقدت رسم خرائط virtualenv الأصلي ، ثم قرأت هذا الموضوع. أولا ، أنا أقدر عمل فريق pipenv. لقد حصلت للتو على بعض الآراء التي أود مشاركتها حول هذه المناقشة:

1. يجب أن يشير المستند بالفعل إلى آلية التعيين بين مسار المشروع والبيئة ، على الأقل تحذير المستخدمين من أن changing project path would cause unmapping the original env .

2. هل سيكون من الأفضل إذا كان بإمكانك تعيين المسار يدويًا إلى البيئة المحيطة في ملف Pipfile؟ أعني أن الأشخاص قد يكون لديهم بعض المتطلبات الخاصة لاستخدام نفس البيئة يدويًا.

فقط ارائي للمشاركة معكم يا رفاق.

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

إذا كنت تريد استخدام بيئة متعددة لمشروع واحد ، فاستخدم السموم. استخدم pipenv لبيئة التطوير الرئيسية الخاصة بك ، والسموم لاختبار إصدار بيثون متعدد.

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

تضمين التغريدة
هذا هو المكان الذي يحدث فيه التجزئة؟

أنا أعمل في مشروع وأحتاج إلى حساب تجزئة المسار.

devxpy نعم ، بالضبط.

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

uranusjr ما سبب عدم قيام Pipenv بإنشاء Virtualenv افتراضيًا في دليل المشروع؟ بالطريقة التي أراها ، ستحل المشكلة مع البيئات المعزولة عند إعادة تسمية المشروع / نقله / حذفه. إلى جانب ذلك ، سيكون الأمر أقل إرباكًا للأشخاص الذين يتوقعون (عن حق إلى حد ما) أن تعمل مثل npm.

هل هناك فائدة من تفضيل هذا النهج على ربما التقاليد؟

ما عليك سوى إنشاء دليل .venv قبل أمر تثبيت pipenv. سيكون خيار venv أو —dot-venv لتثبيت pipenv موضع ترحيب ، في الواقع :)

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

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

ملاحظة هل أنت (أو أي شخص آخر) مهتم بكتابة إدخال أسئلة وأجوبة حول هذا الموضوع؟ من المحتمل أن يستغرق الأمر بضع فقرات ، ولكن سأكون أكثر من سعيد لشرح ما إذا كان شخص ما قد وعد بأخذ وقت لتلميع النص وتقديم العلاقات العامة.

uranusjr أنا أشعر بالفضول

ملاحظة: يمكنني كتابة إدخال في الأسئلة الشائعة إذا قمت بشرح سبب كون الأشياء على ما هي عليه. ؛)

بدءًا من 2018.10.9 ، هناك طريقة أخرى للقيام بذلك. يمكنك إضافة ملف .venv _file_ يحتوي على المسار إلى بيئتك الافتراضية. (ميزة جديدة متستر!)

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

ملاحظة هل أنت (أو أي شخص آخر) مهتم بكتابة إدخال أسئلة وأجوبة حول هذا الموضوع؟ من المحتمل أن يستغرق الأمر بضع فقرات ، ولكن سأكون أكثر من سعيد لشرح ما إذا كان شخص ما قد وعد بأخذ وقت لتلميع النص وتقديم العلاقات العامة.

يؤسفني الاصطدام ... لدي نفس هذه الحاجة لنقل مجلدات المشاريع التي تحتوي على بيئة افتراضية تم إنشاؤها باستخدام pipenv.

أقوم حاليًا بما يلي وليس لدي مشكلة على الإطلاق:

• أنقل مجلد المشروع أينما أريد
• في C: \ Users \ user \ .virtualenvs أحذف مجلد venv المرتبط بالمشروع الذي قمت بنقله للتو
• انتقل إلى موقع مجلد المشروع الجديد عبر cmd وقم بتشغيل تثبيت pipenv (أو pipenv shell ثم مزامنة pipenv)

كل شيء يعمل بشكل جيد. هل هذه ممارسة سيئة؟

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

ملاحظة: أنا أيضًا على استعداد لكتابة الأسئلة الشائعة

في الواقع ، أعتقد أن فكرة @ gioxc88 جيدة ، حيث يمكن لـ Virtualenv الذي تم إنشاؤه حديثًا إنشاء ملف .env تلقائيًا ضمن جذر المشروع ، ويحتوي على تكوينات env مثل PATH . سيجعل البيئة أكثر شفافية للمطورين وطريقة أكثر ملاءمة لإعادة التكوين.

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

تتمثل إحدى طرق التفكير في الأمر في التفكير في وضع مشروع في التحكم في الإصدار (على سبيل المثال Git). إذا تم إنشاء البيئة في جذر المشروع ، فمن الطبيعي أن تكون في جذر المستودع. من الواضح أن الأشخاص مثلي ومثلك ، الذين اعتادوا على هذا الإعداد ، يعرفون أنه يجب علينا إضافة قاعدة في .gitignore (أو تكوين التجاهل العام) لمنع تسجيل الوصول إلى الدليل .venv ، لكن لن يفعل ذلك المستخدم المطمئن ، ويمكنه بسهولة التحقق في البيئة عن طريق الصدفة. هذا ليس سيئًا فقط لإدارة المشروع ، ولكنه (والأهم من ذلك) يوفر ناقلًا للهجمات المحتملة من خلال الكشف عن المعلومات المحلية. لذلك ، فهي قاعدة عامة لأدوات إدارة المشروع لتجنب وضع الملفات التي تم إنشاؤها داخل دليل المشروع . قد يكون من الجيد (لا تزال غير مثالية IMO) للقيام بذلك إذا كنت تصمم نظامًا بيئيًا من البداية (على سبيل المثال NPM node_modules ) ، ولكن بالتأكيد ليست فكرة جيدة للأدوات التي تم إنشاؤها لنظام بيئي مع الممارسات الشائعة المعمول بها ، مثل حالة Pipenv.

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

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

مرحبا. بالنسبة لي ، فإن دليل .venv (الميزة القديمة) وملف .venv (ميزة جديدة) على ما يرام ، لكنني سأكون ممتنًا جدًا لوجود خيار في أمر تثبيت pipenv.

شيء مثل:

pipenv install

سيتم التثبيت في ~/.local/

pipenv install --venv

سيتم التثبيت في الدليل $PWD/.venv

pipenv install --venv-dir /my/custom-path

سيتم التثبيت في /my/custom-path .

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

uranusjr أشكركم على الإجابة المفصلة! فقط لإرضاء فضولي ، ما نوع المعلومات المحلية (التي يحتمل أن تكون حساسة) التي يمكن كشفها بواسطة فحص في python venv؟ أوافق على أنه أمر مزعج أن يتم تسجيل الوصول إلى node_modules ، ولكن عادةً لا يحتوي ذلك على أي معلومات محلية.

تحتوي بيئات Python الافتراضية على العديد من نصوص الصدف (مثل activate ). يقوم الكثير من الأشخاص بتعديلها لإضافة متغيرات البيئة لتحديد كلمات مرور قاعدة البيانات ، والمسار إلى ملف تكوين آخر ، وما إلى ذلك. يعد تعديل البرامج النصية في البيئات الافتراضية ضد أفضل الممارسات ، لكن الأشخاص يفعلون ذلك مع ذلك (واتخذ موقفًا دفاعيًا عندما تخبرهم بالتوقف عن القيام بذلك -خبرة شخصية).

أيضًا ، أنت محق ، ربما لا يحتوي node_modules على معلومات حساسة. هذه فائدة أخرى عندما تبني نظامًا بيئيًا من الصفر. لسوء الحظ ، تم اختراع بيئات Python الافتراضية قبل أن تصبح هذه مشكلة شائعة (في ذلك الوقت ، كنت بالفعل خبيرًا إذا كنت تستخدم VCS على الإطلاق).

لقد وصلت إلى هنا بينما كنت أحاول فهم كيفية معرفة pipenv للـ Virtualenv الصحيح:)

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

جميع صفحات التوثيق مفتوحة للمساهمة. لا تسأل عن الأشياء ، افعلها :)

انا سوف!

uranusjr هذا يعني أنه إذا قمت بإعادة تسمية الدليل ، فسيتم فقد virtualenv لمشروعي. هذا سيء. يمكن أن تكون إعادة تسمية دليل حالة استخدام شائعة وقد يقع المستخدمون في هذا الأمر ويتساءلون كيف توقفت بيئتهم عن العمل.

أود أن أقترح إصلاحه وإدخال Pipfile إذا كان ذلك ممكنًا. أو قم بإنشاء ملف .pipenv آخر لتخزين هذه البيانات الوصفية في كل دليل مشروع.

ماذا تقترح ؟

شكرا للإجابة على كلا السؤالين!

شكرا لطرحك كلا السؤالين. أنا أيضا أواجه نفس المشكلة ،

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

echo ${PATH_OBTAINED_FROM_PREVIOUS_COMMAND} > .venv في الدليل الصحيح ويجب أن يعمل بشكل صحيح.

لاحظت اليوم أنه إذا كان هناك ملف pipfile في الدليل الأصلي ، فإن pipenv يتجاهل المتغير البيئي export PIPENV_VENV_IN_PROJECT=1 ويقوم بتثبيت venv في الدليل الأصلي بدلاً من ذلك. هذا في الإصدار 2018.11.26 . إذا قمت بإزالة ملف الأنابيب من الدليل الأصلي ، فإن pipenv يعمل كما هو موثق.