Gunicorn: v20 문제: 'app'에서 'create_app()' 애플리케이션 개체를 찾지 못했습니다.

나는 또한이 문제를 경험했습니다.
Failed to find application object 'create_app()' in 'app'
버전 19.9.0에 고정하면 문제가 해결됩니다.

처음에는 수정 사항이 gunicorn 명령을 다음에서 변경하는 것이지만
gunicorn --bind 0.0.0.0:$PORT app:create_app()
에게:
gunicorn --bind 0.0.0.0:$PORT app:create_app
(create_app 뒤의 대괄호가 이제 사라졌습니다.) 처음에는 모든 것이 잘 보입니다.

웹사이트_1 | [2019-11-10 19:18:54 +0000] [1] [INFO] 기니콘 20.0.0 시작
웹사이트_1 | [2019-11-10 19:18:54 +0000] [1] [INFO] 듣기: http://0.0.0.0 :8000 (1)
웹사이트_1 | [2019-11-10 19:18:54 +0000] [1] [INFO] 작업자 사용: 동기화
웹사이트_1 | [2019-11-10 19:18:54 +0000] [11] [INFO] pid: 11로 작업자 부팅

그러나 플라스크 웹 사이트/엔드포인트를 로드하려고 하면 다음과 같이 표시되기 때문에 신기루일 뿐입니다.

[2019-11-10 19:20:28 +0000] [11] [ERROR] 요청 처리 오류 /
웹사이트_1 | 역추적(가장 최근 호출 마지막):
웹사이트_1 | 파일 "/usr/local/lib/python3.7/site-packages/gunicorn/workers/sync.py", 134행, 핸들
웹사이트_1 | self.handle_request(수신기, 요청, 클라이언트, 주소)
웹사이트_1 | handle_request의 파일 "/usr/local/lib/python3.7/site-packages/gunicorn/workers/sync.py", 175행
웹사이트_1 | respiter = self.wsgi(환경, resp.start_response)
웹사이트_1 | TypeError: create_app()은 0개의 위치 인수를 사용하지만 2개가 주어졌습니다.

이것은 분명히 gunicorn 버전 20.0.0의 문제입니다.

: 그것은이 변경에 관련되어야한다 https://github.com/benoitc/gunicorn/commit/3701ad9f26a7a4c0a081dfd0f6e97ecb272de515#diff # 2043를 통해 -0b90f794c3e9742c45bf484505e3db8dR377.

귀하의 측면에 문제를 해결하는 한 가지 방법은 내 보낸 것입니다 myapp = create_app() 기본 모듈로 열 시작에 app:myapp . 이것은 작동해야 합니다. 작동하지 않으면 알려주세요.

거기에서 해야 할 일이 있는지 살펴보겠습니다. @berkerpeksag 왜 거기에서 eval 가 필요했습니까?

이 변경 사항과 관련되어야 합니다: 3701ad9#diff-0b90f794c3e9742c45bf484505e3db8dR377 via #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 알아두면 도움이 될 경우를 대비 하여 플라스크 문서 는 gunicorn을 사용할 때 app:create_app() 패턴을 권장합니다. 나는 당신의 새로운 사용자 중 일부가 플라스크 앱을 구축한 결과로 gunicorn을 먼저 시도하고 해당 문서에서 현재 깨진 권장 사항을 사용하려고 시도할 것이라고 생각합니다(최소한 내 경험이었습니다).

해당 팀에 연락하여 업데이트를 요청할 수 있지만 @berkerpeksag 가 exec 하락에 무게를 실 을 때까지 기다리겠습니다.

@ tjwaterman99 글쎄, 나는 이런 식으로 앱에 인수를 전달하는 것을 좋아하는지 확신하지 못합니다. 좋은 생각이 아닌 것 같아요. 인수는 env를 통해 전달되어야 합니다.

Flask 사용 에 대한 우리 자신의

cc @tilgovi @berkerpeksag ^^

FWIW 우리도 이 문제를 겪고 있습니다.

