Gunicorn: v20 मुद्दा: 'ऐप' में एप्लिकेशन ऑब्जेक्ट 'create_app ()' को खोजने में विफल

मैंने इस मुद्दे का भी अनुभव किया है, अर्थात
Failed to find application object 'create_app()' in 'app'
और संस्करण 19.9.0 पर पिन करने से समस्या हल हो जाती है।

मैं शुरू में हालांकि फिक्स को गनिकोर्न कमांड से बदलना था:
gunicorn --bind 0.0.0.0:$PORT app:create_app()
प्रति:
gunicorn --bind 0.0.0.0:$PORT app:create_app
(ध्यान दें कि create_app के बाद कोष्ठक अब चले गए हैं)। प्रारंभ में, सब ठीक लगता है:

वेबसाइट_1 | [२०१९-११-१० १९:१८:५४ +००००] [१] [जानकारी] २०.०.०
वेबसाइट_1 | [२०१९-११-१० १९:१८:५४ +००००] [१] [सूचना] यहां सुन रहा है: http://0.0.0.0 :8000 (1)
वेबसाइट_1 | [२०१९-११-१० १९:१८:५४ +००००] [१] [सूचना] कार्यकर्ता का उपयोग करना: सिंक
वेबसाइट_1 | [२०१९-११-१० १९:१८:५४ +००००] [११] [जानकारी] पीआईडी ​​के साथ बूटिंग कार्यकर्ता: ११

लेकिन अफसोस, यह केवल एक मृगतृष्णा है क्योंकि जब आप अपनी फ्लास्क वेबसाइट/एंडपॉइंट लोड करने का प्रयास करेंगे तो यह कहेगा:

[२०१९-११-१० १९:२०:२८ +००००] [११] [त्रुटि] अनुरोध को संभालने में त्रुटि /
वेबसाइट_1 | ट्रेसबैक (सबसे हालिया कॉल अंतिम):
वेबसाइट_1 | फ़ाइल "/usr/local/lib/python3.7/site-packages/gunicorn/workers/sync.py", लाइन 134, हैंडल में
वेबसाइट_1 | self.handle_request (श्रोता, अनुरोध, ग्राहक, addr)
वेबसाइट_1 | फ़ाइल "/usr/local/lib/python3.7/site-packages/gunicorn/workers/sync.py", लाइन 175, हैंडल_रेक्वेस्ट में
वेबसाइट_1 | रेस्पिटर = self.wsgi (पर्यावरण, resp.start_response)
वेबसाइट_1 | लेखन त्रुटि: create_app () 0 स्थितीय तर्क लेता है लेकिन 2 दिए गए थे

यह स्पष्ट रूप से गनिकोर्न संस्करण 20.0.0 के साथ एक समस्या है।

यह इस परिवर्तन से संबंधित होना चाहिए: https://github.com/benoitc/gunicorn/commit/3701ad9f26a7a4c0a081dfd0f6e97ecb272de515#diff -0b90f794c3e9742c45bf484505e3db8dR377 #2043 के माध्यम से।

इसे अपने पक्ष में ठीक करने का एक तरीका यह है कि आपने अपने मुख्य मॉड्यूल में myapp = create_app() का निर्यात किया है और दस app:myapp । यह काम करना चाहिए, अगर ऐसा नहीं होता है तो मुझे बताएं।

मैं देखूंगा कि वहां कुछ करने की जरूरत है या नहीं। @berkerpeksag eval को हटाने की आवश्यकता क्यों थी?

यह इस परिवर्तन से संबंधित होना चाहिए: 3701ad9#diff-0b90f794c3e9742c45bf484505e3db8dR377 #2043 के माध्यम से।

इसे अपने पक्ष में ठीक करने का एक तरीका यह है कि आपने अपने मुख्य मॉड्यूल में myapp = create_app() का निर्यात किया है और दस app:myapp । यह काम करना चाहिए, अगर ऐसा नहीं होता है तो मुझे बताएं।

मैं देखूंगा कि वहां कुछ करने की जरूरत है या नहीं। @berkerpeksag eval को हटाने की आवश्यकता क्यों थी?

मैंने अपने एप्लिकेशन में यह परिवर्तन किया है और क्रैशिंग को ठीक किया है, Gunicorn अब एक चर में create_app() के परिणाम को सहेजकर और इसे निर्यात करके मेरे एप्लिकेशन को चलाने में सक्षम है ताकि इसे मेरे Gunicorn रन कमांड में उपयोग किया जा सके

# app.py
def create_app():
    ...

my_app = create_app()

gunicorn "app:my_app" --workers 8

मैं पुष्टि कर सकता हूं कि @benoitc और @jrusso1020 ने ऊपर

लॉन्च के समय पैरामीटर पासिंग की आवश्यकता होने पर मुझे फिक्स काम नहीं दिख रहा है:

Gunicorn --chdir hcli_core path "hcli_ core:HCLI (" hcli_core sample hfm ").connector"।

पैरामीटर पासिंग 19.9.0 में काम करता है लेकिन 20.0.0 में विफल रहता है।

