tryout on existing package GEMDAT

[egpbos]

I wanted to try to see what happens when I apply the template on the GEMDAT package. Here I want to highlight some issues I ran across. I will just copy here the process I went through in my terminal and interject it with comments.

git clone [email protected]:GEMDAT-repos/GEMDAT.git
copier copy https://github.com/nlesc/python-template.git GEMDAT

Questions

Q1: profile

I chose the Minimum profile.

Note that here I have my first issue, because I tried to copy-paste the terminal output, but somehow Copier makes it so that I cannot. I think it activates some kind of fancy mouse capturing, which prevents me from selecting text with my mouse, as I usually do. I guess I could find workarounds for this, but anyway, just noting that it's annoying to me.

Q2: project name

I had to choose gemdat as project name.

This already gives us the second issue, because the project's name is actually GEMDAT! We set our validation too strictly here, this should be loosened.

Q3-5, 7, 8, 10: version, full name, license, description, keywords, email

Q3 (version) auto-suggests 0.1.0, which is the default. This is not good default behavior for applying the template on existing projects. The version is easily accessible from pyproject.toml, so this should be reused. I looked it up manually and set it to 1.5.0 (the current version).

The same goes for Q4 (full name) which is specified here as a list (sounds like a good default to use and to change "full name" to "first author name" noting that you can easily add more authors to the list later), Q5 (license) which is specified also already, Q7 (description), Q8 (keywords) and even Q10 (email; is also in the authors list).

Q6: copyright holder

By default, this will often be your organization, not the individual. Would be good to suggest that here, instead of the default "full name".

Q9: github username/org

This is of course a separate issue that will also come up when we start looking into GitLab support. It cannot be taken blindly from the pyproject.toml, but at the same time it could perhaps be taken from the git remote info. Would be good to at least detect that info and suggest it as the default option.

Set this to GEMDAT-repos.

Generation

Then generation starts. The choices made here (either by me or by Copier):

• Overwrite README.md? No (I chose).
• Conflict in LICENSE. Copier chose to skip.
• Conflict in .gitignore. Copier chose to skip.
• Overwrite MANIFEST.in? No (I chose).
• Overwrite pyproject.toml? No (I chose)!
• Overwrite src/gemdat/__init__.py? NEIN!

One thing to note here is that I chose no everywhere, whereas the default choice is yes. We should probably make "no" the default.

Result

$git status
On branch main
Your branch is up to date with 'origin/main'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.copier-answers.yml
	NOTICE
	project_setup.md
	src/gemdat/my_module.py

We see that a NOTICE file was added, which I think is a requirement for Apache v2, so that's good. The .copier-answers.yml file makes sense as well. The other two files, however, I'm not so sure are helpful in case of an existing project.

Conclusion

GEMDAT seems to already adhere to the Minimum profile mostly, although it's hard to say what exactly was ignored or skipped during generation and how crucial that stuff was. The additions are a mixed bag: the extra license compliance is good, but the "getting started" files should be skipped in this scenario. Also there were a lot of questions that did not need to be asked, because they could be answered automatically from the pyproject.toml. All considered, there is a lot of streamlining to do to make "scenario 2" in the README (applying to an existing project) worthwhile. This is just considering the Minimum profile, we could also look at the other options.

[egpbos]

Just pinging GEMDAT authors (from NLeSC) @stefsmeets @v1kko and @SCiarella as well.