"응용 프로그램 팩토리" Flask 패턴을 따르는 사람들이 꽤 많을 것으로 예상합니다.
확실히 해결 방법이 있지만 적어도 변경 로그에는 이를 주요 변경 사항으로 언급해야 합니다.

app:callable() 및 app:callable(some, args) 와 같은 사용법을 의도적으로 지원한 적이 없다고 생각합니다. 이전 구현에서 eval() 를 사용한 불행한 부작용이라고 말하고 싶습니다.

현재 구현은 Django의 import_string() 가 하는 것과 매우 유사합니다.

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

문서를 개선하고, 릴리스 정보를 추가하고, 보다 설명적인 오류 메시지를 표시하게 되어 기쁩니다.

app:callable () 및 app:callable (some, args)과 같은 사용법을 의도적으로 지원한 적이 없다고 생각합니다. 이전 구현에서 eval()을 사용한 불행한 부작용이라고 말하고 싶습니다.

그래, 난 동의. 우리는 내가 찾고 있는 한 응용 프로그램을 시작하는 그런 방법을 지원한 적이 없습니다.

나는 더 명백한 오류에 대해 +1입니다. 응용 프로그램 이름이 간단한 이름이 아니면 오류를 발생시켜야 할까요?

이것은 주요 wsgi 프레임워크(플라스크) 중 하나에 대한 공개 문서에 언급된 명시적인 동작이며 이전에 프로젝트에서 지원한 것임을 기억하십시오. eval을 제거하면 응용 프로그램의 지연 시작이 방지됩니다. 이는 응용 프로그램이 1) 라이브러리에서 제공되고 2) 사소한 설정 비용이 발생하는 경우 문제입니다. 평가가 부적절한 보안이나 다른 이유가 없다면 기존 행동을 계속 지원하는 것이 더 간단하지 않을까요?

누군가 비슷한 경우에 직면하는 경우 Python 3.7 이후의 적절한 해결 방법은 이 PEP 에 따라 모듈 수준 __getattr__ 을 만들어 모듈 수준 변수를 가장하는 것입니다. 그러면 gunicorn 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) 테스트 컬렉션이 모든 모듈(doctest용)을 로드하고 (iii) 가져오기가 끝날 때까지 더 이상 앱 구성을 연기할 수 없기 때문에 긴 문자열을 추가하지 않고는 내 프로젝트를 테스트할 수 없습니다. 모든 테스트 명령 전에 환경 변수를 사용하고 테스트는 이전보다 더 오래 걸립니다.

저는 Python 3.7을 사용하고 있기 때문에 모듈 수준의 __getattr__ 로 이 문제를 해결할 수 있다고 생각하지만 3.7 이전 버전의 경우 다운그레이드 외에 이 문제에 대한 해결책이 없다고 생각합니다.

명령줄 플래그로 팩토리 메서드를 지원하면 이 문제가 해결될 것이라고 생각합니다. 그래도 확실한 해결책이 없다면 다른 제안도 감사하겠습니다 🙃

@ tjwaterman99 글쎄, 나는 이런 식으로 앱에 인수를 전달하는 것을 좋아하는지 확신하지 못합니다. 좋은 생각이 아닌 것 같아요. 인수는 env를 통해 전달되어야 합니다.

Flask 사용 에 대한 우리 자신의

동의합니다. 환경을 통해 인수를 전달하는 것이 더 직관적이고 사용자가 한 곳에서 구성을 유지하도록 권장합니다. 그러나 호출 가능한 객체/팩토리를 지원하는 것은 적어도 Flask 및 아마도 다른 프레임워크에서도 중요합니다.

exec 다음 릴리스를 더 이상 사용하지 않기 전에 경고를 표시하고 공장에서 Gunicorn을 사용하는 방법에 대한 지침을 제공하면 +1입니다.

이런 일이 일어난 것은 불행한 일입니다. 우리는 응답 방법에 대해 두 가지 선택이 있습니다. 행동을 다시 바꾸거나 모든 사람이 이주하도록 도울 수 있습니다.

