twpayne / chezmoi Goto Github PK

I am getting outside target directory error. I tried different formats:

• ./chezmoi add .config/micro/settings.json
• ./chezmoi add pwd/.config/micro/settings.json
• ./chezmoi add /home/jenkins/.config/micro/settings.json
• ./chezmoi add ~/.config/micro/settings.json

./chezmoi add  /home/jenkins/.config/micro/settings.json
Error: .config/micro: outside target directory
Usage:
  chezmoi add [flags]

Flags:
  -h, --help        help for add
  -r, --recursive   recurse in to subdirectories
  -T, --template    add files as templates

Global Flags:
  -c, --config string       config file (default "/home/jenkins/.chezmoi.yaml")
  -n, --dry-run             dry run
  -s, --source string       source directory (default "/home/jenkins/.chezmoi")
      --source-vcs string   source version control system command (default "git")
  -t, --target string       target directory (default "/home/jenkins")
  -u, --umask int           umask (default 18)
  -v, --verbose             verbose

Currently the verify command verifies all targets. It would be nice if the verify command could take a list of targets to verify for example:

$ chezmoi verify ~/.bashrc

If the list of targets is empty, it should default to all targets.

People who publish their dotfiles (e.g. github.com/twpayne/dotfiles) might want to add a README.md or LICENCE or similar to their repo, without wanting these files copied into their home directory.

Suggestion: support .chezmoiignore file that works similarly to .gitignore: any files listed should be ignored by chezmoi.

Today, with the introduction of support for Hashicorp Vault, it is possible for a command to not necessarily exist. Instead of relying on an error scenario when executing the command to try to locate it, for example:

 ~ $ chezmoi vault
chezmoi: exec: "vault": executable file not found in $PATH

Instead of relying solely on this, what's your opinion of instead looking to see if the command is a known command in the path and displaying or not including the command based on that, using exec.LookPath like so:

func init() {
	config.Vault.Vault = "vault"
	config.addFunc("vault", config.vaultFunc)
        
        _, err := exec.LookPath(config.Vault.Vault); if err == nil {
	    rootCommand.AddCommand(vaultCommand)
         }
}

An example application to demonstrate this:

package main

import (
        "fmt"
        "os/exec"
)

func main() {
        p, err := exec.LookPath("ls")
        if err == nil {
                fmt.Printf("ls is installed at %s\n", p)
        } else {
                fmt.Println("ls is not installed")
        }

        p, err = exec.LookPath("vault")
        if err == nil {
                fmt.Printf("vault is installed at %s\n", p)
        } else {
                fmt.Println("vault is not installed")
        }
}

and the output on a machine with ls but not vault is:

$ go run example.go
ls is installed at /bin/ls
vault is not installed

KeePassX is a popular password manager. chezmoi could use this to store secrets, instead of storing them in ~/.chezmoi.yaml.

This could possibly be exposed through a template function.

Currently the documentation is written informally in README.md. It should be restructured, following Divio's advice.

My example use case is I have bash functions that manipulate the distro package manager and it would be nice if chezmoi could ifdef them by distro. Something like:

{{- if eq .chezmoi.distribution "ubuntu" }}
function install-package { apt install $1 ; }
{{- end }}

{{- if eq .chezmoi.distribution "arch" }}
function install-package { pacman -S $1 ; }
{{- end }}

{{- if eq .chezmoi.distribution "fedora" }}
function install-package { dnf install $1 ; }
{{- end }}

distribution would be automagically determined by the ID field in /etc/os-release, which is standard and present on all Linux distributions.

 % chezmoi add ~/.zshrc
Error: rename /tmp/.dot_zshrc208154389 /home/michael/.chezmoi/dot_zshrc: no such file or directory
Usage:
  chezmoi add [flags]

Flags:
  -e, --empty       add empty files
  -h, --help        help for add
  -r, --recursive   recurse in to subdirectories
  -T, --template    add files as templates

Global Flags:
  -c, --config string       config file (default "/home/michael/.chezmoi.yaml")
  -n, --dry-run             dry run
  -s, --source string       source directory (default "/home/michael/.chezmoi")
      --source-vcs string   source version control system command (default "git")
  -t, --target string       target directory (default "/home/michael")
  -u, --umask int           umask (default 2)
  -v, --verbose             verbose

2018/11/22 16:29:15 rename /tmp/.dot_zshrc208154389 /home/michael/.chezmoi/dot_zshrc: no such file or directory

After creating the directory with install -d -m 0700 .chezmoi, the command works as expected. But, to make setup easier, I think the command should create the directory for me :)

CGamesPlay on Hacker News suggested:

New files in tracked directories should be listed with the ability to import them individually (presently you can only do chezmoi add -r and deal with the consequences).

I was impressed that chezmoi handled symlinked files placed by my previous dotfile manager. But it seems to have trouble with directory symlinks:

$ ls -l ~/.config/omf
lrwxrwxrwx 1 james users 25 Nov 10 16:16 /home/james/.config/omf -> /home/james/.dotfiles/omf

