create_app twice? about overholt HOT 5 CLOSED

@joshpurvis THANK YOU SO MUCH :) I was wondering if there was a better way, but I think you have the best way. If you want more granularity to specify which one uses the task, I got it working be the methods below. It digs straight into the python files or the method/route

I also the same problem. But I think you can do:

from flask import current_app
if current_app: # if current app instance exists
   from path.to.task import task

OR

def some_function(arg1,arg2):
    from path.to.task import task
    task.delay(arg1,arg2)

Cheers!

from overholt.

I'm a little confused about this too. When I try the steps listed in the setup, I get an import error upon trying to run alembic upgrade head. It appears that there is a circular dependency: create_app tries to register all the blueprints, and the blueprints import celery tasks from tasks.py. The celery instance in tasks.py is created by calling create_celery_app, which then calls create_app again. Is there a good way around this? Thanks

from overholt.

I was going to fork this and apply a hacky workaround, but I don't have the time to test it and the author might not want that. Anyway, given that I was experiencing the same problem with flask + celery 3 in my own app structure, I figured I'd share my workaround for the next person who googles and lands here.

First, modify create_app to include a new argument which toggles blueprints registration:

def create_app(register_blueprints=True):
    app = Flask(__name__)
    # ...
    if register_blueprints:
        from myblueprint.views import bp as myblueprint
        app.register_blueprint(myblueprint)

Next in create_celery_app, send register_blueprints=False so that we don't try to register them when celery requests an app, thus dodging the circular dependencies:

def create_celery_app(app=None):
    app = app or create_app(register_blueprints=False)
    # ...

This worked on my app structure with Celery 3.1.8. Hopefully this helps someone avoid the many hours I wasted dicking around with celery. If there's a better solution than this, I'd be happy to know.

from overholt.

@joshpurvis Thats probably the best thing to do when it comes to the Celery app. There is not really any reason to have all the views/routes attached to the application in the context of the Celery app. At this point, the app just acts as a configuration and context lifecycle helper.

from overholt.

@mattupstate can you update your celery example code to incorporate the changes from @joshpurvis (or your take on a fix for this)? I've spent some time working around the circular dependency that this project has, and the solution posted here works well. It would be helpful if this was in the project itself to save others from having to find or create a solution themselves.

from overholt.