우리가 동작을 다시 변경한다면 PyPI에서 릴리스를 철회하는 것이 합리적일 수 있지만 이것은 너무 과감하다고 생각합니다. Gunicorn은 이 사용법을 문서화하거나 제안한 적이 없습니다.

따라서 모두가 적응할 수 있도록 돕고 불편을 드려 죄송합니다.

문서를 업데이트하려면 PR과 함께 Flask에 연락해야 합니다. 그렇게 해서 기쁩니다. 다른 사람들이 이미 여기에서 마이그레이션 경로를 문서화하고 있다고 생각합니다.

나는 응용 프로그램 팩토리를 가져오고, 호출하고, 내보내는 _separate_ 모듈 또는 스크립트를 갖는 것이 유용할 수 있다는 제안을 추가할 것입니다. 이는 Gunicorn 진입점 역할을 할 수 있으며 doctest 및 기타 도구에서 생략할 수 있으므로 개발 중에 이러한 도구를 실행할 때 원치 않는 가져오기를 트리거하지 않습니다. __main__.py 또는 web.py 스크립트와 같은 것이 이를 위해 작동할 수 있습니다.

앞으로는 릴리스가 안전해야 한다고 생각하는 경우에도 릴리스 후보를 사용할 수 있도록 해야 합니다. 릴리스 후보를 통해 이 문제를 파악한 다음 릴리스 노트의 주요 변경 사항을 문서화하거나 주기 동안 사용하지 않을 수 있습니다.

명령줄에서 초기화 인수에 대한 지원을 추가하는 것이 합리적이지 않다고 생각합니다. 이 릴리스에는 너무 늦었습니다. 우리는 이미 고급 사용 사례를 위한 맞춤형 애플리케이션을 지원합니다. 많은 프레임워크에는 애플리케이션에 설정을 전달하는 자체 권장 방법이 있습니다. Gunicorn은 자체적으로 제공할 필요가 없습니다. 이 문제를 해결하기 위해 인수를 추가하려고 하면 향후 이러한 종류의 주요 변경 사항에 대한 노출 영역이 확장됩니다. Gunicorn의 CLI 표면을 최대한 최소화하는 것을 목표로 해야 합니다.

문서를 업데이트하려면 PR과 함께 Flask에 연락해야 합니다. 그렇게 해서 기쁩니다. 다른 사람들이 이미 여기에서 마이그레이션 경로를 문서화하고 있다고 생각합니다.

@bilalshaikh42가 이미 https://github.com/pallets/flask/pull/3421 에서 이 작업을 수행 했음을 알 수 있습니다.

(여기에 있는 Flask 관리자 중 한 명)

거기에서 eval 없애는 데 전적으로 동의하지만 앱 팩토리에 대한 명시적인 지원이 있어야 한다고 생각합니다! 앱 팩토리의 요점은 가져올 수 있는 app 개체를 사용하지 않는 것입니다(이를 사용하면 순환 종속성 지옥이 자주 발생하기 때문에).

flask run cli(개발 전용)에서 우리는 실제로 앱 팩토리에 대한 명시적 지원 을 추가했습니다.

물론, A가 생성 wsgi.py 포함 from myapp. import make_app; app = make_app() 쉽습니다. 그러나 이 파일을 별도로 유지 관리해야 하거나(이제 pip install myapp 가 실행하는 데 필요한 모든 것을 설치하지 않기 때문에 불편함) 패키지에 넣어야 합니다(즉, 이제 내부에서 파일을 가져올 수 있음을 의미합니다. 잘못된 앱 자체)

Flask에서 우리는 eval 의존하지 않고 호출 가능한 앱 팩토리를 확인하고 호출하는 명시적인 방법 을 찾았습니다. 아마도 이와 같은 것을 고려할 수 있을까요? 덜 마법을 원한다면 애플리케이션을 가리키고 앱 팩토리를 가리키는 데 다른 CLI 인수를 사용할 수도 있습니다.

