create_app twice?

[rubensayshi]

Hey, this is an issue I've been running into myself and trying to research it a bit I ran into your pretty nice base project!

to be able to give functions the annotation @celery.task we need to be able to import the celery = Celery() instance from somewhere.
but to tie it together with all the Flask related stuff we want to be in app context (and I want to use the config from my app for some celery stuff too) so we need an instance of the app.
so you create that instance when creating the Celery instance ( I do the same in my project ).

but this results in doing more create_app calls (or at least 1 more) when importing tasks to queue them from your blueprints.
The thing is .. I'm not sure if it matters ... but it feels wrong ...

Just putting it here to discuss, hope you don't mind

[sixpi]

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

[joshpurvis]

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.

[mattupstate]

@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.

[skyler]

@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.

[rlam3]

@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!