$ ls -ld ~/.dotfiles/omf
drwxr-xr-x 3 james users 4096 Nov 12 22:27 /home/james/.dotfiles/omf

$ chezmoi add -r ~/.config/omf
Error: .config/omf: not a regular file or directory
Usage:
...
2018/11/24 11:28:51 .config/omf: not a regular file or directory

$ chezmoi add -r ~/.config/omf/
Error: .config/omf: not a regular file or directory
Usage:
...
2018/11/24 11:28:53 .config/omf: not a regular file or directory

Currently the apply command updates all targets. It would be nice if the apply command could take a list of targets to update, for example:

$ chezmoi apply ~/.bashrc

If the list of targets is empty, it should default to all targets.

chezmoi checks for config files in pre-XDG locations, notably ~/.chezmoi.{toml,yaml,..} and ~/.chezmoi. This backwards compatibility code should be removed for the v1.0.0 release.

chezmoi uses Cobra for command line parsing, which can also generate autocompletion code. We should use this to generate bash and zsh autocompletion code.

It would be nice to optionally have edits applied immediately.

Not sure what the best implementation would be, but some ideas:

• chezmoi edit --apply
• a franken-command like chezmoi eda (edit->diff->apply) that potentially prompts "Apply Y/n?" after printing the diff?

Currently chezmoi will only add or replace files in the target directory. It will never remove them. This can lead to the accumulation of stale files.

chezmoi should add support for "exact" directories where the directory contents should match exactly what is specified in ~/.chezmoi. Specifically, any files or directories that exist in the target but not in the source should be removed.

This is broadly equivalent to Puppet's file's purge attribute.

chezmoi should be easily installable with Homebrew. This can easily be done by either:

• Creating a new tap, or
• Adding chezmoi to the default Homebrew tap.

Currently commands a loosely documented in README.md, or not at all. Each command should have long documentation as well.

chezmoi should be easily installable on Debian systems. We should build and distribute a .deb package.

It would be wonderful if 1Password support was added for password management. I think like other password managers, you'd be able to potentially leverage the CLI tool they offer to do the heavy lifting, which is discussed on:

https://support.1password.com/command-line-getting-started/

This is a multi-OS password manager which may make it a good candidate for integration

Add support for retrieving secrets from Vault, as requested by rascaldev on reddit.

@jhillyerd suggested a fraken-command in #28. We should add an alias mechanism similar to gits alias system so the user can create their own shortcuts.

This might require changes to the use of the github.com/spf13/cobra library used for command line parsing as the Cobra library currently only allows command aliases to be defined at initialization, before any configuration file is read.

Add a command:

chezmoi edit-config

which opens the config file in $EDITOR.

chezmoi help currently prints the umask in decimal, for example:

$ chezmoi help
...
Flags:
...
  -u, --umask int                  umask (default 18)

umask is typically written in octal, so seeing decimal here is confusing. The umask can be specified in octal using a leading 0 because github.com/spf13/pflag uses strconv.ParseInt under the hood.

#138 added support for retrieving secrets from pass. The added template function should be documented.

Cool project, may try it out this weekend.

Any thoughts on supporting toml for the data file? It's already an indirect import. YAML is pretty terrible, and considered harmful by many.

Keychain on macOS is used to store secrets. chezmoi could use this, instead of storing secrets in ~/.chezmoi.yaml.

This could possibly be exposed through a template function.

chezmoi uses text/template as its templating language. For an example of text/template in action, see https://play.golang.org/p/lzBUhUAEWXk.

text/template.Template.Execute takes as input a template and some data and outputs the template with data substituted. For chezmoi's autotemplate function, we want to reverse this process. Specifically:

Given some output string and some data map[string]string, determine the optimal templateStr string such that executing the template returned by template.New("").Parse(templateStr) with data results in output.

Requirements:

• Direct substitution should work, e.g. given [email protected] and data := map[string]string{"email": "[email protected]"} the resulting template should be output={{ .email }}.
• Longest matches should win, e.g. given name=John Smith and data := map[string]string{"firstName":"John", "fullName":"John Smith"} the output should be name={{ .fullName }}, not name={{ .firstName}} Smith.
• If multiple template variables have the same value, then the alphabetically first should win, e.g. given name=foo and data := map[string]string{"a": "foo", "b": "foo"} the output should be name={{ .a }}, not name={{ .b }}.
• Substitution should not occur within words, e.g. given os=darwinian evolution and input "data := map[string]string{"os": "darwin"} the output should be os=darwinian evolution, not os={{ .os }}ian evolution.
• Substitution should be flexible on word boundaries, e.g. given output /home/user and data := map[string]string{"h": "/home/user", "u": "user"} the output should be {{ .h }} and not /home/{{ .u }}.

There's an existing algorithm and existing tests, but the algorithm is slow (maybe O(N^2) at best) and the tests are incomplete.

Points for:

• Adding tests that demonstrate where the current algorithm fails.
• Writing code that passes these tests.
• Achieving better time and space complexity.
• Achieving better runtime.
• Supporting Unicode ([]rune), not strings ([]byte).