앞으로는 릴리스가 안전해야 한다고 생각하는 경우에도 릴리스 후보를 사용할 수 있도록 해야 합니다. 릴리스 후보를 통해 이 문제를 파악한 다음 릴리스 노트의 주요 변경 사항을 문서화하거나 주기 동안 사용하지 않을 수 있습니다.

RC가 실제로 도움이 되는지 확실하지 않습니다. 일반적으로 사람들은 --pre 설치/업그레이드하지 않습니다. 따라서 종속성의 일부 종속성이 손상된 시험판을 가져오기가 매우 쉽기 때문에 버전을 고정하지 않은 사람은 실제 릴리스될 때까지 손상을 발견하지 못할 것입니다.

그만한 가치가 있기 때문에 zope.hookable 는 기본적으로 오버헤드가 없는 공장과 같은 게으른 접근 방식을 구현하는 쉬운 방법을 제공합니다(선택적 C 확장으로 인해). 그러나 추가 인수 전달에 대해서는 아무 것도 하지 않습니다.

# 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

물론, A가 생성 wsgi.py 포함 from myapp. import make_app; app = make_app() 쉽습니다. 하지만 이 파일을 별도로 유지 관리해야 하거나(이제 pip install myapp 가 실행하는 데 필요한 모든 것을 설치하지 않기 때문에 불편함) 패키지에 넣어야 합니다(즉, 이제 내부에서 파일을 가져올 수 있음을 의미합니다. 잘못된 앱 자체)

프로젝트에 wsgi.py 가 있는 또 다른 이유는 잘못된 것입니다. 일부 도구는 프로젝트의 모든 모듈을 가져옵니다. 예를 들어 pytest는 doctest를 찾을 때 수행합니다.

여기 또 다른 Flask 유지 관리자가 있습니다. @ThiefMaster는 이미 제가 하고 싶은 말을 다 했기 때문에 저는 이 기능에 대한 지지를 계속해서 강조하고 있습니다.

나는 eval 제거에 동의하고 flask run 에서 그것을 피했습니다. 이전 동작의 더 제한된 버전을 추가할 수 있습니다. 명령줄 옵션에 괄호가 있는 경우 실제 앱을 반환하는 공장이라고 가정합니다. literal_eval 를 사용하여 괄호의 내용을 구문 분석한 다음 구문 분석된 매개변수로 팩토리를 호출합니다.

wsgi.py 파일이 없는 팩토리 패턴은 꽤 가치가 있다고 생각합니다. Gunicorn에 보관하는 방법을 찾는 데 도움이 되었으면 합니다.

누군가 literal_eval 의 공장 같은 애플리케이션 문자열에 대해 PR을 함께 하고 싶습니까? 이것은 gunicorn.util.import_app 있습니다.

테스트를 추가해야 하지만 다음은 Gunicorn으로 이식된 Flask의 코드입니다. 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; app = make_app() 은 쉽습니다. 그러나 이 파일을 별도로 유지 관리해야 하거나(이제 pip install myapp이 실행하는 데 필요한 모든 것을 설치하지 않기 때문에 불편함) 내 패키지에 넣어야 합니다(즉, 이제 앱 자체 내에서 가져올 수 있음을 의미합니다. 그것은 잘못된 것입니다)

그런 파일을 별도로 관리해야 하는 이유가 무엇인지 이해가 되지 않습니다.

패키지에 있으면 가져올 수 있습니다. 따라서 더 큰 프로젝트가 있는 경우 누군가는 결국 current_app 등을 사용하는 대신 가져오기만 하게 됩니다. 즉, 이러한 종류의 실수가 포함된 PR을 처리할 때 더 많은 작업이 필요합니다.

패키지 외부에 있으면 pip install 하면 얻을 수 없습니다.

FWIW, 나는 인수 전달에 대해 정말로 신경 쓰지 않습니다. 일반적으로 그것들은 필요하지 않습니다(env vars가 실제로 갈 길입니다). 그러나 적어도 앱 객체 대신 호출 가능한 앱 팩토리를 가리킬 수 있다는 것은 매우 유용합니다!