@benoitc अगर यह जानना उपयोगी है, तो फ्लास्क डॉक्स गनिकोर्न का उपयोग करते समय app:create_app() पैटर्न की सलाह देते हैं। मुझे संदेह है कि आपके कुछ नए उपयोगकर्ता पहले फ्लास्क ऐप्स बनाने के परिणामस्वरूप गनिकोर्न का प्रयास करेंगे, और वे उन दस्तावेज़ों से अब-टूटी हुई अनुशंसा का उपयोग करने का प्रयास करेंगे (यह मेरा अनुभव कम से कम था)।

मैं उन्हें अपडेट करने के लिए कहने के लिए उस टीम तक पहुंच सकता हूं, हालांकि मैं इसे वापस लाने के लिए समझ में आने पर exec के गिरने पर @berkerpeksag के वजन का इंतजार

@ tjwaterman99 अच्छी तरह से मुझे यकीन नहीं है कि मुझे इस तरह से एक ऐप पर तर्क देना पसंद है। मुझे नहीं लगता कि यह एक अच्छा विचार है। तर्क env के माध्यम से पारित किया जाना चाहिए।

फ्लास्क उपयोग का हमारा अपना

cc @tilgovi @berkerpeksag ^^

एफडब्ल्यूआईडब्ल्यू हम इसमें भी भाग रहे हैं।

मुझे उम्मीद है कि "एप्लिकेशन फैक्ट्री" फ्लास्क पैटर्न का अनुसरण करने वाले बहुत सारे लोग हैं।
निश्चित रूप से एक काम है, लेकिन कम से कम चैंज को इसे ब्रेकिंग चेंज के रूप में उल्लेख करना चाहिए।

मुझे नहीं लगता कि हमने कभी जानबूझकर app:callable() और app:callable(some, args) जैसे उपयोगों का समर्थन किया है। मैं कहूंगा कि यह पिछले कार्यान्वयन में eval() का उपयोग करने का एक दुर्भाग्यपूर्ण दुष्प्रभाव था।

वर्तमान कार्यान्वयन Django के import_string() बहुत करीब है:

https://github.com/django/django/blob/master/django/utils/module_loading.py#L7 -L24

मुझे दस्तावेज़ीकरण में सुधार करने, एक रिलीज़ नोट जोड़ने और एक अधिक वर्णनात्मक त्रुटि संदेश देने में खुशी होगी।

मुझे नहीं लगता कि हमने कभी जानबूझकर ऐप: कॉल करने योग्य () और ऐप: कॉल करने योग्य (कुछ, तर्क) जैसे उपयोगों का समर्थन किया है। मैं कहूंगा कि यह पिछले कार्यान्वयन में eval() का उपयोग करने का एक दुर्भाग्यपूर्ण दुष्प्रभाव था।

हाँ मैं सहमत हूँ। जहां तक ​​मैं देख रहा हूं, हमने कभी भी आवेदन शुरू करने के लिए इस तरह का समर्थन नहीं किया।

मैं अधिक स्पष्ट त्रुटि के लिए +1 हूं। हो सकता है कि हमें एक त्रुटि उठानी चाहिए यदि आवेदन का नाम एक साधारण नाम नहीं है?

कृपया ध्यान रखें कि यह प्रमुख wsgi ढांचे (फ्लास्क) में से एक के लिए सार्वजनिक दस्तावेज़ीकरण में उल्लिखित स्पष्ट व्यवहार था, और पहले आपकी परियोजना द्वारा समर्थित किया गया है। eval को हटाने से किसी एप्लिकेशन की आलसी शुरुआत को रोकता है, जो एक समस्या है यदि कोई एप्लिकेशन 1) लाइब्रेरी द्वारा प्रदान किया गया है, और 2) गैर-तुच्छ सेटअप लागतें हैं। यदि कोई सुरक्षा या अन्य कारण नहीं है कि एक eval अनुचित क्यों है, तो क्या आपके मौजूदा व्यवहार का समर्थन करना जारी रखना आसान नहीं होगा?

यदि किसी को भी इसी तरह के मामले का सामना करना पड़ता है, तो पायथन 3.7 से उपयुक्त समाधान इस पीईपी के अनुसार मॉड्यूल-स्तर __getattr__ बनाकर एक मॉड्यूल-स्तरीय चर बनाना होगा। यह गनिकोर्न 20.0.0 में ब्रेकिंग चेंज को हिट किए बिना आलसी दीक्षा (एक ला एप्लिकेशन फैक्ट्रियों) की अनुमति देगा।

खैर, हमने वास्तव में इस तरह के व्यवहार का समर्थन कभी नहीं किया, हमारे कोई भी दस्तावेज़ या उदाहरण इसका उपयोग नहीं करते हैं। यह कमांड लाइन में फिट नहीं है।

लेकिन ठीक है, यह वास्तव में एक तोड़ने वाला और अप्रत्याशित परिवर्तन है। मैं तब eval को वापस रखने के पक्ष में रहूंगा और उपयोगकर्ता को बहिष्कृत व्यवहार के बारे में चेतावनी दूंगा। शायद इसे बदलने के लिए और लोगों को "फ़ैक्टरी" डिज़ाइन पैटर्न का उपयोग करने दें, हम एक सेटिंग जोड़ सकते हैं --init-args :