Currently chezmoi will populate all files. It is likely that some files will only be required on certain machines. For example, you may need ~/company.conf on your work machine, but this file should not exist on your home machine. At the moment, you can make ~/company.conf empty on your home machine using a template:

{{- if .chezmoi.hostname eq "work-laptop" }}
# contents of company.conf
{{- end -}}

but this will still result in an empty file on other machines. We need a mechanism to only populate files that should be present.

For config files. an empty file is more-or-less equivalent to an absent file. Perhaps we can use this.

chezmoi is currently targeted at macOS/Linux, but there is no reason why it shouldn't also run on Windows. Contributions improving Windows support are very welcome.

chezmoi cd fails without config file:

> chezmoi cd
open /usr/local/google/home/jhillyerd/.config/chezmoi/chezmoi.yaml: no such file or directory

chezmoi version fails with same error

version bdecf50 (HEAD -> master, tag: v0.0.8, origin/master, origin/HEAD)

Currently the "private" and "executable" attributes can only be changed by manually renaming the files in the source directory. For example, to make .netrc private, you have to do:

$ mv ~/.chezmoi/dot_netrc ~/.chezmoi/private_dot_netrc

It would be a nice to have a chezmoi command that updates the source file name appropriately. For example:

$ chezmoi chmod 0600 ~/.netrc

should do the rename above. Similarly for the executable bit.

Currently the diff command diffs all targets. It would be nice if the diff command could take a list of targets to diff, for example:

$ chezmoi diff ~/.bashrc

If the list of targets is empty, it should default to all targets.

Hi,
I just tried your program to synchronize my configuration files, however on my linux desktop I get the following error for any command:

Error: group: unknown groupid 210

How can I fix this?

CGamesPlay on Hacker News spotted:

Adding files should respect the chezmoiignore file (I never want chezmoi add -r ~/.config/fish to import my fish_history file).

running chezmoi add -T file, where file contains /Users/name/... results in /Users/{{ .chezmoi.username }}/... instead of {{ .chezmoi.homedir }}/....

I'm running chezmoi 1.0.0 (via homebrew) on MacOS X 10.14.2. When I try to add a file, I get this error:

chezmoi: group: unknown groupid 1493692218

Our machines are joined to an AD domain. I looked at issue #65 and #72, however it looks like this may only resolve the issue on Linux.

Anything I can do to assist, please let me know. Thanks!

chezmoi diff |less doesn't work, as the diffs are output to stderr

I'd also argue the log date stamps are not helpful, and make the diff harder to read.

As chezmoi gathers features, source directories might depend on features that are not present in older versions of chezmoi. chezmoi should include a way to specify the minimum version of chezmoi for the source directory to apply correctly, and issue an error or warning when the current version of chezmoi is too old.

As the number of supported password managers increases, the tutorial documentation in README.md is becoming increasingly repetitive and verbose.

There should be a reference document of all the template functions for password managers, i,e. bitwarden, lastpass, pass, vault, and (soon) onepassword.

Currently all target names are assumed relative to the target directory.

It would be nice if targets could be absolute or relative paths so that the user can use their shell autocompletion. For example,

$ chezmoi add ~/.bashrc

should work. In the case that the user is already in their home directory then relative paths should work, e.g.

$ chezmoi add .bashrc

chezmoi currently has support for storing secrets in LastPass, macOS Keychain, GNOME Keyring, and Windows Credential Manager. It is likely that individual companies will have their own mechanisms for storing secrets, and will not want to contribute code upstream to chezmoi to support them.

To make chezmoi useful in these environments, chezmoi should have a plugin mechanism, likely using Go Plugins.

As a rough initial sketch, it should be something like:

Config file includes a list of full paths to plugins:

plugins:
  - /usr/local/lib/chezmoi-initech.so

/usr/local/lib/chezmoi-initech.so is a Go Plugin that exports two functions:

Name() string returns the name of the plugin, e.g. "initech".

FuncMap() template.FuncMap returns a map of template functions which are added to the global namespace. An example function might be initechGetUserToken which takes a username and returns some user-specific token.

chezmoi should add a template function "plugin " which returns true if the plugin with the name <name> is loaded.

With this, internal, company-specific configuration code would look something like:

{{ if (plugin "initech.com") }}
initechToken = {{ initechGetUserToken .chezmoi.username }}
{{ end }}

On startup, chezmoi should load all plugins and add their functions to the global list of template functions.

habarnam on Reddit suggested following the XDG Base Directory Specification. This seems like a good idea.

The yet supported password managers are well selected. Usually I use "the standard unix password manager" which even has multi repo support.

pass should be a standard as well.

It's occasionally useful to unpack a tarball in to your home directory, for example to add a vim or zsh plugin.

chezmoi should have an import command that takes a tarball and unpacks it into the source directory, doing any necessary renames.

Example usage:

$ wget https://github.com/robbyrussell/oh-my-zsh/archive/master.tar.gz
$ chezmoi import --strip-components=1 master.tar.gz ~/.oh-my-zsh

chezmoi should be easily installable on RedHat systems. We should build and distribute a .rpm package.