More class, less dangling methods

The more I hack into copier, the more I see the code is structured weirdly.

It seems like copier is thought as a library which also lets CLI usage, instead of the other way around.

Since #106, we leverage Plumbum for the CLI stuff, and it feels way more pythonic and comfortable to write it like this.

Now, the CopierApp class and its friends feature the invoke() method, which should be just enough to let downstream to use Copier as a lib in other python codebases.

If we refactor the codebase to make it more focused on that, we will save the pain to keep on passing arguments here and there. We will easily know if we’re updating or copying, know if the user forced the execution, and so on.

---

This is my mind map about what the new object model would be and what information could be obtained from each object:

• Answer: what has been responded to a question. It can be obtained from asking the user, from API call, last answers in the Subproject, or defaults from the Question (which may be templated). It returns the best match for each Question.
• Question: contains a question definition. It is obtained from the Template. Each question is related to an answer
• Questionary: contains all questions and helpers to ask to the user.
• Template: available versions, the questionary, local clone location, options defined in the template.
• Subproject: is repo? is dirty? last update version, last answers, local path, folder exists?
• Settings: the evolution of ConfigData. It won’t require passing through make_config() (I always thought that’s a weird design). It will hold references to all external settings sources (which are the Template, and the API call, and after #235 it will also be user config file). It will not hold answers data.
• Renderer: takes care of rendering the files to disk.
• Worker: combines all other objects and has 2 main methods: copy() and update().

[pykong]

The more I hack into copier, the more I see the code is structured weirdly.

It seems like copier is thought as a library which also lets CLI usage, instead of the other way around.

I am not sure I can concur, still I am committed to maximum code quality and hence I am open for improvements even radical refactoring required it makes sense.

the pain to keep on passing arguments here and there.

Carrying the extensive signatures around is indeed a major pain point which I could not tackle via my last big refactoring.

TL/DR: I am open to suggestions/PR. Ideally those should be made/merged before I am going to work on #79 again which could happen in the coming weeks.

[yajo]

Yes, I know, that’s exactly the point in this issue. The code is hard to maintain as it is right now. Also, it’s impossible to know if an answer comes from .copier-answers.yml, from CLI or from user input, which makes it hard to implement things as “don’t ask me if I already answered”.

This needs a massive refactoring. Luckily, our test suite is big enough to warn us about any problems introduced.

I’d be glad to finish #173 before starting this task, but this one has to go for v4.