Pipenv: [سؤال] كيف يتم التكامل مع setup.py؟

يجب أن تكون قادرًا على تحقيق ذلك باستخدام الكود أدناه. سيؤدي هذا إلى تحميل ملف Pipfile من مشروعك الحالي وإرجاع التبعيات في قائمة متوافقة مع Pip.

from pipenv.project import Project
from pipenv.utils import convert_deps_to_pip

pfile = Project(chdir=False).parsed_pipfile
requirements = convert_deps_to_pip(pfile['packages'], r=False)
test_requirements = convert_deps_to_pip(pfile['dev-packages'], r=False)

اشعل نحن الان اذا انت عندك اية اب اسئلة :)

ما ورد أعلاه مفيد للغاية. لقد واجهت مشكلات مع setup.py اعتمادًا على Pipenv الذي يتم تثبيته في Virtualenv قبل أن يتم تشغيل setup.py install (أو أي شيء آخر). الحلول الوحيدة لهذه المشكلة التي يمكنني التفكير فيها هي إما بيع Pipenv في مشروع ، والذي يبدو أقل من مثالي ، أو حتى اختراق setup.py بطريقة ما لتثبيت Pipenv قبل محاولة تشغيل الواردات from pipenv... ، والذي يبدو خاطئ - ظلم - يظلم. أي شخص لديه أي أفكار أو حلول أفضل من هذا؟

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

هل ستساعد إضافة pipenv إلى setup_requires ؟ يبدو أنه قد يكون من الضروري أيضًا إضافته إلى install_requires والذي يبدو أمرًا مؤسفًا.

لا تفعل هذا.

@ kennethreitz ماذا تقصد ب "هذا"؟ هل تقصد التكامل مع setup.py أم حل nateprewitt أم الاقتراحين الأخيرين؟

فكيف يعرف المستخدمون أنهم بحاجة إلى تثبيت pipenv؟

نظرًا لأن pipenv هي أداة تُستخدم لتثبيت الأشياء ، وليس العكس ، فلا يوجد سبب لطلبها في ملف setup.py. الشيء الذي يحذر منه كينيث هو استيراد pipenv في setup.py لأنه تطبيق cli ويمكن أن يسبب مشاكل.

في 17 تشرين الأول (أكتوبر) 2017 ، الساعة 9:37 صباحًا ، كتب Iddan Ahahronson [email protected] :

فكيف يعرف المستخدمون أنهم بحاجة إلى تثبيت pipenv؟

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

فكيف يمكنني استخدام رمز nateprewitt في setup.py؟

