kergoth / dotfiles Goto Github PK

@twpayne has, in prior discussions, issues, and PRs, indicated that it's best to use a small set of feature flags to control behavior, rather than having a great deal of information in the chezmoi.toml. Set a few specific boolean feature flags and use template variables and logic to set them cleanly, the way they do in theirs.

There's a function to query the latest version of something from GitHub, and I've seen folks use templates to query the version or branch head before setting the URL.

I've run into inconsistent behavior regarding winget's --id argument, where only certain packages seem to match, whereas others do not, and I have not managed to determine what's the differentiating factor. This happens with the powershell Get-WinGetPackage as well.

> winget list --id 1Password
Name      Id                  Version Source
---------------------------------------------
1Password AgileBits.1Password 8.10.24 winget

❯ winget list --id AgileBits.1Password
No installed package found matching input criteria.

> winget search --id AgileBits.1Password --exact
Name           Id                       Version         Source
---------------------------------------------------------------
1Password      AgileBits.1Password      8.10.24         winget

See giggio's integration here, as upstream is lacking support currently.

See New XDG_STATE_HOME in XDG Base Directory Spec, XDG_STATE_HOME, and Environment Variables for details.

Something along the lines of..

chezmoi managed --include=files,scripts --exclude=externals | Select-String -NotMatch -Pattern '(^ *$)|\.(ttf|otf)$' | Invoke-Fzf -Multi -Select1 -Exit0 -Query home-manager | % { Join-Path $env:USERPROFILE $_ }

Then we have to execute $env:VISUAL on those selected files. I will need to Split-String $env:VISUAL before executing it. See the implementation of Invoke-FuzzyEdit from PSFzf, for example.

Consider replacing the current document-based SSH keys with actual SSH key items. op read "op://Personal/frey/private key?ssh-format=openssh". Initial tests failed due to line ending issues with the openssh format. Presumably this can be done by replacing the line endings in the template appropriately.

Not all systems I use allow access to 1password's servers, so using it for everything isn't ideal. Either it has to be explicitly bypassed on those systems, or I could use gpg encryption instead, optionally fetching the gpg keyring out of 1password if 1) no gpg agent is available and 2) the gnupg keys aren't yet present and 3) the 1password cli is usable here. Then on hosts without access to it, I could manually deploy the gpg keyring.

See Change Window Title in the starshp documentation.

• Revisit os setup in os-install, as parts of this should migrate to setup-system
  • Set root password
  • Add staff group
  • Adjust /usr/local permissions
  • Set hostname? Keep in os-install?
  • Set timezone
  • Set up console font if non-ephemeral and non-WSL
  • Install and enable dhcpcd - keep in os-install
  • Install vi, net-tools, zsh - remove entirely, or keep just net-tools
  • Install and set up bootloader - keep in os-install
  • Set up initramfs - keep in os-install
• Set up pacman keyring
• Change ArchWSL default user if using ArchWSL
• Adjust /etc/wsl.conf if necessary

Reference

• How to Set Up ArchWSL

This is non-trivial, as I still want to be able to run these manually, and there are order-of-operations issues to resolve. It would be nice to conditionally do things in the templates based on what packages are installed, but I'm not sure I want to, as it leads to headaches. Currently, home-manager doesn't run until after the dotfiles are set up, to ensure home.nix was put in place, but this means that anything installed by home-manager isn't available at the time the templates are being processed.

The .chezmoiscripts approach taken by nandalopes seems viable, but this cannot be run manually, unless I write a script to run the .chezmoiscripts explicitly on-demand. Alternatively, I could do the opposite, have the primary source of truth for the scripts be the files in scripts, and call into those from the chezmoi scripts, but I'd likely have to leverage the chezmoi-exec script to pull that off.

• sudo: https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket/
  • See also userv
  • See also sudon't
  • See also run0
• chsh: https://tim.siosm.fr/blog/2023/12/22/dont-change-defaut-login-shell/

"@siosm btw, the nicest way to disable the suid binaries is by dropping in a config snippet for systemd that sets NoNewPriviliges=yes, system wide. In that case suid is a thing of the past. (I mean, ideally we'd have an option to compile it out of the kernel, but this is the next best thing)"

This is no longer maintained, though it does still function.

Test

See Optimizing Shell Startup Time, the main idea being to call out to them in templates, such as {{ output "/opt/homebrew/bin/brew" "shellenv" | trim }}. There are items to confirm when looking into this approach. We'd have to ensure that changes to the packages result in changing the template, and package installation would have to be done with a before script to ensure they're available for the templates to use. They would also have to not depend on my user PATH changes.

On hosts without zoxide, such as my Synology NAS, I still want to be able to use z.

Currently I am registering them, but it's copying them to the system fonts directory first, and 1) I'm not sure this is necessary, and 2) this is quite slow for a large number of user-installed fonts.

See Git - Signing Your Work and Signing commits - GitHub Docs.

• Commit signing works now when done manually, at least for [email protected]. Next steps:
  • Ensure commit signing works with GitHub specifically.
  • Consider enabling signing by default.
  • Generate keys for [email protected].

This is needed primarily between starship and powerlevel10k, but is only really needed if I continue experimenting with nushell, as starship under PowerShell doesn't support the right prompt. Currently only battery is placed in right_format for starship-right.toml, but this doesn't align with the powerline10k behavior.

• Some values could be stored in chezmoi.toml. Security is a concern, but as long as it's protected by permissions, it's no less secure than storing these values in their final destinations.
• For binary or larger values, I could probably alter the template to use the existing value. The question becomes how to trigger invalidation of this cache, since it'd bypass the usual chezmoi mechanisms.
• Handling values which are neither an entire file nor a small string could be problematic, for example, subsets of .ssh/config for home and work.

Consider reworking entirely to improve performance and base on diy++ from zsh-bench.