Consider using more powerful templating, e.g., cookiecutter

[Midnighter]

(The issue template is not helpful for having discussions here :wink:)

Search of the different fields denoted by {{ is tedious and error prone. Cookiecutter provides a way to ask for these values before instantiating a template project structure with those values automatically. Of course, it is one more technology that users would have to learn (although quite straight forward). Is there any other reason why you decided against a technology like cookiecutter?

[mihai-sysbio]

(I agree; it's the cost of providing this issue template to people who use this template)

In short, WYSIWYG. When adopting standard-GEM, the .standard-GEM.md file needs only check marks (x). It's the README that needs to be filled in. Indeed {{ might not be the best - but at least, the file needs to be filled in only once.

I'm hoping that standards will converge, and that eventually the Memote cookiecutter would be the command-line utility for this purpose. It's also a way to avoid duplication of efforts.

[Midnighter]

I'm hoping that standards will converge, and that eventually the Memote cookiecutter would be the command-line utility for this purpose. It's also a way to avoid duplication of efforts.

I'm definitely happy to work in that direction or to decouple it from memote entirely and make it stand-alone or more associated with this work. In fact, I'd be very happy if the cookiecutter were being developed and maintained by the group of people who use it the most, i.e., model builders.

So let me know your ideas and we can start going in that direction.

[edkerk]

Would it not be possible to have the repository template as it is, and provide a cookiecutter solution? The python proficient could then use the cookiecutter, which replaces the template files, while the non-python enthousiasts can still manually edit README.

[Midnighter]

Would it not be possible to have the repository template as it is, and provide a cookiecutter solution? The python proficient could then use the cookiecutter, which replaces the template files, while the non-python enthousiasts can still manually edit README.

Typically, cookiecutters create a project directory which would look ugly for use in a template repository (see, for example, https://github.com/opencobra/cookiecutter-memote). I'm not sure if this is a hard requirement at the moment. Having a cookiecutter.json file is definitely required, though.

[mihai-sysbio]

The current version of standard-GEM works more like a minimum information and some recommendations put together; extra files and folders aren't a problem. Personally, I see nothing wrong with a cookiecutter.json in (some) repos. ~But if we would try to avoid this, here's a random idea: would it make sense to .gitignore the file to prevent it from being committed?~

[sulheim]

I think it would be great to have a cookiecutter-option, I guess that template repository could be a separate one from this, e.g. .../cookiecutter-standard-GEM

[mihai-sysbio]

There is some value in having the model-specific values separated in a config file (eg Jinja). There are multiple ways of solving this, and indeed cookiecutter is one way. Another would be to implement in the validation pipeline a check for empty fields. But I digress.

Looking back at the original post, the core problem seems to be that

Search of the different fields denoted by {{ is tedious and error prone

In other words, as a user, I want to quickly (??) go through the required fields that I am expected to fill in, so that I can be compliant with standard-GEM.

@Midnighter, @edkerk and @sulheim, what would you say the underlying problem is:

• does it take too long to create a standard-GEM-type repository?
• too long to go through the .standard-GEM.md and README.md files?
• too easy for mistakes to happen (eg missing fields)?
• no way of capturing mistakes in the .md?

[Midnighter]

I can't speak from a user perspective here but from experience, I am most worried about

• too easy for mistakes to happen (eg missing fields)?

• no way of capturing mistakes in the .md?

[edkerk]

Having used the template a few times, I agree with @Midnighter.

[sulheim]

I haven't used the template yet, but @Midnighter's concerncs seem the most reasonable