Func to fixup existing pkg

[pat-alt]

Trying to reanimate #288 here to add support for a fixup function. I've tried to address the suggestions made here:

I'd kind of like to not rely on Git. Obviously > 90% of packages generated with PkgTemplates are also Git repos but it's not a guarantee. I think maybe we could just back up the current state to a temp directory, print out a message saying "hey we're about to potentially overwrite a bunch of files, they're all backed up here, do you want to proceed?", and then if yes just write the files ignoring any current contents. Git users can then look at their diffs to see what changed. Maybe there could also be some check for "if it's already a Git repo, require that it's clean".

Additions

1. The fixup function now backs up the current state of the package in a temporary directory, instead of solely relying on Git.
2. A similar approach is taken to deal with an already existing README file: the old file is maintained and a new file that complies with the template used in fixup is added with a _fixed.md suffix. The user will receive an info message that they may need to move contents from the existing README into the new one and then overwrite the existing file with the new file.
3. Other changes are just formatting (JuliaFormatter.format("src")).

Point (2) is clearly not optimal: ideally fixup would overwrite/add whatever is necessary to comply with the new template and keep existing content. I am not sure this can be done though and personally think it would be better to have mediocre fixup functionality than none at all?

[codecov]

Codecov Report

Attention: Patch coverage is 61.81818% with 42 lines in your changes missing coverage. Please review.

Project coverage is 90.19%. Comparing base (a007c9e) to head (62f9ed4).

Files	Patch %	Lines
src/fixup.jl	0.00%	18 Missing ⚠️
src/plugins/git.jl	25.00%	6 Missing ⚠️
src/plugins/readme.jl	63.63%	4 Missing ⚠️
src/interactive.jl	87.50%	2 Missing ⚠️
src/plugins/documenter.jl	75.00%	2 Missing ⚠️
src/plugins/formatter.jl	0.00%	2 Missing ⚠️
src/plugins/license.jl	50.00%	2 Missing ⚠️
src/plugins/project_file.jl	50.00%	2 Missing ⚠️
src/PkgTemplates.jl	50.00%	1 Missing ⚠️
src/plugin.jl	88.88%	1 Missing ⚠️
... and 2 more

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #483      +/-   ##
==========================================
- Coverage   94.33%   90.19%   -4.15%     
==========================================
  Files          24       25       +1     
  Lines         742      785      +43     
==========================================
+ Hits          700      708       +8     
- Misses         42       77      +35     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[gdalle]

Thank you for these contributions!
I just want to point out that @oxinabox and I chatted at JuliaCon, and agreed that BestieTemplate.jl might be the best way forward to replace PkgTemplates.jl, precisely because it includes an update mechanism from the get go. We haven't made any formal announcement yet but I encourage you to check it out before you spend too much effort here.

[pat-alt]

Ah ok, good to know, thanks! I'm also now seeing #478

@abelsiqueira I've dabbled a bit with BestieTemplate.jl and having the update functionality is definitely a huge win. Maybe I'll abuse this thread here to ask a few questions/add some thoughts:

1. What's Bestie's equivalent to plugins?
2. Would it be possible to move to Bestie and not completely give up on the ability to generate templates programmatically?

To elaborate a bit on (1), I've found it very easy to add functionality here since it's all Julia and the docs for devs are comprehensive. To give you a concrete example, how easy do you think it would be to contribute something like #482 to Bestie?

As for point (2), it says in Bestie's docs:

PkgTemplates.jl is a project generator. This means that if you want to programmatically create templates inside Julia, this is the best solution. The questions (user interface) are implemented by the package, which then translates that into the answers for the engine.

I think this is a great feature and it would be a shame to lose it entirely. For example, I have been trying to leverage this functionality here to add a custom package template for Taija. I've continued to work on this even after hearing about Bestie at JuliaCon, because it seemed to me like the most straightforward pure-Julia approach.

Happy to instead focus my efforts on Bestie, these are just a few questions/concerns I've had so far, so what be great to hear your thoughts :)

[gdalle]

@pat-alt can you maybe put this comment and continue the discussion with Abel on #478 instead?