gunicorn -b :8000 --init-args="arg1,arg2"  app:factory_method

या ऐसा कुछ। विचार?

@benoitc एक स्पष्ट कमांड-लाइन ध्वज के साथ फ़ैक्टरी विधियों का समर्थन करना उत्कृष्ट होगा शायद कुछ ऐसा:

$ gunicorn -b :8000 \
  --callable \
  --callable-arg "abc" \
  --callable-arg "xyz" \
  --callable-kwarg "key" "value" \
  app:factory_method

(या शायद कोई अन्य आधार नाम, जैसे --factory )

मैं इस परिवर्तन के साथ समस्याओं का सामना कर रहा हूं क्योंकि अब मेरे लिए आसानी से परीक्षण चलाने का कोई तरीका नहीं है। क्योंकि (i) मेरा ऐप पर्यावरण चर पर निर्भर करता है, (ii) परीक्षण संग्रह सभी मॉड्यूल (सिद्धांतों के लिए) को लोड करता है और (iii) मैं अब आयात के बाद तक ऐप निर्माण को स्थगित नहीं कर सकता, मैं एक लंबी स्ट्रिंग जोड़े बिना अपने प्रोजेक्ट का परीक्षण नहीं कर सकता प्रत्येक परीक्षण कमांड से पहले पर्यावरण चर, और परीक्षण में पहले की तुलना में अधिक समय लगता है।

चूंकि मैं पायथन 3.7 पर हूं, मुझे लगता है कि मैं इसे मॉड्यूल-स्तर __getattr__ साथ हैक कर सकता हूं, लेकिन प्री-3.7 के लिए मुझे नहीं लगता कि डाउनग्रेडिंग के अलावा इस मुद्दे का कोई समाधान है।

मुझे लगता है कि कमांड-लाइन ध्वज के साथ फ़ैक्टरी विधियों का समर्थन करने से यह समस्या हल हो जाएगी। अगर मुझे एक स्पष्ट समाधान याद आ रहा है, तो अन्य सुझावों की भी सराहना की जाएगी

@ tjwaterman99 अच्छी तरह से मुझे यकीन नहीं है कि मुझे इस तरह से एक ऐप पर तर्क देना पसंद है। मुझे नहीं लगता कि यह एक अच्छा विचार है। तर्क env के माध्यम से पारित किया जाना चाहिए।

फ्लास्क उपयोग का हमारा अपना

मैं सहमत हूं, मुझे लगता है कि पर्यावरण के माध्यम से तर्क पारित करना अधिक सहज है और उपयोगकर्ताओं को उनके कॉन्फ़िगरेशन को एक ही स्थान पर लाइव करने के लिए प्रोत्साहित करता है। हालांकि कम से कम फ्लास्क, और शायद अन्य ढांचे के लिए कॉल करने योग्य वस्तुओं/कारखानों का समर्थन करना महत्वपूर्ण है।

चेतावनी देने के लिए +1, और exec अगली रिलीज़ का बहिष्कार करने से पहले कारखानों के साथ Gunicorn का उपयोग करने के बारे में निर्देश प्रदान करना।

यह दुर्भाग्यपूर्ण है कि ऐसा हुआ। हमारे पास दो विकल्प हैं कि कैसे प्रतिक्रिया दी जाए। हम व्यवहार को वापस बदल सकते हैं या हम सभी को माइग्रेट करने में मदद कर सकते हैं।

अगर हम व्यवहार को वापस बदलना चाहते हैं, तो पीपीपीआई से रिलीज को खींचना समझ में आता है, लेकिन मुझे लगता है कि यह बहुत कठोर है। Gunicorn ने कभी भी इस उपयोग का दस्तावेजीकरण या सुझाव नहीं दिया।

इसलिए, मेरा सुझाव है कि हम असुविधा के लिए सभी को अनुकूलित करने और क्षमा मांगने में मदद करें।

हमें उनके दस्तावेज़ीकरण को अद्यतन करने के लिए एक पीआर के साथ फ्लास्क तक पहुंचना चाहिए। मैं ऐसा करके खुश हूं। मुझे लगता है कि अन्य लोग पहले से ही यहां प्रवासन पथ का दस्तावेजीकरण कर रहे हैं।

मैं सुझावों में जोड़ूंगा कि यह एक _separate_ मॉड्यूल या स्क्रिप्ट के लिए उपयोगी हो सकता है जो एप्लिकेशन फ़ैक्टरी को आयात करता है, उसे कॉल करता है, और उसे निर्यात करता है। यह गनिकोर्न प्रवेश बिंदु के रूप में काम कर सकता है और इसे सबसे अच्छे और अन्य टूलिंग से छोड़ा जा सकता है ताकि विकास में इन उपकरणों को चलाते समय अवांछित आयात को ट्रिगर न करें। इसके लिए __main__.py या web.py स्क्रिप्ट जैसा कुछ काम कर सकता है।