iddan : لقد حاولت حل مشكلة Pipenv bootstrapping فقط عن طريق بيع نسخة من Pipenv في هيكل مشروعي (https://github.com/elgertam/cookiecutter-pypackage/blob/master/٪7B٪7Bcookiecutter.project_slug٪7D ٪ 7D / setup.py). حتى الآن لم أواجه أي مشاكل ، على الرغم من أنني لا أستطيع أن أقول إن لدي الكثير من الفرص لاختبارها في موقف حيث أقوم بتثبيت حزمة باستخدام setup.py .

يمكنني أن أفهم سبب قلقنا بشأن عدم تشغيل CLI عند تحميل setup.py ، ولكن مما يمكنني قوله ، فإن الكود الذي أستخدمه (تم نسخه من منشورnateprewitt هنا) آمن إلى حد ما.

أعتقد أن هذا الاختراق لن يكون ضروريًا بعد الآن عندما يكون لدى pip عناصر داخلية كافية لفهم تنسيق ملف Pipfile.

iddan ، للتوضيح ، هذا الرمز هو فقط لتحويل تبعيات Pipfiles إلى تنسيق نمط طراز requirements.txt الذي ستقرأه النقطة. يبدو أن كينيث قد نقح شيئًا من المنشور الأصلي لكني لست متأكدًا مما هو.

الغرض من Pipenv هو أن يكون أداة لإدارة ونشر البيئة ، وليس للتوزيع مثل setup.py. نقترح بشدة توثيق استخدامك لملف Pipfile وربما الارتباط بـ pipenv.org للحصول على إرشادات التثبيت. تعامل مع هذه الطريقة بنفس الطريقة التي تتعامل بها مع النقطة ، فليس من المتوقع أن يقوم المستخدم بتثبيت النقطة في كل مرة يقوم فيها بتثبيت حزمة بايثون جديدة.

أنا أفهم ذلك تمامًا. ما لا أفهمه هو ما الذي تتوقع حدوثه عندما يقوم المستخدم بتنزيل حزمة باستخدام هذا البرنامج النصي ولم يتم تثبيت pipenv

nateprewitt ، إذا أردنا توزيع حزمة إذن (من خلال الوسائل المعتادة ، باستخدام pip ) ، يجب أن نحتفظ بنسخة من قائمة التبعية في setup.py أو requirements.txt ؟ كنت أتمنى أن أستخدم Pipfile كمصدر وحيد للحقيقة.

للتوضيح ، أفترض أن الكود في الرد الأول من المفترض أن يتم تشغيله كجزء من بناء ، بدلاً من استخدامه فعليًا في setup.py .

ما لم أكن مخطئًا ، الكود الموجود في https://github.com/kennethreitz/pipenv/issues/209#issuecomment -278185133 آمن للاستخدام إذا كنت تبني عجلة (= توزيع ثنائي) ، ولكن ليس إذا أنت تبني sdist (= مصدر توزيع).

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

باستخدام sdist ، يتم تشغيل setup.py فعليًا على جهاز التثبيت ولذا يجب أن يكون pipenv متاحًا هناك.

نعم بالتأكيد. tuukkamustonen ، حالة الاستخدام الخاصة بي هي sdist. نظرًا لأنني لا أرغب في مطالبة مستخدم الحزمة بتثبيت pipenv قبل تنفيذ pip install ، أفترض أنني عالق في اشتقاق install_requires خارج setup.py (أي يدويًا أو كجزء من بناء)؟

إذا كنت أقرأ بشكل صحيح ، فأنا أعتقد أن كينيث والمشرفين الآخرين لا يريدون منا أن نتعامل مع Pipenv على أنه تبعية للمشروع كما قد نفعل مع pytest ، أو حتى تبعية عادية للحزمة. من الناحية المثالية ، يبدو أنه يجب علينا تثبيت وتحديث Pipenv بنفس طريقة pip نفسها ، على سبيل المثال ، يتم تثبيت pip عند تثبيت Python أو عند virtualenv تم إنشاء

ومع ذلك ، ردد isobit أفكاري بأن Pipfile يجب أن يكون المصدر الوحيد للحقيقة. أستطيع أن أرى حالتين مقنعتين لتفضيل ملف Pipfile (وهناك حالات أخرى): أولاً ، يكون خط أنابيب CI / CD الذي يعتمد على Pipfile لإعداد بيئة الإنشاء أكثر قوة من حالة واحدة وفقًا للمتطلبات. وثانيًا ، قد يحاول أحد المساهمين بشكل أعمى تثبيت مشروع يستند إلى ملف Pipfile وقد يشعر بالإحباط إذا لم يعمل python setup.py install بالطريقة التي تتوقعها. بالنظر إلى أنه لا يوجد Pipenv أو Pipfile المدركين من أدوات Python القياسية حتى الآن ، وأن Pipenv هو بالفعل التطبيق المرجعي لـ Pipfile ، لدينا خيارات قليلة لحل المشكلة:

1) حدد في وثائق مشروعك أن مشروعك يعتمد على Pipenv . لا يزال بإمكانك الاعتماد على Pipenv في setup.py الخاص بك ، وسوف ينكسر هذا إذا لم يتم تثبيت Pipenv في بيئة Python الخاصة بك. بشكل ملموس ، سيتعين على المساهم في الكود الخاص بك تثبيت Pipenv يدويًا إلى virtualenv لتثبيت المشروع بـ setup.py .
2) لا يزال لديك setup.py يعتمد على requirements.txt ، والذي تقوم بإنشائه بشكل دوري بناءً على Pipfile . يظل هذا متوافقًا تمامًا مع pip و setuptools ، لكنه يتطلب أي مشرف لتوليد requirements.txt عندما يتم إنشاء المشروع ونشره. قد يكون الاختلاف المحتمل لهذا الأمر بالنسبة لخط أنابيب CI / CD لتحديث requirements.txt في وقت الإنشاء.
3) قم بتوريد نسخة من Pipenv إلى مشروع وقم بتسميتها باستخدام from _vendor.pipenv.project import Project... داخل setup.py . يمكن أن يكون أحد أشكال هذا هو الاستيراد من الإصدار المورّد فقط عند فشل الاستيراد العام.
4) خيار آخر لم يتم تقديمه هنا وأنا لست ذكيًا بما يكفي لأفكر فيه.

