Using Python 3.7, I made a CLI utility which prints some results to stdout. Depending on an option the results should be visualized in a browser (single user, no sessions). Flask seems to be a good choice for this. However, this is not a standard usecase described in the docs or in tutorials.
I am looking for a best practise way to pass the data (e.g. a Python List) to the Flask app so that I can return it from view functions. Basically it would be immutable application data. The following seems to work but I don't like to use globals:
main.py:
import myapp
result = compute_stuff()
if show_in_browser:
myapp.data = result
myapp.app.run()
myapp.py:
from flask import Flask
from typing import List
app = Flask(__name__)
result: List
#app.route("/")
def home():
return f"items: {len(result)}"
Reading the Flask docs I get the impression I should use an application context. On the other hand, its lifetime does not span across requests and I would not know how to populate it. Reading other questions I might use a Flask config object because it seems to be available on every request. But this is not really about configuration. Or maybe I should use Klein, inspired by this answer?
There does not seem to be a best practice way. So I am going with a modification of my original approach:
class MyData:
pass
class MyApp(Flask):
def __init__(self) -> None:
super().__init__(__name__)
self.env = "development"
self.debug = True
def getData(self) -> MyData:
return self._my_data
def setMyData(self, my_data: MyData) -> None:
self._my_data = my_data
app = MyApp()
This way I can set the data after the app instance was already created - which is necessary to be able to use it in routing decorators defined outside of the class. It would be nice to have more encapsulation: use app methods for routing (with decorators) instead of module global functions accessing a module global app object. Apparently that is not flaskic.
Related
I am trying to abstract away some of the route class logic (i.e. I am looking to dynamically generate routes). api.add_resource seemed like the right place to do this.
So this is what I am trying to do:
# app.py
from flask import Flask
from flask_restplus import Api, Resource, fields
from mylib import MyPost
# Define my model
json_model = api.schema_model(...)
api.add_resource(
MyPost,
'/acme',
resource_class_kwargs={"json_model": json_model}
)
And then in mylib:
# mylib.py
def validate_endpoint(f):
def wrapper(*args, **kwargs):
return api.expect(json_fprint)(f(*args, **kwargs))
return wrapper
class MyPost(Resource):
def __init__(self, *args, **kwargs):
# Passed in via api.add_resource
self.api = args[0]
self.json_model = kwargs['json_model']
# I can't do this because I don't have access to 'api' here...
# #api.expect(json_model)
# So I am trying to make this work
#validate_endpoint
def post(self):
return {"data":'some data'}, 200
I don’t have access to the global api object here so I can’t call #api.expect(json_model). But I do have access to api and json_model inside of the post method. Which is why I am trying to create my own validate_endpoint decorator.
This does not work though. Is what I am trying to do here even possible? Is there a better approach I should be taking?
Stop using flask-restplus. Thats the most valuable answer I can give you (and anyone else).
Ownership is not there
Flask-restplus is a fork of flask-restful. Some engineers started developing features that suited them. The core guy has ghosted the project so its been officially forked again as Flask-Restx.
Poorly designed
I used to love flask when I was a yout’. I’ve realized since then that having global request, application, config that all magically update is not a good design. Their application factory pattern (to which flask-restplus conforms) is a style of statefully mutating the application object. First of all, Its hard to test. Second of all, it means that flask-restplus is wrapping the app and therefore all of the requests/handlers. How can anyone thing thats a good thing? A library whose main feature is endpoint documentation has its filthy hands all over every one of my requests?? (btw, this is whats leading to your problem above) Because my post is serious and thoughtful I’m skipping my thoughts on the Resource class pattern as it would probably push me into the waters of ranting.
Random Feature Set
A good library has a single purpose and it does that single thing well. Flask-restplus does 15 things (masking, swagger generation, postman generation, marshaling, request arg validation). Some features you can’t even tell are in the libraries code by reading the docs.
My solution to your problem
If you want to document your code via function decorators and models use a tool that does that alone and does it well. Use one that won’t touch your handlers or effect your actual request decorators. Use oapispec for swagger generation. For the other features of flask-restplus you’ve got marshmallow for marshaling request/response data, pydantic for validating request objects and args, and so on.
btw, I know all this because I had to build an api with it. After weeks of fighting the framework I forked it, ripped it apart, created oapispec, and trashed it from the project.
I have a Flask app with multiple routes. I have defined an Utility class with few methods to handle the common functionalities, for eg. getting some properties etc. Now I want to create and instance of the Utility class in a common place to be used by functions in each route. How do I achieve this ?
from flask import Flask, request, jsonify
import mysql.connector as mariadb
app = Flask(__name__)
#app.route('/aaa/bbb/ccc',methods=['POST'])
def func1():
pass
#app.route('/xxx/yyy/zzz',methods=['POST'])
def func2():
pass
#app.route('/abc/dfg/ijk',methods=['POST'])
def func3():
pass
class Utility:
def get_properties():
pass
def get_database_conn():
pass
if __name__ == "__main__":
app.run(host='127.0.0.1', port=5000, debug=True)
Now, I want to do something like -
util_obj = Utility()
in the beginning of the app, so that from any of my routes I can call the utility methods without having to create the object every time.
What is the best way to achieve this ?
What you're describing seems to follow the same structure as most extensions to Flask, like Flask-SQLAlchemy or Flask-Caching, namely to have a globally configured instance that you import or call upon when necessary.
In a large scale application, you would create these instances in a file like extensions.py, away from where you create app to avoid circular imports, but in the case of a single file, you don't have to worry about that. Instead, I would simply move the class definition of Utility to just underneath where you define app, and create util_obj right below the class definition.
from flask import Flask, request, jsonify
import mysql.connector as mariadb
app = Flask(__name__)
class Utility:
def get_properties():
# you can access app here!
pass
def get_database_conn():
pass
util_obj = Utility()
#app.route('/aaa/bbb/ccc',methods=['POST'])
def func1():
# you can access util_obj here!
pass
#app.route('/xxx/yyy/zzz',methods=['POST'])
def func2():
pass
#app.route('/abc/dfg/ijk',methods=['POST'])
def func3():
pass
if __name__ == "__main__":
app.run(host='127.0.0.1', port=5000, debug=True)
I'm trying to use the wonder apscheduler in a pyarmid api. The idea is to have a background job run regularly, while we still query the api for the result from time to time. Basically I use the job in a class as:
def my_class(object):
def __init__(self):
self.current_result = 0
scheduler = BackGroundScheduler()
scheduler.start()
scheduler.add_job(my_job,"interval", id="foo", seconds=5)
def my_job():
print("i'm updating result")
self.current_result += 1
And outside of this class (a service for me), the api has a POST endpoint that returns my_class instance's current result:
class MyApi(object):
def __init__(self):
self.my_class = MyClass()
#view_config(request_method='POST')
def my_post(self):
return self.my_class.current_result
When everything runs, I see the prints and incrementation of value inside the service. But current_result stays as 0 when gathered from the post.
From what I know of the threading, I guess that the update I do is not on the same object my_class but must be on a copy passed to the thread.
One solution I see would be to update the variable in a shared intermediate (write on disk, or in a databse). But I wondered if that would be possible to do in memory.
I manage to do exactly this when I do this in a regular script, or with one script and a very simple FLASK api (no class for the API there) but I can't manage to have this logic function inside the pyramid api.
It must be linked to some internal of Pyramid spawning my api endpoint on a different thread but I can't get right on the problem.
Thanks !
=== EDIT ===
I have tried several things to solve the issue. First, the instance of MyClass used is intitialized in another script, follow a container pattern. That container is by default contained in all MyApi instances of pyramid, and supposed to contain all global variables linked to my project.
I also define a global instance of MyClass just to be sure, and print its current result value to compare
global_my_class = MyClass()
class MyApi(object):
def __init__(self):
pass
#view_config(request_method='POST')
def my_post(self):
print(global_my_class.current_result)
return self.container.my_class.current_result
I check using debug that MyClass is only spawned twice during the api execution (one for the global variable, one inside the container. However.
So what I see in logging are two values of current_result getting incremented, but at each calls of my_post I only get 0s.
An instance of view class only lives for the duration of the request - request comes in, a view class is created, produces the result and is disposed. As such, each instance of your view gets a new copy of MyClass() which is separate from the previous requests.
As a very simple solution you may try defining a global instance which will be shared process-wide:
my_class = MyClass()
class MyApi(object):
#view_config(request_method='POST')
def my_post(self):
return my_class.current_result
I'm trying to catch the flow_finished signal from django viewflow like this
flow_finished.connect(function)
but it's not working. The function isn't called even if the flow finishes.
Any help please, I'm pretty lost.
In my app's init.py I added this
from django.apps import AppConfig
default_app_config = 'test.TestConfig'
class TestConfig(AppConfig):
name = 'test'
verbose_name = 'Test'
def ready(self):
import viewflow.signals
First, you need to ensure that you properly configured you app config, and the ready method really been called. Check your installed apps that you properly included your TestConfig, or if you use shortcuts, check you test/__init__.py default_app_config value
from viewflow.signals import flow_finished
def receiver(sender, **kwargs):
print('hi')
class TestConfig(AppConfig):
name = 'test'
def ready(self):
flow_finished.connect(receiver)
But generally, using signals to weave your codebase is a bad taste. To call an action before flow.End you can explicitly add flow.Handler. That's the recommended solution.
We are extending the Flask-cli with some custom commands. The command test is one of them:
# run.py: specified by FLASK_APP
# This is the Flask application object
app = create_app(os.getenv('FLASK_ENV') or 'default')
#app.cli.command()
def test():
"""Run the unit tests."""
tests = unittest.TestLoader().discover('tests')
test_runner = unittest.TextTestRunner()
test_runner.run(tests)
However a typical test (using Python's built-in unittest module) looks like
this which is based on the style described here.
# some-tests.py: unittest-based test case.
class SomeTestCase(unittest.TestCase):
def setUp(self):
self.app = create_app('testing')
self.app_context = self.app.app_context()
self.app_context.push()
def tearDown(self):
self.app_context.pop()
def test_load(self):
pass
I am clearly hitting an anti-pattern here: I have initialized a flask object with the default(development) configuration because I need it for the #app.cli.command() decorator which all happens in run.py. However once I run the test setUp function in some-tests.py I somehow have to obtain a Flask object utilizing the testing configuration, e.g. by recreating a Flask app with the testing configuration like what happens now.
I would like to have pointers on how one goes about to implement a flask-cli test command in which only one Flask object is created which is reused amongst the various test cases without having the need of explicitely setting the environment to testing before I run flask test on the command line.
I'm not sure if this answer will suit your requirements but that is how I would try to approach this problem. Unfortunately, if you want to use default CLI interface in Flask than you need to call create_app just to call flask test command. What you can do is try use pytest. It allows you to create fixtures that can be used across multiple test cases. For example, in your tests package create file named conftest.py and declare some default fixtures like this:
#pytest.fixture
def app():
return create_app('testing')
#pytest.fixture
def client(app):
return app.test_client()
#pytest.fixture
def database(app):
_db.app = app
with app.app_context():
_db.create_all()
yield _db
_db.session.close()
_db.drop_all()
Then in your test case file (ex. test_login.py) you can use those fixtures like this:
# Notice argument names are the same as name of our fixtures
# You don't need to import fixtures to this file - pytest will
# automatically recognize fixtures for you
def test_registration(app, client):
response = client.post(
'/api/auth/login',
json={
'username': 'user1',
'password': '$dwq3&jNYGu'
})
assert response.status_code == 200
json_data = response.get_json()
assert json_data['access_token']
assert json_data['refresh_token']
The best thing about this approach is that you don't need to create setUp and tearDown methods. Then you can create test cli command for your app:
import pytest
#app.cli.command()
def test():
'''
Run tests.
'''
pytest.main(['--rootdir', './tests'])
And call it like this flask test.