fermyon
install a specific template from a repository
the current ux around templates management is lacking a way to install a specific template from a repository. for example, I want to install https://github.com/fermyon/spin/tree/main/templates/http-go.
maybe something like the following could be implemented?
spin templates install \
--git https://github.com/fermyon/spin \
--branch main \
--name http-go
@rgl Thanks for raising this. To help us address this, could you clarify the problem with having the "extra" templates, e.g.
- It's clutter when choosing from the list
- Disk space
- Download time
- Principled objection to having stuff on your computer that you don't use
- etc.
The reason I ask is that we manage templates at the repo level and that's unlikely to change in the short term, so I'd like to understand the underlying goal / requirement. Thanks!
I'm fiddling with ansible automatic installation of spin and related tools. For that, having a way to target specific tools seems more appropriate, as it would be a one to one mapping between the thing that appears when listing with the list command and the thing that we actually install with the install command. When that happens, I could just skip the installation when the list command says it is already installed. Does that make sense?
PS have a look at how I declare the install using an ansible task at https://github.com/rgl/my-ubuntu-ansible-playbooks/blob/c0a0c22acd9185e167ef6e8593f80a8d0fea85f9/roles/spin/tasks/main.yml#L35
PPS or this is the wrong approach, and what we should have is a proper Debian package.
PPPS spin like tools will have a tendency to install a lot of things that I particularly do not use, like support for programming languages that I do not use. As such, having separate templates would help reduce the clutter.
Ooh, Ansible-based install sounds intriguing! However, I'm afraid your specific requirement still isn't quite clicking for me. It sounds like you hope to use spin templates list to identify which "packages" (sorry, don't know the Ansible term) are already installed - like, as a kind of "if I see that the http-go template is installed, then I know my whole Go package is installed, and I can skip re-installing it." Is that correct? If so, that inference seems risky, even with the "install a single template" change.
I appreciate what you're saying about the clutter - my first thought on seeing the issue was the visual clutter of the spin new interactive list. For interactive users the actual artefacts are hopefully out of sight out of mind, but I see how trying to reconcile different tasks adding supposedly disjoint stuff could dislike it. And yes fair point that install and list are not symmetric!
Yes, that was my hope. But in the end, it's faulty because there is no obvious way to know the installed versions. If there was a way, why would it be risky? The listing code path should only list something when it's actually fully installed, right?
My comment about 'risky' was that Spin templates don't guarantee the presence of tools. A user might install the Go template but not TinyGo. A user might install the JavaScript "template and tools" package but then uninstall js2wasm. I don't know if Ansible prevents that; it just seemed to me that it would be safer to check directly for the 'other stuff' than to rely on the presence or absence of a template. But I know nothing about Ansible so I may well be missing something obvious - if I seem obtuse then I apologise in advance!
And yeah, you make a great point about versions...
My ansible task is only taking care of ensuring that a given template is installed. The template dependencies, like j2wasm, are ensured by another ansible task. Both tasks are used in tandem (like in https://github.com/rgl/my-ubuntu-ansible-playbooks/blob/c0a0c22acd9185e167ef6e8593f80a8d0fea85f9/roles/spin/tasks/main.yml#L26-L29). But, indeed, this whole ansible thingy is still very rough, fragile and a big ball of mud. In fact, from my viewpoint, generally speaking, installing software, their dependencies, and upgrades, is a hell on its own, unfortunately. Hopefully, Web Assembly will fix that? But I digress. :-D