أنا شخصياً أستخدم (3) (انظر https://github.com/kennethreitz/pipenv/issues/209#issuecomment-300550425) حتى يصبح Pipfile أكثر من معيار مشترك ، وعند هذه النقطة لن يكون لدي أي من مشاريعي تعتمد على كود Pipenv مباشرة ، حيث يبدو من الواضح أن Pipenv تهدف إلى أن تكون أداة لإدارة Virtualenv على أساس Pipfile ، وليس بالضرورة مكتبة Pipfile نفسها.

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

لدي شعور بأن المشكلة هنا تنشأ من إساءة استخدام أصلية (IMO) لـ requirements.txt لتبدأ بها. هذا قليل من استخدام pipenv .

سأشير إلى هذه المقالة الرائعة من دونالد ستافت ، setup.py vs requirements.txt:
https://caremad.io/posts/2013/07/setup-vs-requirement/

TL ؛ DR (ولكن يجب أن تقرأ بالفعل ): الغرض setup.py install_requires هو تفصيل متطلبات (التبعيات) للحزمة. يجب استخدام requirements.txt (الذي سيتم استبداله بالسرد Pipfile / Pipfile.lock هنا) لسرد الحزم الدقيقة التي سيتم استخدامها لتلبية ما هو مطلوب ، بناءً على البيانات الوصفية من setup.py ، من أجل إنشاء بيئة قابلة لإعادة الإنتاج.
يشبه ملء install_requires من requirements.txt العودة إلى الخلف.

setup.py 's install_requires = / = requirements.txt (أو Pipfile / Pipfile.lock ).
يجب أن يكون Pipfile (أو بالأحرى Pipfile.lock ) المصدر الوحيد لحقيقة الحزم المراد تثبيتها في بيئة التطبيق.
يوفر setup.py 's install_requires البيانات الوصفية المستخدمة لإنشاء Pipfile.lock صالح.

أعتقد أن هذا هو المكان الذي يأتي منه الاحتكاك. آمل أن يكون منطقيا.

أحب هذا الرد كثيرًا يا فنسنت ، وأنا أوافق تمامًا على أن يكون Pipfile.lock بديلًا كاملاً (وأفضل) لـ requirements.txt .

بعد أن استخدمت Pipenv لبضعة أشهر الآن ، على الرغم من ذلك ، فإن استخدامي لـ Pipfile يقودني إلى الاعتقاد بأن install_requires مطابق تقريبًا لما يحدث في Pipfile . إذا كنت بحاجة إلى numpy ، فأنا pipenv install numpy وأدخل إدخال جديد في مجموعة Pipfile [packages] : numpy = "*" . بعبارة أخرى ، يختلف استخدامي تمامًا عن requirements.txt ، والذي اعتدت إنشاؤه قبل الالتزام باستخدام pip freeze > requirements.txt .

ربما تكون هذه مجرد طريقة غريبة أستخدم فيها Pipenv ، وسأعمل عكس الاتجاه (أقوم أيضًا بتثبيت Virtualenv الخاص بي في .venv/ داخل دليل المشروع ، لذا فأنا من Pythonista المارقة) ، حيث حالة يمكنني بسهولة الامتثال لاتفاقية مجتمع Python لوجود جدار فاصل بين setup.py و Pipfile | Pipfile.lock | requirements.txt .

ما الذي أفتقده هنا ،vphilippon؟

شكرا على المعلومات ، vilippon. ربما نتحدث عن هذا إلى الوراء ، يبدو أن ما نريده حقًا هو العكس - طريقة تستخدم دعامات مجردة من install_requires في ملف Pipfile الخاص بنا ، كما ذكر دونالد فيما يتعلق بـ -e . في requirements.txt . يبدو أنه كانت هناك مشكلة بالفعل حول ذلك (رقم 339) ، ولكن لا يبدو أنها تذهب إلى أي مكان.

هل هذا مشمول بالفعل من خلال بناء جملة Pipfile؟ لقد لاحظت للتو أن مكتبة الطلبات Pipfile تستخدم "e1839a8" = {path = ".", editable = true, extras=["socks"]} في قسم الحزم الخاصة بها. يظهر شيء مشابه في أمثلة Pipfile ، لكني لا أرى أي وثائق أخرى.

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

الآن ، دعنا نصل إلى هذا.

سأبدأ بهذا البيان elgertam :

[...] استخدامي لـ Pipfile يقودني إلى الاعتقاد بأن install_requires متطابقة تقريبًا مع ما هو موجود في ملف Pipfile. إذا كنت بحاجة إلى numpy ، فأنا أقوم بتثبيت numpy وأدخل إدخالًا جديدًا في مجموعة [حزم] Pipfile [...]

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

بعبارة أخرى ، يختلف استخدامي تمامًا عن requirements.txt ، والذي اعتدت إنشاؤه فقط قبل الالتزام باستخدام تجميد النقطة> متطلبات. txt.

من المثير للدهشة أن استخدامك لا يختلف كثيرًا إذا فكرت في الأمر:

• سير العمل السابق: pip install stuff -> pip freeze > requirements.txt -> feed install_requires من requirements.txt
• سير العمل الجديد (الذي تمت تجربته): تم تحديث pipenv install stuff -> Pipfile تلقائيًا -> محاولة إطعام install_requires بـ Pipfile .
• ما هي الفكرة المقصودة: إضافة أشياء إلى install_requires -> pipenv install -> تم تحديث البيئة و Pipfile.lock .

ولهذه الطريقة المقصودة للعمل ، فأنت تريد Pipfile تنص على أنك تريد تثبيت تطبيقك.
شيء مثل requests Pipfile مرتبط بواسطةisobit.

أو على سبيل المثال:

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[dev-packages]
pytest = ">=2.8.0"
tox = "*"

[packages]
"-e ." = "*"

إن مبلغك Pipfile هو لوصف بيئتك ، وليس تبعيات الحزمة. كما ترى ، فإن Pipfile أعلاه يحدد ما أريد تثبيته ، وهو الحزمة المحلية في وضع قابل للتحرير.

قد يبدو هذا "عديم الفائدة" إلى حد ما ، حيث يتم تشغيل كل شيء الآن بواسطة حزمة واحدة ، ولكن لنفترض أنك تريد تثبيت تطبيقك ، ولكن مع requests[security] ، لكنها ليست تبعية صارمة لتطبيقك ، فعل pipenv install requests[security] ، ثم:

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[dev-packages]
pytest = ">=2.8.0"
tox = "*"

[packages]
"-e ." = "*"
requests = { extras = ['security'] }

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

ما الذي أفتقده هنا ،vphilippon؟ لماذا [حزم] Pipfile مقيدة للغاية لاستخدامها في install_requires أو tests_require؟

إذا شرحت هذا جيدًا بما فيه الكفاية ، يمكنك أن ترى أنه من المفترض أن يكون العكس.
تضع تبعياتك في install_requires $ ، وتضع الحزمة في Pipfile ، ثم تحصل على البيئة ، مع Pipfile.lock للتكاثر (حيث ستحل وتحترم الخاص بك تبعيات الحزمة).

بالنسبة إلى test_require ، سأعترف أنني لست متأكدًا من أن هذا يناسب كل هذا. IIRC ، إنها ميزة خاصة بـ setuptools . يمكننا القول إنها مجموعة من التبعيات المجردة للاختبار ، ونتوقع pipenv لحلها وتثبيتها ثم القيام بـ pipenv install --dev ، لجميع الحزم ، لكن لدي شعور بأن هذا ليس صحيحًا تمامًا. ليس لدي فكرة أو رأي واضح حول هذا والأساس المنطقي حوله ، آسف.

آمل أن يكون كل هذا منطقيًا بطريقة ما.

vphilippon لقد شرحت الأمر جيدًا ، وأعتقد أنك أقنعتني.

TL ؛ DR: حدد الملخص ، التبعيات الضرورية للغاية في setup.py ، ثم أضف السياق (وبالتالي الدقة) في Pipfile و Pipfile.lock ، بما في ذلك "-e ." = "*" الرائع دخول

هناك مشكلة في https://github.com/kennethreitz/pipenv/issues/209#issuecomment -337409290 وهي أنه عندما نريد نشر تطبيقنا على خادم ، فإننا لا نحصل على بيئة قابلة لإعادة الإنتاج.

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

(لا يعد التصريح عن الإصدارات الدقيقة من التبعيات متعدية الخيارات يدويًا - الطريقة مرهقة للغاية.)

في حالة الاستخدام هذه ، يجب أن نعتمد على ملف قفل النمط requirements.txt (الذي يحدد الإصدارات الدقيقة حتى للتبعيات متعدية). ومع ذلك ، لا يبدو كما لو أن pipenv يسمح باستبعاد متطلبات التطوير في pipenv lock -r (على سبيل المثال pipenv lock --no-dev -r ) ، حتى نتمكن من صياغة مثل requirements.txt (يمكن أن يكون ذلك بعد ذلك قراءة إلى install_requires )؟

سأقتبس مقال دونالد ستافت:

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

بمعنى آخر: التطبيق ليس الحزمة. التطبيق هو البيئة ، مع تثبيت مجموعة من التبعيات الملموسة. يجب تمثيل تبعيات التطبيق بـ requirements.txt (أو Pipfile / Pipfile.lock ) ، وليس بحزمة واحدة install_requires .

شخصيًا ، سأذهب إلى حد القول إن المجموعة الكاملة من التبعيات المثبتة (بما في ذلك التبعيات المتعدية) يجب أن تكون في requirements.txt للتطبيق ، وليس في الحزمة setup.py . يوضح هذا فكرة أن نشر التطبيق لا يتم باستخدام pip install myapp==1.0.0 ، بل pip install -r requirements.txt (أو pipenv install مع Pipfile.lock ) ، حيث requirements.txt يتضمن myapp==1.0.0 بالإضافة إلى كل التبعيات الأخرى والتبعيات المتعدية المثبتة.
قد يبدو أنني أذهب بعيدًا بعض الشيء ، لكنني عملت في سياق يتم فيه نشر "التطبيق" بواسطة مجموعة من الحزم. لا توجد حزمة واحدة تمثل التطبيق نفسه ، لذا فإن فكرة أن "الحزمة ليست التطبيق" ظهرت في وجهي مبكرًا 😄.

لدي شعور قوي بأن Pipenv / Pipfile / Pipfile.lock يتبع هذه الفكرة.
لهذا السبب يبدو أن هناك فجوة للانتقال من Pipfile.lock إلى setup.py s install_requires : ليس من المفترض أن يتم ذلك بهذه الطريقة في أي حال.

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

vphilippon أعتقد أن هناك وجهات نظر ومصطلحات مختلفة. لكن في النهاية ، نريد قائمة من التبعيات المثبتة لتثبيتها. لذا فإن requirements.txt بإصدارات مثبتة (أو حزمة بها تبعيات معلنة لا تهم حقًا). السؤال هو ، كيف تصنع مثل هذا الملف بالفعل؟

باستخدام pip-compile (من أدوات النقطة ) ، يمكنني تجميع مثل requirements.txt من requirements.in وسيحتوي فقط على التبعيات غير التطويرية التي يحتاجها تطبيقي. لست متأكدًا مما إذا كنت أقوم بتفسير إجابتك بشكل صحيح - هل تقصد حقًا أننا يجب أن نحافظ على تبعيات مثبتة requirements.txt يدويًا (أيضًا تكرار ما هو موجود بالفعل بالفعل في setup.py ) ، أيضًا لـ التبعيات متعدية؟ لا يمكن أن يكون هذا هو الحل ...

إذا كان هناك pipenv lock --no-dev -r ، أعتقد أن هذا سيحل هذه المشكلة.

tuukkamustonen آسف للارتباك ، كنت أتحدث فقط عن فكرة install_requires مقابل requirements.txt / Pipfile / Pipfile.lock .

لذلك لا يهم ملف requirements.txt مع الإصدارات المثبتة (أو الحزمة التي تحتوي على مثل هذه التبعيات المعلنة).

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

ومع ذلك ، لا يبدو كما لو أن pipenv يسمح باستبعاد متطلبات التطوير في pipenv lock -r

لكن في النهاية ، نريد قائمة من التبعيات المثبتة لتثبيتها. [...] السؤال هو ، كيف تصنع مثل هذا الملف؟ [...] باستخدام تجميع النقاط (لأدوات النقطة) ، يمكنني تجميع متطلبات .txt من المتطلبات ، وستحتوي فقط على التبعيات غير المتعلقة بتطوير البرامج التي يحتاجها تطبيقي.

آه ، لقد تخطيت هذا الجزء في البداية ، آسف. ويبدو أنك على حق: لست قادرًا على إيجاد طريقة لأقول pipenv install --not-dev-stuff (كنت متأكدًا تمامًا من وجود واحد ، رغم ذلك ، غريب) ، وإنشاء بيئة غير مطورة. ما الفائدة من وجود قسمين منفصلين إذن؟ قد أفتقد شيئًا ما الآن ، وهذا لا علاقة له باستخدام setup.py . ربما يستحق المناقشة في عدد جديد.

تعديل:
لقد ارتكبت خطأ هنا. لم أجد بالفعل طريقة لتوليد Pipfile.lock بدون حزم مطور ، ولكن في بيئة جديدة ، مع Pipfile / Pipfile.lock ، أداء pipenv install لا يقوم بتثبيت حزم المطورين. هذا لا يحل نقطة tuukkamustonen ، لكنني كنت مخطئًا عندما قلت إنه لا توجد طريقة لتثبيت "بيئة prod" ، خطأي.

Phew ، كان هذا كثيرًا للحاق به.

ما لم أكن مخطئًا بشكل سيئ ، فإن الكود الموجود في # 209 (تعليق) آمن للاستخدام إذا كنت تقوم ببناء عجلة (= توزيع ثنائي) ، ولكن ليس إذا كنت تقوم ببناء sdist (= مصدر توزيع).

tuukkamustonen هذا مخصص للاستخدام فقط في برنامج نصي مستقل لعمليات النشر ، ولا تقم بتضمينه في ملف setup.py. هذا حل شبه متطفل من قبل كان لدينا pipenv lock -r ، منذ عدة أشهر. ستعمل هذه الطريقة مع حالة استخدامك لتقسيم packages و dev-packages بالرغم من ذلك.

أنا شخصياً أستخدم (3) (انظر # 209 (تعليق)) حتى يصبح Pipfile أكثر من معيار مشترك ، وعند هذه النقطة لن يكون لدي أي من مشاريعي يعتمد على كود Pipenv مباشرة ، حيث يبدو أن Pipenv يعني بوضوح أن يكون أداة لإدارة virtualenv على أساس Pipfile ، وليس بالضرورة مكتبة Pipfile نفسها.

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

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

أعتقد أنك تتماشى جيدًا مع رؤيتنا لطول المشروع. شكرًا لتجميع كل هذا وتوضيحه جيدًاvphilippon!

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

لقد تابعت باقتراح ملموس في https://github.com/pypa/pipfile/issues/98 أعتقد أنه يمنحنا شيئًا عمليًا وعمليًا يمكن أن يحسن DX للحفاظ على مكتبات Python.

أفكار؟

import json, jmespath

install_requires = []
with open('Pipfile.lock') as f:
    context = json.loads(f.read())
    install_requires.extend(map(
        lambda n, v : n + v,
        jmespath.search('default | keys(@)', context),
        jmespath.search('default.*.version', context),
    ))

setup(
    name='foobar',
    packages=find_packages(),
    setup_requires=['jmespath'],
    install_requires=install_requires,
)

cornfeedhobo ما أفهمه هو أن setup_requires لا تعمل بشكل جيد مع النقطة. هل يمكنك أن تشرح قليلاً كيف تقترح استخدام هذه العينة؟

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

لقد ذكرت هذا في مشكلة أخرى ، لكن لا يمكنني تحديد موقعه على أجهزة الصراف الآلي (هناك الكثير من المناقشات المكررة في جميع أنحاء أداة تعقب المشكلات ، ومن المستحيل العثور على أي شيء بعد الآن) ، لذلك سأقولها مرة أخرى: من فضلك لا تضع أي شيء غير مبني- في داخل setup.py ما لم تقدم احتياطيًا مناسبًا ، أو لديك سبب وجيه. الحزمة التي تحتوي على setup.py أعلاه لن تعمل حتى مع Pipenv مع تثبيت jmespath في virtualenv ؛ يستدعي Pipenv setup.py egg_info في بيئة نظيفة ، وسيفشل في تنفيذ استيراد jmespath. هذه ممارسة سيئة. من فضلك تجنب ذلك.

epot لم أكن على علم بذلك

uranusjr شكرًا على الإجابة المدروسة بالتفاصيل. أنا فقط أقوم باستكشاف هذه المشكلة برمتها ، لذلك قد أعود لمزيد من الإحراج. أنا أيضًا أتتبع pypa / pipfile # 98

ماذا لو لم نطلب jmespath ؟

import json


install_requires = []
tests_require = []

with open('Pipfile.lock') as fd:
    lock_data = json.load(fd)
    install_requires = [
        package_name + package_data['version']
        for package_name, package_data in lock_data['default'].items()
    ]
    tests_require = [
        package_name + package_data['version']
        for package_name, package_data in lock_data['develop'].items()
    ]

mschwager لا تريد تثبيت الإصدار ، وإلا سيواجه المستخدمون صعوبة. # 1921 هو مثال لمكتبة تستخدم == وينتهي بها الأمر إلى تحطيم بنية المستخدم.

اعتذاري ولكن ما الفرق بين استخدام setup.py لاستخدامه كحزمة أو requirements.txt / Pipfile لإدارة تبعيات الحزمة المذكورة؟ يجب أن تكون المستندات المطلوبة متطابقة بين setup.py و requirements.txt / Pipfile أليس كذلك؟ لذلك لا يوجد سبب لعدم دمج Pipfile . يوزع $ setup.py بالفعل requirements.txt . لماذا لا يكون قادرًا على تحليل Pipfile ؟

سيكون من الرائع التخلص من requirements.txt واستخدم فقط Pipfile

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

ومع ذلك ، هناك بالفعل أسباب تجعلها متطابقة. Pipenv لا يستبعد ذلك. إنه خارج النطاق فقط ، ولا يدعمه هذا المشروع. يمكنك إنشاء مكتبة بالكامل لدعم ذلك ، والاستفادة من PEP 518 ، الذي يتم تضمينه في نقطة 10.0 ، لتوفير دعم وقت البناء.

كما قلت ، لا يوجد سبب لعدم السماح لـ setup.py بتحليل ملف Pipfile. أتطلع إلى تحقيق ذلك :)

افهم أن بعض الناس يحبون اللقطات المجردة لـ setup.py ولكن هذا ليس ضروريًا؟ أعني أن golang يعاني من متطلبات ملموسة فقط ولكن لا يزال قادرًا على استبدال lib المطلوب بشوكة خاصة بك فقط لأنه يتطابق مع الاسم؟ من المفهوم أن setup.py intergation ليس فقط في النطاق.

ومع ذلك ، سيكون من المثير للاهتمام معرفة ماهية خارطة الطريق طويلة المدى لـ pipenv. سيكون من الرائع رؤيتها تصبح أداة الانتقال في بيثون. على سبيل المثال ، يستبدل setup.py بطريقة أو بأخرى أو يُنشئ setup.py مناسبًا للمستخدم ، وفي كلتا الحالتين يكون pipenv مدير الحزم أمرًا رائعًا. فقط أتساءل عما إذا كانت هناك إمكانية لتوسيع النطاق ليشمل setup.py؟

إذا كانت pipenv مثل npm وما إلى ذلك ، فإن package.json الخاصة بهم تسمح بالتثبيت عن بُعد ، ولا يوجد سبب لعدم قدرة pipenv على التفاعل أو استبدال setup.py ، مما يجعلها في النطاق. هل أنا منطقي أم يبدو أنني أتناول حبوباً مجنونة؟

شكرًا لك على التفكير في أنه أمر لا بد منه. نظرًا لأنك تعتبره أمرًا بالغ الأهمية ، أعتقد أننا سنكون قادرين على تشغيل نظام بناء قائم على Pipfile في أي وقت من الأوقات.