정말 필요한 경우 환경 변수를 사용하여 사용자 지정 인수 또는 구성을 전달하지 않는 이유는 무엇입니까?

pytest 는 프로젝트의 모든 모듈을 로드하여 테스트를 찾습니다. 환경 변수 또는 구성 파일에 의존하는 전역 app=Flask() 개체가 있는 경우 테스트를 실행할 때 해당 개체가 로드됩니다. 환경 변수나 구성 파일을 설정하지 않고 테스트를 실행할 수 있는 것이 유용합니다. 앱 팩토리 패턴은 이에 적합합니다.

인수 패턴이 있는 팩토리는 일부 인기 있는 Flask 튜토리얼로 인해 다소 일반적입니다. 이것이 제가 flask run 에서 지원한 이유입니다. 환경을 사용하여 앱을 구성하는 것이 더 낫다는 데 동의합니다. 따라서 인수 없이 팩토리 호출을 지원하는 더 축소된 버전을 사용하는 것이 좋습니다.

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

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

@tilgovi 동의합니다. 내 주요 문제는 우리가 그것이 누군가를 망칠 것이라고 예상하지 못했다는 것입니다. 따라서 내가 평가(또는 더 안전한 것)를 되돌리고 더 이상 사용하지 않을 것을 제안한 이유는 무엇입니까? 반면에 그 동작은 지원되지 않았으며 eval 를 사용한 불행한 결과였습니다./

@davidism 재미

무슨 말인지 잘 모르겠는데 좀 더 구체적인 예를 들어주실 수 있나요? 팩토리는 WSGI 애플리케이션을 반환하지만 그 자체는 WSGI 애플리케이션이 아닙니다.

@davidism 내 말은

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

application = make_app()

누군가 gunicorn -b :8000 somemodule:application

이로 인해 application 는 코드를 가져올 때 항상 평가되어 팩토리의 목적을 무효화합니다.

WSGI 콜러블은 클래스 인스턴스가 될 수도 있으므로 아마도 이것이 의도한 것입니다.

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 앱을 갖는 것은 이상적이지 않습니다. 이제 실제 진입점으로 프록시를 요청하는 모든 요청에 ​​대한 추가 함수 호출입니다. 설정은 첫 번째 요청 전에 수행되어야 하지만 지금은 그때까지 연기되어 첫 번째 요청이 (잠재적으로 훨씬) 더 오래 걸립니다.

여기서 문제의 기능은 런타임/환경 구성을 기반으로 해당 개체를 생성 하는 팩토리 기능으로, 애플리케이션 부분을 분리하고 순환 가져오기를 방지하며 테스트 격리를 더 쉽게 하는 데 유용합니다. 명시적으로 공장 종류를 호출하는 코드의 어딘가에 디커플링 목적이 무효화됩니다. 사용자가 Flask에서 사용할 수 있는 기능을 대신 사용해야 할 때 "오, 지금쯤 이 앱 개체를 가져와야 합니다"라고 생각할 것이라고 보장하기 때문입니다.

이 시점에서 우리가 요구하는 것은 "가져오기 문자열이 괄호로 끝나면 가져온 이름을 호출하여 앱을 가져옵니다"입니다.

나는 우리가 이 문제를 해결할 수 있는 방법이 많다고 생각하지만, 그것은 우리가 타겟 청중이 아니라는 것을 의미합니다. 패키지 외부에 있는 스크립트를 컨테이너의 진입점으로 제공하고 pytest가 이를 무시하도록 구성하는 등의 작업을 수행할 수 있다는 것을 알고 있습니다. 역추적을 이해하지 못한다.

매우 제한된 "앱 개체가 인수가 없는 경우 호출 가능한 경우 팩토리로 호출" 패턴이 작동할 수 있지만 호출 가능한 개체가 실제로 잘못 데코레이팅된 WSGI 응용 프로그램이고 자체 검사에서 인수를 쉽게 드러내지 않는 경우 실패합니다. . 우리가 관대해지고 싶다면 eval 를 피하면서 이전에 가졌던 모든 것을 지원해야 하므로 그것이 우리가 해야 할 길이라고 생각합니다.

