Package stack templates outside stacks

[slinkydeveloper]

Is your feature request related to a problem? Please describe. Now the stack templates are packaged inside templates, meaning that if you want to ship new templates you need to ship a whole new stack, copying the existing one. It would be good if stack templates could be packaged outside the stack itself

Describe the solution you'd like stack templates should be packaged outside the stack, so one can use an "official" stack and a custom template installed from a third-party repo

[sam-github]

I like the idea of decoupling the app skeletoning from the deployable image (based on stack) build.

Maybe just an appsody init STACK --no-template or appsody init some-stack empty (so, make every stack have a template with no content) would be sufficient? Maybe even possible already? This would be useful to add appsody capatibility to existing apps.

That would cause the .appsody.yml (IIRC the name of the appsody state file) to be created, and then you could leave the creation of the app completely up to the user. npx express-generator would be possible, or git clone https://github.com/socketio/chat-example; cd chat-example; appsody init nodejs-express empty, or whatever app skeleton/templating system they already have.

[slinkydeveloper]

Maybe even possible already?

I see your solution and it could definitely work now as is.

But what I meant is the opportunity to have something completely integrated within the appsody experience, so third party can ship repositories with just templates, specifying for which stacks they compatible, and appsody init stack template-3rd-party would just trigger a scan of external repo. But maybe it's too overkilling/out of goal for appsody?

[neeraj-laad]

This is an interesting thought. Though there are a number of aspects to consider:

• Will we have many 3rd party providers providing starter templates for a stack they do not maintain?
• Who would anyone guarantee that ongoing changes to stacks and templates are compatible?
• Is there anything stopping the 3rd party provider to contribute the template to appsody stack via a PR and maybe become a maintainer?

There have been some other discussions around stacks and templates and the idea there was to bundle the templates within the stack image itself. So there is only one asset that gets published / maintained.

[slinkydeveloper]

@neeraj-laad you raised all valid points, my two cents here:

Will we have many 3rd party providers providing starter templates for a stack they do not maintain? Who would anyone guarantee that ongoing changes to stacks and templates are compatible?

It's up to them to fix it and keep updated

Is there anything stopping the 3rd party provider to contribute the template to appsody stack via a PR and maybe become a maintainer?

The whole thing generates from the problem that to add a template, without adding it to appsody official stack, you need to copy the existing stack and add the template. If someone wants to contribute directly to appsody and that contribution makes sense to exist in appsody, then he should contribute. But this is not always the case and now, if you want to add a template without adding to appsody, you need to create a "copy paste" stack. If you feel that it doesn't make sense to extend functionalities of appsody init on this aspect, then feel free to just ignore this issue :smile:

[nastacio]

I think this feature is necessary. I remember participating in a discussion on this exact topic, where I suggested that not only appsody supported the notion of external templates, but also hosted the marketplace for them.

re: "Maybe even possible already?" , there is the limitation in the proposed (and clever) workaround: templates are managed and browsed in isolation from their stack.

As a user, I would rather see a list of templates with the proper maturity classification (stable, incubator, experimental, 3rd party, etc) in a central location than not know about the git url of a templates that could have saved me a few hours/days worth of wrangling thorny issues already covered by someone else. As a stack owner, I may not want to own yet another relatively niche template, but I definitely want to know which templates are heavily used and warrant graduation to the official stack.

Not to design the whole experience, but a central marketplace of some kind is virtually a standard for systems expecting contributions from 3rd parties. Such marketplace should definitely start with the stacks themselves, and then expand to templates.