भविष्य में, हमें रिलीज़ उम्मीदवारों को तब भी उपलब्ध कराना चाहिए, जब हमें लगता है कि रिलीज़ सुरक्षित होनी चाहिए। हम इसे एक रिलीज उम्मीदवार के साथ पकड़ सकते थे और फिर हमारे रिलीज नोट्स में ब्रेकिंग परिवर्तन को दस्तावेज करने का अवसर मिला, या इसे एक चक्र के लिए हटा दिया।

मुझे नहीं लगता कि कमांड लाइन पर प्रारंभिक तर्कों के लिए समर्थन जोड़ने का कोई मतलब है। इस रिलीज़ के लिए बहुत देर हो चुकी है; हम पहले से ही उन्नत उपयोग के मामलों के लिए कस्टम अनुप्रयोगों का समर्थन करते हैं; और कई चौखटे अनुप्रयोगों के लिए सेटिंग्स पास करने के लिए अपने स्वयं के अनुशंसित तरीके हैं। Gunicorn को अपना प्रदान करने की आवश्यकता नहीं होनी चाहिए। इस समस्या को ठीक करने के लिए तर्क जोड़ने का प्रयास भविष्य में इस तरह के ब्रेकिंग परिवर्तन के लिए सतह क्षेत्र का विस्तार करता है। हमें गनिकोर्न की सीएलआई सतह को यथासंभव कम से कम करने का लक्ष्य रखना चाहिए।

हमें उनके दस्तावेज़ीकरण को अद्यतन करने के लिए एक पीआर के साथ फ्लास्क तक पहुंचना चाहिए। मैं ऐसा करके खुश हूं। मुझे लगता है कि अन्य लोग पहले से ही यहां प्रवासन पथ का दस्तावेजीकरण कर रहे हैं।

मैं देख रहा हूँ कि @bilalshaikh42 पहले ही https://github.com/pallets/flask/pull/3421 पर ऐसा कर चुका है।

(यहां फ्लास्क अनुरक्षकों में से एक)

जबकि मैं वहां eval से छुटकारा पाने के लिए पूरी तरह सहमत हूं, मुझे लगता है कि ऐप कारखानों के लिए स्पष्ट समर्थन होना चाहिए! एक ऐप फ़ैक्टरी का पूरा बिंदु आयात करने योग्य app ऑब्जेक्ट से बचने के लिए है (क्योंकि इसका उपयोग अक्सर सर्कुलर निर्भरता नरक में होता है)।

flask run cli (केवल विकास के लिए) में हमने वास्तव में ऐप फैक्ट्रियों के लिए स्पष्ट समर्थन जोड़ा, क्योंकि वे बहुत आम हैं।

ज़रूर, wsgi.py युक्त from myapp. import make_app; app = make_app() आसान है। लेकिन मुझे या तो इस फ़ाइल को अलग से बनाए रखने की आवश्यकता है (जो असुविधाजनक है क्योंकि अब pip install myapp बस इसे चलाने के लिए आवश्यक सब कुछ स्थापित नहीं करेगा), या इसे मेरे पैकेज में डाल दें (जिसका अर्थ है कि अब आप इसे भीतर से आयात कर सकते हैं) ऐप ही जो गलत होगा)

फ्लास्क में हम कॉल करने योग्य ऐप फ़ैक्टरी की जाँच करने और eval सहारा लिए बिना इसे कॉल करने के एक

भविष्य में, हमें रिलीज़ उम्मीदवारों को तब भी उपलब्ध कराना चाहिए, जब हमें लगता है कि रिलीज़ सुरक्षित होनी चाहिए। हम इसे एक रिलीज उम्मीदवार के साथ पकड़ सकते थे और फिर हमारे रिलीज नोट्स में ब्रेकिंग परिवर्तन को दस्तावेज करने का अवसर मिला, या इसे एक चक्र के लिए हटा दिया।

सुनिश्चित नहीं है कि आरसी वास्तव में मदद करते हैं - आम तौर पर लोग --pre साथ इंस्टॉल/अपग्रेड नहीं करते हैं (यह भी कि यह कितनी बुरी तरह से काम करता है - यह न केवल स्पष्ट रूप से निर्दिष्ट पैकेजों को प्रभावित करता है, बल्कि सभी नेस्टेड निर्भरताएं कितनी गहरी हैं, इसलिए यह बहुत आसान है कि निर्भरता की कुछ निर्भरता एक टूटी हुई पूर्व-रिलीज़ में खींचती है), इसलिए कोई भी जिसने अभी-अभी अपने संस्करणों को पिन नहीं किया है, वे वास्तविक रिलीज़ होने तक कोई टूट-फूट नहीं देखेंगे।

इसके लायक क्या है, zope.hookable एक आलसी फैक्ट्री-जैसे दृष्टिकोण को लागू करने का एक आसान तरीका प्रदान करता है जिसमें अनिवार्य रूप से कोई ओवरहेड नहीं होता है (वैकल्पिक सी एक्सटेंशन के कारण)। हालाँकि, यह अतिरिक्त तर्क पारित करने के बारे में कुछ नहीं करता है।

# app.py
from zope.hookable import hookable

