I’ve looked at the engine architecture and have a couple of concerns. Current engine

Engine

class don’t look like a good place to add multithreaded/distributed functionality. It’s almost don’t have a state (all state in the scheduler actually). Which led to the question - if actually

scheduler

will be the place where ‘engine’ lives we need to reify and extract actual

scheduler

api. From current code perspective

Selector

, all `State`s,

Node

,

BuildRequest

,

Promise

looks like actual api for scheduler (both from task implementing side and client usage side) while classes like

DependenciesNode

or

SelectProjection

looks like something which should be implemented atop of the api, just like other user code, maybe just more common. So maybe it’s reasonable to merge

engine.py

and

scheduler.py

and extract more refined api? More exactly: engine is something you can build from product factories (Selectors/Nodes/etc here) and ask for products. It will manage execution planning & somehow caching. Current implementation will go to one concrete engine implementation with different executors (serial & multithreaded). Thoughts?