Feat: Adding force_overwrite config option.

[andrew-glenn]

This PR adds the force_overwrite config option, which allows template authors more granularity in how their templates are consumed downstream.

The intended use case (and reason for this PR) is the ability to centralize core information, such as license info, legal notices, code of conduct, etc. With this PR, copier will force-overwrite the content of the given files in the downstream consumer repository, without prompting.

This is considered a relative edge case, but is critical for situations where more granularity is required.

Edit to add: this differs from the existing overwrite functionality, which indiscriminately overwrites without prompting. This adds pattern matching, allowing more flexibility

[yajo]

Thanks for the contribution!

I'm not sure I like this feature. I think it's the user who must decide if files should or not be overwritten. Why would the template designer choose that? 🤔

[codecov-commenter]

Codecov Report

Merging #733 (fb0e20d) into master (17ca2ed) will decrease coverage by 12.36%. The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           master     #733       +/-   ##
===========================================
- Coverage   96.63%   84.27%   -12.37%     
===========================================
  Files          41       42        +1     
  Lines        2915     2988       +73     
===========================================
- Hits         2817     2518      -299     
- Misses         98      470      +372     

Flag	Coverage Δ
unittests	84.27% <100.00%> (-12.37%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
copier/main.py	94.87% <100.00%> (+0.44%)	:arrow_up:
copier/template.py	98.02% <100.00%> (+0.02%)	:arrow_up:
tests/test_force_overwrite.py	100.00% <100.00%> (ø)
tests/test_prompt.py	13.09% <0.00%> (-76.20%)	:arrow_down:
tests/test_complex_questions.py	30.72% <0.00%> (-69.28%)	:arrow_down:
tests/test_tools.py	64.00% <0.00%> (-28.00%)	:arrow_down:
tests/test_templated_prompt.py	72.13% <0.00%> (-27.87%)	:arrow_down:
copier/user_data.py	70.27% <0.00%> (-23.66%)	:arrow_down:
tests/conftest.py	72.72% <0.00%> (-22.28%)	:arrow_down:
copier/cli.py	85.88% <0.00%> (-10.59%)	:arrow_down:
... and 6 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[andrew-glenn]

In my use-case, there are certain files that need to be fully managed by the upstream template. Examples would be a software license, legal notices, etc.

A user could choose to change the software license of a repo, which has significant implications for both the project, and the company that's providing the repository for public consumption.

A more concrete example would be the open-source "department" (for lack of a better term) of BigCorp Inc. Management decides that all repositories must have an Apache2.0 license. The hope / intention was to use copier as a way to enforce this policy.

Thinking about the bigger purpose and scope of the copier project, I would have the same opinion in your position as a maintainer. I think this may be better suited for a post-migration strategy. Assuming that's the case, I think a secondary PR is needed to make certain private methods public so they can be used in a post-migration script.

Looking forward to your thoughts.

[yajo]

The case that you mention seems to be better fixed with:

1. Multiple templates. This is already supported by copier. One template for legal stuff, another for the normal project lifecycle. This way, updating the normal project will never touch legal files, and vice-versa.
2. CODEOWNERS file. This is supported by github and gitlab. Blocks changes into certain files by unauthorized users. It would forbid non-legal users from changing legal files.

See https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners and https://docs.gitlab.com/ee/user/project/code_owners.html

WDYT?

[andrew-glenn]

Anticipating that it wouldn't be good fit for upstream, I've accomplished what I need via wrapping the Worker class, invoking it twice, and playing with excludes.