Werkzeug: تم استدعاء Windows console_scripts من أداة إعادة التحميل

هل هناك مثال صغير يمكنني استخدامه لإعادة إنتاج هذا؟ لست معتادًا على استخدام Apistar ولا أستخدم Windows بانتظام.

لقد حفرت فيه قليلا. المشكلة هي في الواقع مع _get_args_for_reloading () . ترجع هذه الطريقة قيم تساوي ['python.exe', 'apistar.exe', 'run'] والتي عند تمريرها إلى subprocess.call() تولد هذا الخطأ. لا يختلف الأمر عن استدعاء python.exe apistar.exe run من سطر الأوامر.

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

أنا أقوم بتغيير عنوان الإصدار لحساب هذا.

إذا تم التخلص من هذه الطريقة من عنصر sys.executable لـ rv ضمن التحقق من windows ، فإن إعادة التحميل تكون ناجحة:

def _get_args_for_reloading():
    """Returns the executable. This contains a workaround for windows
    if the executable is incorrectly reported to not have the .exe
    extension which can cause bugs on reloading.
    """
    rv = [sys.executable]
    py_script = sys.argv[0]
    if os.name == 'nt' and not os.path.exists(py_script) and \
       os.path.exists(py_script + '.exe'):
        py_script += '.exe'
        rv.pop()
    rv.append(py_script)
    rv.extend(sys.argv[1:])
    return rv

يسعدني مراجعة العلاقات العامة إذا كنت تريد إرسال واحدة.

أود بالتأكيد ذلك ، لكنني عالق قليلاً في كتابة اختبار لهذا. يمكنني فقط رؤية هذا العمل مع مكتبة unittest.mock وترقيع sys.executable و os.name ، لكنني أفترض أن هذا لن يعمل مع مشروعك لأنه يجب أن يدعم الاختبار الآلي في 27 أيضًا. اي نصيحه؟

أيضا ما هي استراتيجية التفريع المستخدمة هنا؟ هل طلبات السحب للمشكلات تتعارض مع فرع الصيانة الحالي؟

يمكنك التفرع من 0.12 صيانة. دعونا نرى كيف يبدو التصحيح أولاً ثم اكتشف الاختبار.

لقد قدمت طلب سحب. يبدو أن Travis CI يفشل لأسباب لا علاقة لها بالتغييرات التي أجريتها. هذا هو أول طلب سحب لي لذا لا أعرف إلى أين أذهب من هنا.

سيحدث هذا عندما يكون لديك setuptools تثبيت قاذفات exe. إذا قمت بالتثبيت عبر نقطة - محدثة - فإنها تقوم بتثبيت نوع جديد من قاذفات exe (من distlib ) التي تجمع نص المشغل في ملف exe داخل ملف مضغوط والذي يمكن لبايثون تنفيذه مباشرة ( مستندات runpy ).

هذا لا يعني أنه لا ينبغي إصلاح هذا ، ولكن من المفيد أن تعرف في حالة عدم قدرتك على إعادة إنتاج هذا. سيستمر حدوث ذلك إذا قمت بتثبيت Flask في وضع التطوير ( pip install -e ) على سبيل المثال.

davidismandroiddrew أي تحديث على هذا PR؟

segevfiner هل يمكنك إضافة المزيد من التفاصيل إلى تعليقك الأخير؟ هل تقترح أنه ينبغي علينا على الأرجح إصلاح السبب الجذري في setuptools على عكس Flask؟

ewpete السبب الأساسي هو أنه عند استخدام برنامج setuptools الذي تم إنشاؤه ،
الملف sys.argv [0] غير قابل للتنفيذ كبرنامج نصي لبايثون لأنه ملف
قاذفة إكس. يتم تسمية النص الفعلي مثل exe مع - "-script"
الملحق وتحميل exe وتشغيله.

هل لاحظ أنه يمكن تنفيذ exe مباشرة (وكذلك نص Python
مع shebang الذي أعتقد أنه ما يولده setuptools على الوحدات). ولكن
لا يمكن الاعتماد على القيام بذلك من أجل نصوص Python النصية العادية على Windows (عندما يكون ملف
pylauncher غير مثبت) ، حيث سيتم إطلاقه مع Python التعريفي
المرتبط بملفات .py في التسجيل ، والتي قد تكون مختلفة
من Python الحالية التي نستخدمها. وبطبيعة الحال ، ينطبق الأمر نفسه على
أي نص عشوائي من Python قد يتم استدعاؤنا منه ، والذي قد لا يكون كذلك
تنفيذ.

يتم تثبيت pip بدلاً من ذلك (عبر distlib) نوعًا جديدًا من مشغلات exe التي تحتوي على امتداد
تم إلحاق نص المشغل الذي تم إنشاؤه داخل ملف مضغوط في نهاية ملف
تنفيذ. سيتم الكشف عن هذا كملف zip مع نص برمجي __main__.py (A
zipapp) ويمكن تمريره مباشرة إلى Python للتنفيذ.

لإصلاح هذا الأمر في setuptools سيعني إنشاء نفس النوع / نفس النوع
قاذفات في setuptools. وبروح http://xkcd.com/1172/ هذا
من المحتمل أن يكسر الكود الذي يتوقع قاذفات setuptools ويحاول
باستخدام ملفات "* -script.py" لحل المشكلة. لم أتحقق
ما إذا كان هناك مشكلة / العلاقات العامة حول هذا بالفعل.

ربما يكون من الجيد أن يكون لديك حل بسيط هنا حتى Werkzeug
معيد التحميل يعمل حتى في وجود النمط الحالي لأدوات الإعداد
قاذفات. لكن هذا حقًا متروك لمسؤولي المشروع.

בתאריך 28 בנוב '2017 20:46 "ewpete" [email protected] כתב:

androiddrew https://github.com/androiddrew davidism
https://github.com/davidism أي تحديث على هذه العلاقات العامة؟

segevfiner https://github.com/segevfiner هل يمكنك إضافة المزيد
التفاصيل لتعليقك الأخير؟ هل تقترح أن علينا ذلك
ربما إصلاح السبب الجذري في setuptools مقابل في Flask؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/pallets/werkzeug/issues/1136#issuecomment-347623921 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AXlg_8OSR3NdbPJzM87dyKPUAA9NpXJ6ks5s7FT7gaJpZM4N5Fcb
.ال

ewpete كان هذا أول

لدي وقت محدود للغاية عبر مشاريع متعددة. لا تقلق ، لم أنس هذا.

davidism شكرًا لك ، ليس فقط على الاستجابة ولكن على العمل الجيد لإبقاء هذه المشاريع حية!

في حين أن هذا لم يتم دمجه بعد ، فإن أحد الحلول المؤقتة المحتملة هو monkeypatch وظيفة _get_args_for_reloading() مكان ما قبل استخدامها. في حالة وجود برنامج Flask النصي ، فإن إضافة هذا في مكان ما في بداية ملف manage.py يساعد على:

import werkzeug._reloader
import os, sys

def _get_args_for_reloading():
    rv = [sys.executable]
    py_script = sys.argv[0]
    if os.name == 'nt' and not os.path.exists(py_script) and \
       os.path.exists(py_script + '.exe'):
        py_script += '.exe'
    if os.path.splitext(rv[0])[1] == '.exe' and os.path.splitext(py_script)[1] == '.exe':
        rv.pop()
    rv.append(py_script)
    rv.extend(sys.argv[1:])
    return rv
werkzeug._reloader._get_args_for_reloading = _get_args_for_reloading