def make_app():
    def _(environ, start_response, value=b'Hello'):
        start_response('200 OK',
                       [('Content-Type', 'text/plain')])
        return [value]
    return _

<strong i="8">@hookable</strong>
def app(environ, start_response):
    real_app = make_app()
    app.sethook(real_app)
    return real_app(environ, start_response, b"First time")

$ gunicorn app:app
[2019-11-12 05:53:47 -0600] [12457] [INFO] Starting gunicorn 20.0.0
[2019-11-12 05:53:47 -0600] [12457] [INFO] Listening at: http://127.0.0.1:8000 (12457)
[2019-11-12 05:53:47 -0600] [12457] [INFO] Using worker: sync
[2019-11-12 05:53:47 -0600] [12460] [INFO] Booting worker with pid: 12460
...

% http localhost:8000
HTTP/1.1 200 OK
Connection: close
Content-Type: text/plain
Date: Tue, 12 Nov 2019 11:53:49 GMT
Server: gunicorn/20.0.0
Transfer-Encoding: chunked

First time

% http localhost:8000
HTTP/1.1 200 OK
Connection: close
Content-Type: text/plain
Date: Tue, 12 Nov 2019 11:53:51 GMT
Server: gunicorn/20.0.0
Transfer-Encoding: chunked

Hello

ज़रूर, wsgi.py युक्त from myapp. import make_app; app = make_app() आसान है। लेकिन मुझे या तो इस फ़ाइल को अलग से बनाए रखने की आवश्यकता है (जो असुविधाजनक है क्योंकि अब pip install myapp बस इसे चलाने के लिए आवश्यक सब कुछ स्थापित नहीं करेगा), या इसे मेरे पैकेज में डाल दें (जिसका अर्थ है कि अब आप इसे भीतर से आयात कर सकते हैं) ऐप ही जो गलत होगा)

आपके प्रोजेक्ट में wsgi.py का एक अन्य कारण गलत है: कुछ टूल प्रोजेक्ट में सभी मॉड्यूल आयात करते हैं; उदाहरण के लिए पाइस्टेस्ट करता है जब डॉक्टरेट की तलाश होती है।

एक और कुप्पी मेंटेनर यहाँ। @ThiefMaster ने पहले ही वह सब कुछ कह दिया जो मैं कहना चाहता था, इसलिए मैं ज्यादातर फीचर के लिए अपना समर्थन

मैं eval से छुटकारा पाने के लिए सहमत हूं, और मैंने इसे flask run में टाला। आप पिछले व्यवहार का अधिक सीमित संस्करण जोड़ सकते हैं। यदि कमांड लाइन विकल्प में माता-पिता हैं, तो मान लें कि यह एक कारखाना है जो वास्तविक ऐप देता है। माता-पिता की सामग्री को पार्स करने के लिए literal_eval का उपयोग करें, फिर फ़ैक्टरी को पार्स किए गए पैरा के साथ कॉल करें।

मुझे लगता है कि wsgi.py फ़ाइल के बिना फ़ैक्टरी पैटर्न बहुत मूल्यवान है। मैं इसे Gunicorn में रखने का तरीका खोजने में मदद करना चाहता/चाहती हूं।

क्या कोई literal_eval फैक्ट्री-जैसी एप्लिकेशन स्ट्रिंग्स के लिए पीआर को एक साथ रखना चाहेगा? यह gunicorn.util.import_app ।

परीक्षण जोड़ने की जरूरत है, लेकिन यहां फ्लास्क का कोड गनिकोर्न में पोर्ट किया गया है: https://github.com/benoitc/gunicorn/compare/master...davidism:import-factory

@davidism यदि आप रुचि रखते हैं, तो यहां एक ऐसा फ़ंक्शन है जो ऐप कारखानों से ऐप्स लोड करने के लिए उपयोगी हो सकता है (सिद्धांतों के साथ)। यह विशेषता नामों और फ़ंक्शन कॉल (रेगेक्स के बजाय) को अलग करने के लिए पायथन के अंतर्निर्मित एएसटी पार्सर का उपयोग करता है। यह फ़ैक्टरी फ़ंक्शन में कीवर्ड तर्कों का भी समर्थन करता है। सब कुछ अभी भी ast.parse और ast.literal_eval का उपयोग करके मूल्यांकन किया जाता है, इसलिए कोई eval कॉल नहीं हैं:

import ast
from types import ModuleType
from typing import Any


