Discussion: potential merge with pytest-copie

[kenibrewer]

Key discussion points.

1. What are the features that are present in pytest-copier that would be worth bringing over to pytest-copie (or vice-versa)?
2. Under who's leadership should the combined project be led?
3. Is @noirbizarre willing to donate the pytest-copier name to a merged project?
4. Is pytest-copier currently being used in production anywhere despite being explicitly labeled as a PoC?

[noirbizarre]

Hi @kenibrewer 👋🏼

Thanks for reaching me. I will answer your points but let me bring a bit of context before: I started this project from scratch for my needs and those from the company I work for or with. It started as an experimentation (hence the lack of doc and tests for the moment) at a time when there was nothing existing. We are actively using it and it was meant from day one to be donated to @copier-org (if they accept it) as soon as it is fully working for our cases. You know the drill: as soon as a personal project become a community driven one, some bad practice can't persist (and this kind of try and publish dev is not a good practice, I know, but it allows to quickly get something up and working). Right now, I am finalizing it as it is only missing the snapshot part (and tests and docs obviously).

So given this context:

1. I need to dig into pytest-copie to answer (but from the first sight at the readme, all features provided by pytest-copie are already in pytest-copier except template path change), but here's the list of pytest-copier features:

• expose the current copier template as a project typed fixture (it is meant for testing a single copier template)
• allow copy and update
• allows testing rendered context values without rendering the project
• allows to tests rendered answer
• allows to test the entire rendered projects
• allows to easily commands in the rendered project
• WIP: snapshoting based on syrupy (I have it working, just finalizing the matchers and filters part. I already proposed to syrupy the path/directory snapshoting part: Path snapshotting support syrupy-project/syrupy#829)

2 and 3 are the same to me: it was my plan from day 1 to give the project to the @copier-org as soon as I have a "fully" working solution. It is still the case. TBH, in the past, I burnt-out because of overload of open source project to maintain. I don't want to go back to it, and I am looking to contribute to existing and living projects (aka. with one or more existing maintainers and ideally a working organization). I believe single maintainers projects are not sustainable on long term.
As a consequence, I'm willing to:

• either give it as it is to copier-org and let them maintain it
• either give to copier-org and be part of maintainers
  I am OK with both, as long as there is a shared maintenance and leadership and we can agree to keep some backward-compatibility in the future devs.

4. Yes it is. On my side on non public (yet) personal projects. At my works, we literally moved all Python projects to a copier managed template. It's working just fine, but without the snapshoting part, updating the template and the tests is a long process (hence the fact I want to finish this part before giving the project).

I was on holidays, so I haven't had time to finish yet, but it's in my current high priority todolist so expect a delivery to copier-org this month (I would love to be able to do it this week, but I'll avoid false promises I won't be able to fill)

In the meantime, I'll take a look at pytest-copie to see where it overlaps, where it doesn't.

Also, If you want to try the project and you have some question, don't hesitate. Same if you have some specific use cases and want to know if they are supported...