Por que a execução do servidor de desenvolvimento do Flask é executada duas vezes?

Estou usando o Flask para desenvolver um site e, durante o desenvolvimento, executo o flask usando o seguinte arquivo:

#!/usr/bin/env python
from datetime import datetime
from app import app
import config

if __name__ == '__main__':
    print '################### Restarting @', datetime.utcnow(), '###################'
    app.run(port=4004, debug=config.DEBUG, host='0.0.0.0')

Quando eu inicio o servidor ou quando ele reinicia automaticamente porque os arquivos foram atualizados, ele sempre mostra a linha de impressão duas vezes:

################### Restarting @ 2014-08-26 10:51:49.167062 ###################
################### Restarting @ 2014-08-26 10:51:49.607096 ###################

Embora não seja realmente um problema (o resto funciona conforme o esperado), eu simplesmente me pergunto por que ele se comporta assim? Alguma ideia?

O recarregador Werkzeug gera um processo filho para que possa reiniciar esse processo sempre que seu código for alterado. Werkzeug é a biblioteca que fornece ao Flask o servidor de desenvolvimento quando você chama app.run().

Veja o restart_with_reloader()código da função ; seu script é executado novamente com subprocess.call().

Se você definir use_reloadercomo, Falseverá o comportamento desaparecer, mas também perderá a funcionalidade de recarregamento:

app.run(port=4004, debug=config.DEBUG, host='0.0.0.0', use_reloader=False)

Você também pode desativar o recarregador ao usar o flask runcomando:

FLASK_DEBUG=1 flask run --no-reload

Você pode procurar a WERKZEUG_RUN_MAINvariável de ambiente se quiser detectar quando está no processo filho de recarregamento:

import os
if os.environ.get('WERKZEUG_RUN_MAIN') == 'true':
    print '################### Restarting @ {} ###################'.format(
        datetime.utcnow())

No entanto, se você precisa configurar globais de módulo, então você deve usar o @app.before_first_requestdecorador em uma função e fazer com que essa função configure tais globais. Ele será chamado apenas uma vez após cada recarga, quando a primeira solicitação chegar:

@app.before_first_request
def before_first_request():
    print '########### Restarted, first request @ {} ############'.format(
        datetime.utcnow())

Leve em consideração que se você executar isso em um servidor WSGI em escala real que usa bifurcação ou novos subprocessos para lidar com solicitações, esses before_first_requestmanipuladores podem ser chamados para cada novo subprocesso.

Se você estiver usando o flask runcomando moderno , nenhuma das opções a app.runserá usada. Para desativar o recarregador completamente, passe --no-reload:

FLASK_DEBUG=1 flask run --no-reload

Além disso, __name__ == '__main__'nunca será verdade porque o aplicativo não é executado diretamente. Use as mesmas ideias da resposta de Martijn , mas sem o __main__bloqueio.

if os.environ.get('WERKZEUG_RUN_MAIN') != 'true':
    # do something only once, before the reloader

if os.environ.get('WERKZEUG_RUN_MAIN') == 'true':
    # do something each reload

Eu tive o mesmo problema e resolvi definindo app.debugcomo False. Definir como Trueestava fazendo com que eu __name__ == "__main__"fosse chamado duas vezes.

No Flask 0.11, é recomendado executar seu aplicativo com, em flask runvez de python application.py. Usar o último pode resultar na execução de seu código duas vezes.

Conforme declarado aqui :

... do Flask 0.11 em diante, o método do frasco é recomendado. A razão para isso é que, devido à forma como o mecanismo de recarga funciona, existem alguns efeitos colaterais bizarros (como executar determinado código duas vezes ...)

Um dos possíveis motivos para o aplicativo Flask rodar sozinho duas vezes é uma configuração de WEB_CONCURRENCYconfiguração no Heroku. Para configurar em um, você pode escrever no console heroku config:set WEB_CONCURRENCY=1

Uma observação sobre tópicos

Isso é particularmente irritante quando seu aplicativo usa threads, pois eles serão disparados duas vezes na inicialização. Pelo que eu tentei, os singletons também não corrigiram isso (o que é surpreendente). No entanto, adicionar um atraso inicial de alguns segundos antes do início do thread pode resolver o problema.

Se o aplicativo for reiniciado mais rápido do que antes de seu período de atraso terminar, o thread fornecido é gerado apenas uma vez, após a reinicialização.

Eu tive o mesmo problema. Eu resolvi isso modificando meu principal e inserindo use_reloader = False nele. Se alguém estiver aqui procurando uma solução alternativa para este problema, o código abaixo o ajudará a começar, entretanto, a funcionalidade de alterações no código detectadas automaticamente e reiniciar o aplicativo não funcionará. Você terá que parar e reiniciar manualmente seu aplicativo após cada edição no código.

if __name__ == '__main__':
    app.run(debug=True, use_reloader=False)