def get_app(module: ModuleType, obj: str) -> Any:
    """
    Get the app referenced by ``obj`` from the given ``module``.

    Supports either direct named references or app factories, using `ast.literal_eval` for safety.

    Example usage::

        >>> import collections
        >>> get_app(collections, 'Counter')
        <class 'collections.Counter'>
        >>> get_app(collections, 'Counter()')
        Counter()
        >>> get_app(collections, 'import evil_module')  # doctest: +ELLIPSIS
        Traceback (most recent call last):
          ...
        ValueError: Could not parse 'import evil_module' as a reference to a module attribute or app factory.
        >>> get_app(collections, '(lambda: sys.do_evil)()')
        Traceback (most recent call last):
            ...
        ValueError: App factories must be referenced by a simple function name
        >>> get_app(collections, '(1, 2, 3)')
        Traceback (most recent call last):
            ...
        ValueError: Could not parse '(1, 2, 3)' as a reference to a module attribute or app factory.
    """
    # Parse `obj` to an AST expression, handling syntax errors with an informative error
    try:
        # Note that mode='eval' only means that a single expression should be parsed
        # It does not mean that `ast.parse` actually evaluates `obj`
        expression = ast.parse(obj, mode='eval').body
    except SyntaxError as syntax_error:
        raise ValueError("Could not parse '{}' as a reference to a module attribute or app factory.".format(obj)) from syntax_error

    # Handle expressions that just reference a module attribute by name
    if isinstance(expression, ast.Name):
        # Expression is just a name, attempt to get the attribute from the module
        return getattr(module, expression.id)

    # Handle expressions that make a function call (factory)
    if isinstance(expression, ast.Call):
        # Make sure the function name is just a name reference
        if not isinstance(expression.func, ast.Name):
            raise ValueError("App factories must be referenced by a simple function name")

        # Extract the function name, args and kwargs from the call
        try:
            name = expression.func.id
            args = [ast.literal_eval(arg) for arg in expression.args]
            kwargs = {keyword.arg: ast.literal_eval(keyword.value) for keyword in expression.keywords}
        except ValueError as value_error:
            raise ValueError("Could not evaluate factory arguments, please ensure that arguments include only literals.") from value_error

        # Get and call the function, passing in the given arguments:
        return getattr(module, name)(*args, **kwargs)

    # Raise an error, we only support named references and factory methods
    raise ValueError("Could not parse '{}' as a reference to a module attribute or app factory.".format(obj))

यदि निर्णय केवल शून्य-तर्क ऐप कारखानों का समर्थन करने के लिए किया जाता है, तो सभी तर्क प्रसंस्करण कोड को हटाया जा सकता है। यह अभी भी नामों और फ़ैक्टरी कॉलों को सुरक्षित रूप से अलग करने के लिए अच्छी तरह से काम करेगा (और फ़ैक्टरी में तर्क पारित करने का प्रयास करते समय उपयोगकर्ताओं को विशिष्ट त्रुटि संदेश देने के लिए उपयोगी होगा)

@ThiefMaster मैं अभी भी

ज़रूर, myapp से युक्त एक wsgi.py बनाना। आयात मेक_एप; ऐप = make_app() आसान है। लेकिन मुझे या तो इस फ़ाइल को अलग से बनाए रखने की आवश्यकता है (जो असुविधाजनक है क्योंकि अब pip install myapp बस इसे चलाने के लिए आवश्यक सब कुछ स्थापित नहीं करेगा), या इसे मेरे पैकेज में डाल दें (जिसका अर्थ है कि अब आप इसे ऐप के भीतर से ही आयात कर सकते हैं) जो गलत होगा)

मुझे समझ में नहीं आता कि ऐसी फाइल को अलग से क्यों रखना पड़ता है?

यदि यह पैकेज में है, तो यह आयात योग्य है। इसलिए यदि आपके पास एक बड़ी परियोजना है तो कोई अंततः current_app आदि का उपयोग करने के बजाय इसे आयात करेगा .. यानी इस तरह की गलतियों वाले पीआर से निपटने के दौरान अधिक काम।

यदि यह पैकेज के बाहर है, तो pip install करते समय आपको यह नहीं मिलेगा।

एफडब्ल्यूआईडब्ल्यू, मुझे वास्तव में तर्क पारित करने की परवाह नहीं है। आम तौर पर उनकी आवश्यकता नहीं होती है (env vars वास्तव में जाने का रास्ता हैं)। लेकिन कम से कम ऐप ऑब्जेक्ट के बजाय कॉल करने योग्य ऐप फ़ैक्टरी को इंगित करने में सक्षम होना अविश्वसनीय रूप से उपयोगी है!

यदि वास्तव में इसकी आवश्यकता है तो कस्टम तर्क या कॉन्फ़िगरेशन पास करने के लिए पर्यावरण चर का उपयोग क्यों नहीं कर रहे हैं?

pytest परीक्षण खोजने के लिए परियोजना में प्रत्येक मॉड्यूल को लोड करता है। यदि आपके पास वैश्विक app=Flask() ऑब्जेक्ट है जो पर्यावरण चर या कॉन्फ़िगरेशन फ़ाइल पर निर्भर करता है, तो परीक्षण चलाते समय वह ऑब्जेक्ट लोड हो जाएगा। पर्यावरण चर या कॉन्फ़िगरेशन फ़ाइलों को सेट किए बिना परीक्षण चलाने में सक्षम होना उपयोगी है। इसके लिए ऐप फैक्ट्री पैटर्न बहुत अच्छा है।

कुछ लोकप्रिय फ्लास्क ट्यूटोरियल के कारण तर्क पैटर्न वाला कारखाना कुछ सामान्य है, यही वजह है कि मैंने इसे flask run में समर्थन दिया। मैं मानता हूं कि ऐप को कॉन्फ़िगर करने के लिए पर्यावरण का उपयोग करना बेहतर है, इसलिए मैं अधिक कम संस्करण के साथ ठीक रहूंगा जो बिना किसी तर्क के कारखाने को कॉल करने का समर्थन करता है।

