Re: [BuildStream] Responsive, but not overly verbose UX - not-in-scheduler

[William Salmon <will salmon codethink co uk>]

On 18/04/2019 14:59, Daniel Silverstone via buildstream-list wrote:
> On Thu, Apr 18, 2019 at 17:22:02 +0900, Tristan Van Berkom via buildstream-list wrote:
> [snip]
> >    * Have the Loader trigger a callback mentioning that it requires a
> >      fetch operation (or multiple fetch operations) to be performed.
> >
> >    * Stream run the scheduler on it's behalf to fetch the junction
> If this essentially means we start the scheduler always and treat all longer
> running operations semi-equally, then I think it could be an interesting way to
> implement the goal of my proposal.  I didn't want to suggest it because the
> scheduler seemed so focussed on progressing fully realised elements from one
> end of a semi-rigid pipeline to the other.
When I first started working on buildstream there used to be some 
commands in `_frontend/cli.py` that did not use `with app.initialized()` 
or could do some work before calling it. This is no longer the case 
apart from the odd bit of command line parsing, almost all of the code 
is now in context mangers of `app.initialized`.

This change make sense as the commands have become smarter and more 
aware of the project as they have been improved. However now that 
everything uses `with app.initialized` and as Daniel has pointed out it 
can be a big bottle neck, it has resulted in even very simple commands 
needing to spend a long time setting up and then only a tiny amount of 
time doing their task.

While this area of code is being re-factored I wonder if we could think 
about if everything that `app.initialized` dose is needed for every 
command? I suspect that it dose but if it dose not we may be able to 
return some of the snappiness of the the simple `fast` commands that 
have all be slowed by having to run a full `app.initialized`.

I think the ideal would be that `app.initialized` was really fast and 
that all the commands used it in full but as that dose not seem likely 
in the short term it might be worth having a quick think about making 
parts optional.

I am not sure if this is a goer but I thought it was worth mentioning.

Will