Support for Stage Blocks?

[fvumbaca]

It would be awesome if strapped can support the use of blocks to categorize different "stages" of a strapped file.

Something like:

strapped:
  stage: scripting
  repo: repo.strapped.sh

brew:
  packages:
    - { name: python, upgrade: true }
    - { name: ruby, upgrade: true }
---
strapped:
  stage: emacs
  repo: repo.strapped.sh

brew:
  packages:
    - { name: emacs, upgrade: true }
  casks:
    - { name: emacs, upgrade: true }

bash:
  ln:
    - { target: ~/strapped/config/init.el, name: ~/.emacs.d/init.el, symbolic: true }
    - { target: ~/strapped/config/config.org, name: ~/.emacs.d/config.org, symbolic: true}

This can open up some cool use cases where users can run a subset of stages, or import stages from another yaml file:

$ strapped -y https://github.com/some/raw/yaml.yaml --stages emacs

or from a yaml:

strapped:
  stage_src: https://github.com/some/raw/yaml.yaml
  stage: referenced_stage
---
strapped:
  stage: custom
  repo: repo.strapped.sh

# ....

[MatthewNielsen27]

I'm wondering how this would be cleanly implemented. Any suggestions? I have ideas, but nothing really speaks to me at the moment.

[MatthewNielsen27]

@fvumbaca the limiting factor happens here:

straps=$(ysh -T "${config}" -t | uniq)

If we remove the | uniq then we can iterate over repeated stages but that doesn't help us since ysh will only return the data from its first occurrence in the config file.

[MatthewNielsen27]

The problem with our current implementation is that we use the strap names as a key in a sort of map that allows no duplicated keys. The fix would require stages to be iterable and each element in stages to have an identifier of what to do in the stage (name). The name for custom straps would then just be custom.

The fix would be to have stages as a list instead of a top-level lookup.

[fvumbaca]

ysh has supported blocks actually :) By default, ysh only reads the first block. To read the next block you can do something like:

file=$(ysh -f input.yaml)
echo "Now in stage:" $(ysh -T "$file" -Q "strapped.stage")

# -n for next block
file=$(ysh -T "$file" -n)
echo "Now in stage:" $(ysh -T "$file" -Q "strapped.stage")

Edit: here is a link to an example from the docs (with looping): Ysh block example

[fvumbaca]

@MatthewNielsen27 @tk8817 I definitely feel this is possible, but what are your opinions on adding it? The ability to run subsets of setups is starting to feel a little limited in its use-case. The use-cases I see are:

• organizing and recovering from errors
• including configs for different systems in one file, then run that systems stage(s) - could even contain a general stage
• "I want to try out Frank's super cool emacs configuration"
• allow cross-file references of stages and consume them similar to straps

I am not sure if this is too much functionality to shove in as it might move us away from the intention of setting up your system.

I'm curious what your thoughts are on this feature (or something like it)

[MatthewNielsen27]

@fvumbaca yup this is something that 100% needs to happen. It’s definitely a large limitation as it stands right now. I am unsure about using blocks, how would that allow us to preserve ordering when searching between stages without the use of state? I think there would be some state to maintain in the case of [brew, vscode, pip, brew, bash, brew] (in order to keep track that we are at the 3rd brew block). I would prefer to minimize internal state kept by the program and keep it as functional as possible.

@tk8817 do you have any architectural ideas?

[fvumbaca]

I was thinking that stages could be stateless. What cases are you thinking we would need to preserve state between stages @MatthewNielsen27 ?