# an app is a name only
$ gunicorn module:app

# a factory has (), but no args allowed
$ gunicorn module:factory()

@tilgovi मैं सहमत हूँ। मेरा मुख्य मुद्दा यह है कि हमें उम्मीद नहीं थी कि यह किसी को तोड़ देगा, इसलिए मैं eval (या कुछ सुरक्षित) को वापस रखने और इसे बहिष्कृत करने का सुझाव क्यों दे रहा था। दूसरी ओर, हाँ वह व्यवहार कभी समर्थित नहीं था और eval का उपयोग करने का एक दुर्भाग्यपूर्ण प्रभाव था: /

@ डेविडवाद दिलचस्प। लेकिन यह कॉल करने योग्य ऑब्जेक्ट को एप्लिकेशन के रूप में उपयोग करने से अलग कैसे होगा?

मुझे यकीन नहीं है कि आपका क्या मतलब है, क्या आप एक और विशिष्ट उदाहरण दे सकते हैं? एक कारखाना एक डब्लूएसजीआई आवेदन देता है, यह स्वयं एक डब्लूएसजीआई आवेदन नहीं है।

@davidism मेरा मतलब कुछ इस तरह है

def make_app():
  from mymodule.application import MainApp
  return MainApp()

application = make_app()

फिर कोई gunicorn -b :8000 somemodule:application चलाता है

यह कारखाने के उद्देश्य को हराकर, कोड आयात करते समय application का हमेशा मूल्यांकन करता है।

एक डब्लूएसजीआई कॉल करने योग्य एक वर्ग उदाहरण भी हो सकता है, इसलिए शायद यही इरादा था:

class Application:
    _app = None
    def __call__(self, environ, start_response):
        if self._app is None:
            from wherever import make_app
            self._app = make_app()
        return self._app(environ, start_response)

application = Application()

( zope.hookable उदाहरण अनिवार्य रूप से वही है, स्थिर-अवस्था की स्थिति में बस कम ओवरहेड।)

वास्तविक WSGI ऐप बनाने वाला WSGI ऐप होना आदर्श नहीं है। यह अब वास्तविक प्रवेश बिंदु पर प्रॉक्सी के प्रत्येक अनुरोध पर एक अतिरिक्त फ़ंक्शन कॉल है। सेटअप पहले अनुरोध से पहले किया जाना चाहिए, लेकिन अब इसे तब तक के लिए टाल दिया गया है, जिससे पहले अनुरोध में अधिक समय लग सकता है (संभावित रूप से बहुत अधिक)।

यहां विचाराधीन कार्यक्षमता एक फ़ैक्टरी फ़ंक्शन है जो उस ऑब्जेक्ट को रनटाइम/पर्यावरण कॉन्फ़िगरेशन के आधार पर

इस बिंदु पर, हम केवल यह पूछ रहे हैं कि "यदि आयात स्ट्रिंग माता-पिता के साथ समाप्त होती है, तो ऐप प्राप्त करने के लिए आयातित नाम पर कॉल करें"।

मुझे लगता है कि हमारे पास इसके लिए बहुत सारे तरीके हैं, लेकिन इसका सीधा सा मतलब है कि हम लक्षित दर्शक नहीं हैं। मुझे पता है कि मैं अपने कंटेनर के लिए एक एंट्रीपॉइंट के रूप में पैकेज के बाहर एक स्क्रिप्ट शिप करने जैसी चीजें कर सकता हूं और इसे अनदेखा करने के लिए पाइस्टेस्ट को कॉन्फ़िगर कर सकता हूं, आदि, लेकिन हम उन लोगों की परवाह करना चाहते हैं जिनके लिए यह टूट जाता है जो ट्यूटोरियल का अनुसरण कर रहे हैं और हो सकता है ट्रेसबैक समझ में नहीं आता।

एक बहुत ही सीमित "यदि ऐप ऑब्जेक्ट शून्य तर्कों के साथ कॉल करने योग्य है, तो इसे फ़ैक्टरी के रूप में आमंत्रित करें" पैटर्न काम कर सकता है, लेकिन यह विफल हो जाता है यदि कॉल करने योग्य वास्तव में एक डब्लूएसजीआई एप्लिकेशन है जो बुरी तरह से सजाया गया है और आत्मनिरीक्षण से अपने तर्कों को इतनी आसानी से प्रकट नहीं करता है . अगर हम उदार होना चाहते हैं, तो हमें eval से परहेज करते हुए पहले जो कुछ भी था उसका समर्थन करना चाहिए, इसलिए मुझे लगता है कि यही वह रास्ता है जो हमें करना चाहिए।

मैं वास्तव में सभी सुझावों की सराहना करता हूं और इसे हल करने में मदद करता हूं, हर कोई।

मुझे literal_eval का उपयोग करके @davidism और @connorbrinton दोनों सुझावों को पसंद है ।