모든 제안에 감사드리며 이 문제를 해결하는 데 도움을 드립니다.

literal_eval 사용하는 @davidism 과 @connorbrinton 의 제안이 모두 마음 에 듭니다 .

이로 인해 코드를 가져올 때 애플리케이션이 항상 평가되어 팩토리의 목적이 무효화됩니다.

글쎄, 그것은 런타임에 앱을 초기화하고 작업자가 사용하는 콜러블을 반환합니다. 그렇게 다르지 않습니다.

그 패턴에 대한 나의 주요 예비 사항은 사람들이 HUP 또는 USR2에 대한 기대를 깨뜨릴 수 있는 일부 코드 사전 생성을 실행하도록 권장한다는 것입니다. 또한 현재 UI를 깨뜨립니다. 앞으로 gunicorn을 사용할 때 작동합니까?

어쨌든 선택은 다음과 같습니다.

1. 우리는 이 동작이 지원되지 않고 문서화되지 않은 것으로 간주할 수 있습니다(gunicorn에서). 이를 기반으로 한 변경 사항입니다.
2. 일부 사용자는 그것에 의존했고 이제 우리는 그 행동을 지원하고자 합니다.

(1)은 어려운 선택이지만 우리가 지원한 적이 없다는 점을 고려하면 논리적인 경로이기도 합니다.
(2) 어떤 종류의 미학적이고 명령줄 UI를 깨뜨립니다. gunicorn에서 테스트하려면 몇 가지 테스트/예제가 필요합니다. literal_evals와 같은 것을 사용합니다.

우리는 (2)를 지원할 수 있지만 몇 가지 테스트를 하고 싶습니다. 또한 문서화해야 합니까?

@tilgovi @jamadden @berkerpeksag @sirkonst 당신의 취향은 무엇입니까?

또 다른 주요 사용 사례는 literal_eval 로 해결되지 않는 속성 액세스 인 것 같습니다.

예를 들어, Plotly Dash에서 server 속성으로 내부적으로 Flask 인스턴스가 있는 Dash 개체를 사용합니다. 어떤 사람들은 다음을 사용하고 있었습니다.

gunicorn "module:app.server"

그러나 이것이 지원되어야하는지 확실하지 않습니다. flask run 도 지원하지 않습니다. Dash 개체에 Flask.__call__ 전달되는 __call__ 메서드가 있어야 하는 것 같습니다. 또한 Dash의 문서 에는 server = app.server 하고 Gunicorn을 가리키도록 되어 있으므로 대부분 잘못된 정보가 전달되는 경우인 것 같습니다.

@davidism 저는 오늘 @tilgovi 의 제안은

그런 초기화를 사용하고 있다고 사용자에게 경고해야 한다고 생각합니다. 생각? cc @tilgovi

다른 구현을 만들지 않는 한 위에서 링크한 분기를 토요일에 테스트가 포함된 PR로 전환하려고 합니다.

@davidism 가세요. 일요일에 다시 방문하겠습니다. 필요한 경우 검토하겠습니다 :) 감사합니다!

조금 뒤에, 지금 작업 중입니다.

@connorbrinton ast.parse 을 사용하는 멋진 아이디어 , 시도해 보고 함께 간다면 커밋에 공동 작성자로 포함하겠습니다.

사용자를 v19 동작으로 안내하는 다소 인기 있는(그리고 꽤 오래된) 스택 오버플로 답변이 있다는 점에서 차임하고 싶었습니다. 어떤 선택을 했는지에 따라 업데이트가 필요할 수 있습니다: https://stackoverflow.com/questions/ 8495367/using-additional-command-line-arguments-with-gunicorn

마스터에서 고정. 패치에 대해 @davidism 에게 감사드립니다!

처리 모든 경우에이 시험에 있습니다 https://github.com/benoitc/gunicorn/commit/19cb68f4c3b55da22581c008659ee62d8c54ab2b#diff -5832adf374920d75d4bf48e546367f53R67