Concern about deprecation of the Worker class

[lhupfeldt]

I think deprecation of the Worker class may be a step in the wrong direction.
We use the api to update around 150 subprojects. This is quite slow, and removing the Worker class would remove the possibility for some optimizations.
When we update using the api we always update all subprojects to the exact same template version. Having the Worker class allows (would allow) copier to only clone and expand the new template once.

[sisp]

From my perspective, the Worker class is a historically grown monolith that mixes several concerns which slows down development progress and makes some features and bug fixes hard to implement. My goal is breaking the Worker class up into well-defined classes with clear scopes. For example, the update algorithm currently relies on the generation of fresh projects based on the old and new template versions, so with a different architecture an updater class could use a generator class to produce the two fresh projects – but a potential future update algorithm might fetch a fresh copy based on the old template version from some kind of cache, which I imagine to be just a different implementation of the generator class satisfying the same interface.

Deprecating the Worker class doesn't mean giving up a stateful object that holds a reference to a cloned template, which is what I believe you're concerned about. In fact, I'd even like to avoid repeated cloning of the same template repo at some point – but that's not anywhere near the top of my list for now.

I think the Worker class will need to go away at some point, but a more modular, more flexible alternative will take its place.

[lhupfeldt]

Great. I was exactly concerned about giving up the stateful object.
The deprecation seems a little premature. Rewriting a script using the Worker class now would mean using the run_... methods, så another rewrite would be necessary when you release the rewrite.