Closed dprada closed 3 years ago
I believe it has various advantages as it will make easier to incorporate continuous integration because it already contains preconfigured workflows for GitHub actions. It also will make testing and deployment easier.
I think it is a good idea to use it, or at least incorporate some parts of the structure to the library.
Ok. Then... I agree it is something very interesting that we have to implement now. I see three options. You choose:
1- Do you want to start a new repository from scratch? I guess we should clone the cookie-cutter. We can do it, no problem. 2- You clone locally the cookie-cutter to compare files and structure. Moving little by little files and options in config files. (This is probably something that is going to take a while, but it is what I would do if I were you). This doesn't need to be done at once, with a setup.py and the versioning system we can start working on the library. 3- I add in this repo the structure proposed in the cookie-cutter (as in 2).
If you choose 2, I can always help.
I have followed the instructions in the MOLSSI cookie-cutter repo to clone the template (with a hypothetical new project). I think we can implement everything in our repository little by little. I'm going to try to do it with MolSysMT.
Ok, I guess we can go for option 2 then.
I'm going to close this issue since the discussion had already a resolution: the structure and files from MOLSSI Cookie-cutter were adopted with slight modifications (see the repository Test-UIBCDF-Library)
We should based the project on https://github.com/molssi/cookiecutter-cms.