feat: adds bundle/content deploy and task management #183
Conversation
tdstein
force-pushed
the
tdstein/110-bundle-deploy
branch
2 times, most recently
from
a7161f1 to
8fb8e09
Compare
tdstein
force-pushed
the
tdstein/110-bundle-deploy
branch
from
8fb8e09 to
18da02e
Compare
☂️ Python Coverage
Overall Coverage
New Files
Modified Files
|
tdstein
force-pushed
the
tdstein/110-bundle-deploy
branch
from
027f722 to
780ca20
Compare
tdstein
force-pushed
the
tdstein/110-bundle-deploy
branch
from
780ca20 to
e705541
Compare
src/posit/connect/tasks.py
Outdated
| None | ||
| """ | ||
| while not self.is_finished: | ||
| self.update(wait=sleep) |
There was a problem hiding this comment.
I know the API supports this, but it's odd to me that we'd push the sleep to the server. I.e. with wait_for(5), each request is going to take 5 seconds to respond. Seems odd to consume server resources for that waiting. Why not do the sleeping on the client side and always send wait=0 (which is the default anyway)?
The other thing you might do is pass the first argument, set to len(self.output) so that you're only returning newly generated lines of log output. You'd have to do something different than just super().update(**result) with that, have to be sure to append output and update the rest. But I could see that for a large task (IDK, lots of package installation output), not fetching all lines every time could be important.
There was a problem hiding this comment.
I had the same reaction when developing this. The one advantage of the current implementation is that the API will return once the task is finished. So, if you call with wait=60, the method will return in less than 60 seconds if the task finishes.
But I also agree. It seems like an anti-pattern to consume server threads waiting for the task to complete.
Co-authored-by: Neal Richardson <[email protected]>
Resolves #110
Resolves #111
Resolves #112