Don't checkout anything by default on local templates

[pawamoy]

I'm currently translating a cookiecutter template to a copier one, and each time I change something, I have to commit the change for copier to pick it up. At first it was confusing ("why did files that I removed were copied??"), and now it's annoying (a "wip" commit for every change, and then I'll have to squash them or something).

I think it's because copier tries to checkout the latest tag? I'd like it not to do anything if I don't specify the -r, --vcs-ref option.

[yajo]

This is important because copier uses git tags to handle upgrades. Also, copier needs a ref to be saved into the _commit key in .copier-answers.yml.

However, I agree this is a little pain point for template development.

One thing I do is:

1. Commit your changes.
2. Add --vcs-ref=HEAD to your copy command.

For unit tests, however, I simply use this pytest fixture, which clones the current template into a temporary directory, including dirty changes, applies a test tag (so I know .copier-answers.yml will always have _commit: test) and returns the Path to that clone, which can be safely used in TDD.

Copier could include a --vcs flag with these options: auto, git, none. It should default to auto (use git if available, none otherwise), but this way users could just give --vcs=none and skip all the gitty stuff.

[pawamoy]

Copier could include a --vcs flag with these options: auto, git, none. It should default to auto (use git if available, none otherwise), but this way users could just give --vcs=none and skip all the gitty stuff.

That would be great 🙂

I totally get why the checkouts are important for being able to update the generated projects, though if users could disable it it could really facilitate the development!

[pawamoy]

It's especially annoying when you have tests for your template: you must commit before running the tests 🤣 !

[yajo]

Not with that fixture provided above. Although you're right this should be fixed.

[pawamoy]

Oh yes, thank you! I happen to have written my tests in a simple shell script though 😅

But I'll use your fixture if I convert them to a pytest suite.

[yajo]

You can also emulate that fixture as a bash function, it's quite easy.

[yajo]

I'm thinking that a good fix might be to supply that fixture with Copier, so downstream templates can reuse it.

[dennisroche]

As suggested in #412, could we make these two commands behave differently?

copier . ./tmp

use the local changes instead of the git repo if template_src is not a url

copier copy https://github.com/copier-org/autopretty.git .?

as-is

If that isn't possible (or what you prefer) then perhaps a flag --local or --no-git to change the behavior.

As a user I want to be able to test templates quickly/iteratively using existing cli tool (not via pytest fixture)

[yajo]

As a user I want to be able to test templates quickly/iteratively using existing cli tool (not via pytest fixture)

Yes, well that makes sense indeed.

However, I cannot predict what you want to test. Is it a copy, a recopy or an update? Besides, when copying a non-git template, the results and features are different, so you could get to unexpected results when comparing your dev with production environments.

However I guess that we can make this assumption: if the template is a local directory and it is dirty, you're developing the template, so you're going to want to test those dirty changes, so Copier could take the freedom to do the wip commit dance automatically and print a warning so you are aware of that.

[hojerst]

I'd also really like to see this feature in some kind.
Just some ideas which would simplify local testing during development:

• add a flag like --vcs-ref=dirty or something like that. (semantic: if it is a local git repo, just add -dirty to the commit-hash for the answer file and use the dirty, checked out version)
• use --vcs-ref=none to disable the git tag stuff completely. IMHO this is completely sufficient for a quick test. Even if the result might differ slightly from a git repository. You could also print a warning about the caveats.

This should only be relevant during development of templates. Depending on your workflow there is still the option to run a commit as soon as you assume you are finshed and run a "real life test with git" before publishing.

[yajo]

Those are OK until somebody creates a branch named dirty or none. 😄

I think I still prefer the suggestion from #184 (comment).