A tool I developed for my own personal use, but it tickled my fancy to think about how I could make it usable by others.
Overall this has been a blast to work on. There is a kind of unhingedness when writing this much stuff in a language like Bash.
Why Bash?
- Primarily, because Bash is everywhere. Everywhere that I intend to support, at least. Using another tool leads to a frustrating “bootstrap” problem: what do I need to install for the bootstrap tool to work? This means that there will almost always be some kind of initial bash bootstrap layer. (I also don’t care to use any of the available options that make writing fully contained “just download and run” programs easy to make).
- I’ve long wanted to get better at Bash (or at least have felt frustrated with my lack of skill in Bash). As a typical unix-using dev, I’ve learned bits about shell over the years, but I’ve not been able to internalize much of it as I learn it. Most of it feels extremely random and inexplicable. Given that I’ve been essentially uable to really learn it via typical osmosis, the only realistic way I know to fix this at this point is to make a study of it, and for me the best way to study a language is to have a project I’m working on with it at the same time.
- the universal interface to the tool. You shouldn’t need to use anything else.
- settings file
setting up
- download ws_install.sh and run, optionally setting env vars to customize
- sets up repo
- makes various default files etc, esp settings.sh
- maybe use a different dir as source?
- customize ws_profile/settings.sh (where should this go?) can run gen
e.g. download ws_install and run download personal workstation configuration, or put in place in some other way run e.g. workstation bootstrap
setup steps configure any env vars if want installed elsewhere curl ws_install, run it w bash execute ws bootstrap ()
- at this point, where should configurations be?
implement a -i or -q for interactive/quiet? (-i default?) where should the settings and config file be located?
- TODO make actual modification commands clearer/explicitly logged.
- automatic adding of ws tool’s bin dir to PATH, at least, and perhaps other relevant tasks?
- automatically/better handle conflicts when e.g. replacing a file/dir with a ws
managed version that already exists?
- good idea to log, “save” these differences in state
- command like `ws hack` that loads all of the relevant workstation stuff into an interactive bash session and drops the user in it so they can experiment/make whatever changes are necessary.
- finish porting remaining functionality from workstation repo to this (ws)
- home manager
- bww/secrets
- df/dotfiles subcommand
- standardized/better logging/output
- save logs in a subdir?
- save state/info somewhere?
- “last checked on $date, properties verified …”
- ran the following potentially destructive commands, making the differences/changes noted in <some diff>
- save md5 hashes of previous runs/files so it can know that nothing has changed in a file since a previous run, and so it can safely overwrite/remove whatever necessary changes.
- better docs/explanation of how it all works
- parameterizable properties?
- vs just wanting props to wrap?
- oo commands to props, e.g. so that prop_foo takes a –fix flag
and then a separate function is not needed? makes some things simpler
- also does expand upon the notion of functions as way to indirectly trigger or control behavior, like how the dotfiles mgmt system works.
- collect/predefine descriptionm of what changes would be made as detailed as
possible before actually invoking?
- the “print the fix function” is pretty useless, fix funcs too complex
- replace with “drop into shell here” command, similar to the `ws hack` suggestion above?
- the “print the fix function” is pretty useless, fix funcs too complex
- build a single ws bin that can be thus distributed
- cat most of the files together should work
- avoids much of the initial difficulty
- no need to clone/fetch entire repo
- ws_install can be replaced with a curl that just downloads the ws tool
- no need for WS_DIR to house files etc
- makes sense with XDG_BASE_DIRECTORY spec:
- .local/state/ws for logs, saving state
- XDG_STATE_HOME
- .local/state/ws for logs, saving state
- store ws bin itself in .local/bin
- havintg just one bin would remove a lot of the unknowns with issues
- thinking about things that work in this direction anyway, like generating default config files from code instead of
- document the various properties
- experiment with literate programming and this tool
- tangle end product via shell
- give subcommands automatic help, parsing, etc
- so i.e. metaprogrmaming while reading the file? like the “find all vars” thing?
- split code into organization by features, i.e.
- feats/nix/{props,lib,subcmd,sets}
- feats/secrets/{props,lib,subcmd,sets}
- feats/dots/{props,lib,subcmd,sets}
- maybe? feats/core/{props,lib,subcmd,sets,cfg,bootstrap}