Remove duplicate code on recipes

[faustinoaq]

Hi 😅

Currently --recipe flag is working very nice on master (not released yet), also the recipes are being automatically tested and deployed 🎉 https://github.com/amberframework/recipes/releases

Although, this repo has some duplicated code across recipes, we have some options to fix this:

1. Use symlinks to reuse existent code/directories/files, before deploy the symlinks should be replaced by the real folder/file, once deployed and zipped the recipe should not contain symlinks. 😄

2. Use multiple liquid layouts to reuse templates. We would need a common layout directory, so every recipe can include it and reuse the code. 🎉

3. Use one recipe per repository this won't remove the duplicated code, but just move the code to a new repo for each recipe. This would work by using shards install, although the maintainability is not easy, because we will require to test, maintain, deploy and review issue/PRs for all recipe repositories.. ❤️

4. hierarchical recipes where a recipe depends on another base recipe and is effectively a delta from the base recipe by @damianham 👍

/cc @drujensen @damianham @amberframework/contributors @amberframework/core-team

[faustinoaq]

Please vote using

1. 😄 (option 1: symlinks)
2. 🎉 (option 2: luiquid layouts)
3. ❤️ (option 3: multiples repos)
4. 👍 (option 4: hierarchical recipes)

[damianham]

I think my preferred option to remove duplicate code in recipes is to have hierarchical recipes where a recipe depends on another base recipe and is effectively a delta from the base recipe. I am working on some options to refactor recipes. In particular I am looking to source a recipe directly from a github repo as per the comment by @drujensen i.e.

amber new myapp -r drujensen/basic_granite

which would source the recipe from https://github.com/drujensen/basic_granite repository. However I am not thinking about going the whole 9 yards with a shards based installation as that will imply copying a lot of code from the shards program into the amber CLI rather than just 1 or 2 files. I am more inclined to a simple a solution as possible that works that just clones and extracts the repo. Once I have this feature working I can experiment with hierarchical recipes more easily. With the implementation of hierarchical recipes I envisage the above command would become;

amber new myapp -r drujensen/granite

which would extend the base recipe at e.g. amberframework/base and add the granite ORM.

[faustinoaq]

hierarchical recipes

@damianham Oh yeah! I added your option, and I think is a very nice idea 👍

[drujensen]

@damianham Thanks for looking into this.

[drujensen]

Would be nice shards install drujensen/basic_granite existed where it would add this to your shards.yml and install it. https://github.com/crystal-lang/shards/blob/master/src/commands/install.cr

But there is still a chicken/egg thing since the shards.yml won't exist until the project templates are ran. It would require a bootstrap step which is probably what you are already doing.

I still think it would be nice to be able to update the recipes by just updating the shard.yml.

[faustinoaq]

@drujensen I think shards install doesn't support that yet 😅

See: install cli

See: crystal-lang/shards#144

[damianham]

@drujensen yes there is a chicken/egg situation and I am trying to keep it as simple as possible. I will see if I can find a method to specify the recipe in the app/shard.yml and also bootstrap the app from the recipe.