do not use dbs.task_api, use dbs.tasks directly

[misli]

There is no reason for this layer.
The tasks in dbs.tasks should be complex enough to be called directly from dbs.api.views or dbs.management.commands.

[TomasTomecek]

I disagree.

1. you can do that already
2. if we ditch task_api, you have to take care of celery stuff on server (.apply_async() and whatever else will be needed in future): why would you want that? right now, celery stuff is hidden behind python api
3. with current implementation (running callback when task finishes), it wouldn't be possible call these callbacks anymore; instead, we would have to implement another rest api call in server for submitting results (together with worker authentication -- we don't have to authenticate anything with callbacks)

Since we are still in proof-of-concept state, I don't think this issue is really important. It's just implementation. Once we leave PoC state, we can discuss it and agree on something.

[misli]

1. if we ditch task_api, you have to take care of celery stuff on server (.apply_async() and whatever else will be needed in future): why would you want that? right now, celery stuff is hidden behind python api

It is not "on server" it is "in dbs" - worker, server, commandline interface, they are all part of the same dbs. There is no celery stuff, there is just dbs stuff. No need to have python api between left and right hand. Nohting to hide.

1. with current implementation (running callback when task finishes), it wouldn't be possible call these callbacks anymore; instead, we would have to implement another rest api call in server for submitting results (together with worker authentication -- we don't have to authenticate anything with callbacks)

The current implementation of callbacks is bad designed and if we don't throw it away now, we will do it in the future. Relying on theese callbacks is pure waste of time.
We do not need any new rest api call, because the task itself is part of dbs and is able to call any function dbs provides.

Since we are still in proof-of-concept state, I don't think this issue is really important. It's just implementation. Once we leave PoC state, we can discuss it and agree on something.

No, we should discuss now. As I said before, building something (including PoC) on top of something what is already known to be bad designed, is waste of time.

[TomasTomecek]

So... we'll have django code in celery stuff, is that right? Testing that thing will be a real bliss -- I'm going to need server with database just to smoke test some tasks. Until now, worker could run by itself easily without need of running server.

[misli]

So... we'll have django code in celery stuff, is that right? Testing that thing will be a real bliss -- I'm going to need server with database just to smoke test some tasks.

There is no django code, nor celery stuff. There is even no server and no worker (and fortunately no smoke yet).
It is just common django application (which is obviously made of python code).
Sou you don't need server with database to test some smoke tasks.
You need the django application you want to test, if you want to test one. And that makes sense.

Until now, worker could run by itself easily without need of running server.

You may still simply test any task without running server. Task is yet another function, which you may call directly or asynchronously from view, from command, or from any application written in python.