यह फ़ैक्टरी के उद्देश्य को हराते हुए, कोड आयात करते समय एप्लिकेशन का हमेशा मूल्यांकन करने का कारण बनता है।

वैसे यह रनटाइम पर ऐप को इनिट करेगा और श्रमिकों द्वारा उपयोग किए जाने वाले कॉल करने योग्य लौटाएगा। यह इतना अलग नहीं है।

उस पैटर्न के बारे में मेरा मुख्य रिजर्व यह है कि यह लोगों को कुछ कोड प्री-स्पॉन चलाने के लिए प्रोत्साहित करता है जो एचयूपी या यूएसआर 2 पर अपेक्षाओं को तोड़ सकता है। साथ ही यह वर्तमान UI को तोड़ता है। क्या यह गनिकोर्न के भविष्य के उपयोग के साथ काम करेगा?

वैसे भी विकल्प निम्नलिखित हैं:

1. हम इस व्यवहार पर विचार कर सकते हैं असमर्थित, अनिर्दिष्ट (गनिकोर्न में)। इसके आधार पर जो बदलाव किया गया है।
2. कुछ उपयोगकर्ता इस पर भरोसा कर रहे थे और अब हम उस व्यवहार का समर्थन करना चाहते हैं

(१) एक कठिन रास्ता है, लेकिन तार्किक रास्ता भी है, यह देखते हुए कि हमने कभी इसका समर्थन नहीं किया।
(२) किसी प्रकार का सौंदर्य और कमांड लाइन UI को तोड़ता है, इसे गनिकोर्न में परीक्षण करने के लिए कुछ परीक्षणों/उदाहरणों की आवश्यकता होती है, जैसे कुछ का उपयोग करें शाब्दिक_एवल्स

हम (2) का समर्थन कर सकते हैं लेकिन मैं कुछ परीक्षण करना चाहता हूं। क्या हमें इसका दस्तावेजीकरण भी करना चाहिए?

@tilgovi @jamadden @berkerpeksag @sirkonst आपकी पसंद क्या है?

ऐसा लगता है कि एक और ब्रेकिंग उपयोग मामला विशेषता पहुंच था , जिसे literal_eval द्वारा हल नहीं किया जाएगा।

उदाहरण के लिए, प्लॉटली डैश में आप Dash ऑब्जेक्ट का उपयोग करते हैं, जिसमें आंतरिक रूप से server विशेषता के रूप में Flask उदाहरण होता है। कुछ लोग उपयोग कर रहे थे:

gunicorn "module:app.server"

मुझे यकीन नहीं है कि हालांकि इसका समर्थन किया जाना चाहिए। flask run भी इसका समर्थन नहीं करता है। ऐसा लगता है कि Dash ऑब्जेक्ट में __call__ विधि होनी चाहिए जो Flask.__call__ । इसके अतिरिक्त, डैश के दस्तावेज़ server = app.server करने के लिए कहते हैं और उस पर गनिकोर्न को इंगित करते हैं, इसलिए ऐसा लगता है कि यह कुछ गलत जानकारी के आसपास पारित होने का मामला है।

@davidism मैं आज बीमार हो गया हूं लेकिन मैं इस रविवार को सोमवार को रिलीज के लिए इसके बारे में @tilgovi का सुझाव अच्छा है और सामान्य योजना पुराने eval की जगह एक सुरक्षित eval रखना है।

मुझे लगता है कि हमें उस उपयोगकर्ता को चेतावनी देनी चाहिए जो वह इस तरह के प्रारंभिक उपयोग कर रहा है। विचार? सीसी @tilgovi

जब तक आप एक अलग कार्यान्वयन नहीं बनाना चाहते, मैं शनिवार को परीक्षणों के साथ ऊपर से जुड़ी शाखा को पीआर में बदलने की कोशिश करूंगा।

@davidism आगे बढ़ो। मैं रविवार को वापस आऊंगा जहां नीड होने पर मैं इसकी समीक्षा करूंगा :) धन्यवाद!

थोड़ा पीछे, अब इस पर काम कर रहे हैं।

@connorbrinton ast.parse का उपयोग करने के लिए अच्छा विचार है, मैं इसे आज़माउंगा और यदि मैं इसके साथ जाता हूं तो आपको प्रतिबद्धता पर सह-लेखक के रूप में शामिल करूंगा।

बस इसमें झंकार करना चाहता था कि कुछ लोकप्रिय (और काफी पुराना) स्टैक ओवरफ्लो उत्तर है जो उपयोगकर्ताओं को v19 व्यवहार की ओर निर्देशित कर रहा है, जिसे किस विकल्प के आधार पर अपडेट की आवश्यकता हो सकती है: https://stackoverflow.com/questions/ 8495367/उपयोग-अतिरिक्त-कमांड-लाइन-तर्क-साथ-गनिकोर्न

मास्टर में तय पैच के लिए धन्यवाद @davidism !

संभाले गए सभी मामले इस परीक्षण में हैं: https://github.com/benoitc/gunicorn/commit/19cb68f4c3b55da22581c008659ee62d8c54ab2b#diff -5832adf374920d75d4bf48e546367f53R67