Why does resume halt unspecified system keys?

[dimovich]

What is the best approach when suspending/resuming only changed keys, leaving untouched the other unchanged keys.

Currently resume will halt unspecified keys:
https://github.com/weavejester/integrant/blob/master/src/integrant/core.cljc#L469

Maybe I'm missing something behind the design decisions?

For the moment this is the approach that works for my use case:

(merge
 (apply dissoc system changed-keys)
 (resume config (select-keys system changed-keys) changed-keys))

Thanks!

[weavejester]

resume halts keys so that suspend/resume produces the same result as halt/init.

You'll need to explain why you want to partially suspend/resume.

[dimovich]

I have this config:

{:proj/schedule [[1 :m some-task-fn]
                 [2 :m other-task-fn]]
 :proj/data ["some" "long" "loading" "files"]}

I update the config by changing the :proj/schedule opts:

{:proj/schedule [[1 :m some-task-fn]
                 [3 :m other-task-fn]] ;; <- changed
 :proj/data ["some" "long" "loading" "files"]}

So now I suspend and resume :proj/schedule to reflect the config changes. I don't see why :proj/data should also be restarted instead of being left as is.

I need to use resume so I can compare the new config with the running system and re-schedule only the changed tasks, while leaving the others running.

It makes sense that init will return a system with only the specified keys, but in the case of resume we are talking about a running system that could have had only some of its keys suspended.

[weavejester]

Manually choosing which keys to suspend/resume is not a use-case I want to support. It's more reliable to restart everything, and the suspend/resume system allows components with similar configurations to be reused.

[dimovich]

Thank you for the comment.