Perché la beuta CLI è consigliata su Flask.run?

Question

Perché la beuta CLI è consigliata su Flask.run?

#1 da (7 voti)

8

In Flask 0.11 è stata introdotta una flask CLI. Sia il documento che lo stato del registro delle modifiche sono consigliati.

Documenti del server di sviluppo :

Starting with Flask 0.11 there are multiple built-in ways to run a development server. The best one is the flask command line utility but you can also continue using the Flask.run() method.

Command Line

The flask command line script (Command Line Interface) is strongly recommended for development because it provides a superior reload experience due to how it loads the application. The basic usage is like this:
$ export FLASK_APP=my_application
$ export FLASK_DEBUG=1
$ flask run

Registro delle modifiche :

Added flask and the flask.cli module to start the local debug server through the click CLI system. This is recommended over the old flask.run() method as it works faster and more reliable due to a different design and also replaces Flask-Script.

Finora non ho notato questa "esperienza di ricarica superiore". Non riesco a vedere il punto di usare la CLI su uno script personalizzato.

Se si utilizza Flask.run , scriverei semplicemente un file python:

#!/usr/bin/env python3
from my_app import app


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

Se si utilizza la CLI, è necessario specificare le variabili di ambiente. Nel documento CLI si afferma che questo può essere integrato nello script activate di virtualenvwrapper. Personalmente ritengo che questo sia parte dell'applicazione e penso che dovrebbe essere sotto controllo della versione. Ahimè, è necessario uno script di shell:

#!/usr/bin/env bash
export FLASK_APP=my_app:app
export FLASK_DEBUG=1

flask run

Naturalmente questo sarà accompagnato da uno script bat aggiuntivo non appena tutti gli utenti di Windows iniziano a collaborare.

Anche la prima opzione consente l'installazione scritta in Python prima di avviare l'app effettiva.

Questo consente ad esempio

per analizzare gli argomenti della riga di comando in Python
per configurare la registrazione prima di eseguire l'app

Sembrano promuovere che è possibile aggiungere comandi personalizzati. Non riesco a capire perché è meglio che scrivere semplici script Python, opzionalmente esposti attraverso i punti di ingresso.

Esempio di output di registrazione quando si utilizza un logger configurato utilizzando lo script di esecuzione Python:

$ ./run.py 
   DEBUG 21:51:22 main.py:95) Configured logging
    INFO 21:51:22 _internal.py:87)  * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
    INFO 21:51:22 _internal.py:87)  * Restarting with inotify reloader
   DEBUG 21:51:22 main.py:95) Configured logging
 WARNING 21:51:22 _internal.py:87)  * Debugger is active!
    INFO 21:51:22 _internal.py:87)  * Debugger pin code: 263-225-431
   DEBUG 21:51:25 inotify_buffer.py:61) in-event <InotifyEvent: src_path=b'my_app/main.py', wd=272, mask=IN_MODIFY, cookie=0, name=b'main.py'>
   DEBUG 21:51:25 inotify_buffer.py:61) in-event <InotifyEvent: src_path=b'my_app/main.py', wd=272, mask=IN_MODIFY, cookie=0, name=b'main.py'>
    INFO 21:51:25 _internal.py:87)  * Detected change in 'my_app/main.py', reloading
    INFO 21:51:26 _internal.py:87)  * Restarting with inotify reloader
   DEBUG 21:51:26 main.py:95) Configured logging
 WARNING 21:51:26 _internal.py:87)  * Debugger is active!
    INFO 21:51:26 _internal.py:87)  * Debugger pin code: 263-225-431

Esempio di output di registrazione quando si utilizza un logger configurato utilizzando la CLI :, si noti che il root logger non può essere configurato abbastanza presto nel processo.

$ ./run.sh 
 * Serving Flask app "appsemble.api.main:app"
 * Forcing debug mode on
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
 * Restarting with inotify reloader
   DEBUG 21:51:33 main.py:95) Configured logging
 * Debugger is active!
 * Debugger pin code: 187-758-498
   DEBUG 21:51:34 main.py:95) Configured logging
   DEBUG 21:51:37 inotify_buffer.py:61) in-event <InotifyEvent: src_path=b'my_app/main.py', wd=272, mask=IN_MODIFY, cookie=0, name=b'main.py'>
   DEBUG 21:51:37 inotify_buffer.py:61) in-event <InotifyEvent: src_path=b'my_app/main.py', wd=272, mask=IN_MODIFY, cookie=0, name=b'main.py'>
 * Detected change in 'my_app/main.py', reloading
    INFO 21:51:37 _internal.py:87)  * Detected change in 'my_app/main.py', reloading
 * Restarting with inotify reloader
    INFO 21:51:38 _internal.py:87)  * Restarting with inotify reloader
 * Debugger is active!
 * Debugger pin code: 187-758-498
   DEBUG 21:51:38 main.py:95) Configured logging

La mia domanda attuale è semplicemente:

Perché la CLI del pallone è consigliata su Flask.run ?

python flask

posta Remco Haszing 03.08.2016 - 22:18

fonte

1 risposta

Leggi altre domande sui tag python flask

JavaScript per un non programmatore [chiuso] Come si fa a fare una stima dei core CPU necessari e della memoria dalle specifiche?

score 7 · Accepted Answer

Nei documenti del server di sviluppo, affermano che ci sono problemi con la chiamata run () e il caricamento automatico del codice:

This works well for the common case but it does not work well for development which is why from Flask 0.11 onwards the flask method is recommended. The reason for this is that due to how the reload mechanism works there are some bizarre side-effects (like executing certain code twice, sometimes crashing without message or dying when a syntax or import error happens).

Affermano che la CLI non soffre di questo problema.

Il primo commit che sembra toccare questo problema è questo: link

E lì Armin Ronacher ha scritto:

It is not recommended to use this function for development with automatic reloading as this is badly supported. Instead you should be using the flask command line script's runserver support.

Come accennato da Aaron Hall, sembra che l'uso di run () potrebbe essere problematico a causa del fatto che tutti gli oggetti che sono istanze di classi definite nei moduli che vengono sostituiti non verranno ristestati, e ogni volta che un modulo è ricaricato, i moduli che importa non vengono ricaricati pure.

I dettagli su questo possono essere trovati per Python 3 in: link

Dichiara:

As with all other objects in Python the old objects are only reclaimed after their reference counts drop to zero.

Other references to the old objects (such as names external to the module) are not rebound to refer to the new objects and must be updated in each namespace where they occur if that is desired.

When a module is reloaded, its dictionary (containing the module’s global variables) is retained. Redefinitions of names will override the old definitions, so this is generally not a problem. If the new version of a module does not define a name that was defined by the old version, the old definition remains.

Quindi, creando un nuovo processo e uccidendo quello vecchio, si eliminano naturalmente tutti i riferimenti obsoleti.

Inoltre, la CLI di Flask utilizza il modulo "clic", rendendo molto facile l'aggiunta di comandi personalizzati, ma soprattutto, oltre a correggere il bug di ricarica, la CLI offre un modo standard per eseguire applicazioni e aggiungere comandi personalizzati. Sembra una cosa molto buona, perché rende la familiarità con Flask più trasferibile tra diversi team e applicazioni, piuttosto che avere più modi di fare la stessa cosa.

Sembra un modo genuino per rendere Flask più conforme allo Zen di Python:

There should be one-- and preferably only one --obvious way to do it.