evanpurkhiser / dots Goto Github PK

When no groups are set, dots will happily run w/out error leaving the user to figure out why nothing got installed.

dots should emit a warning when there are no groups set for installation.

I've had some ideas bouncing around in my head about a updated version of this tool that's hopefully just as powerful, but even easier to configure and more manageable. Here's some ideas I wanted to write down:

Configurations stored in the repository

Right now when you want to setup your dotfiles on a machine you have to decide all of what groups you want to be installed. If you have more than a few groups this can be annoying to manage. Why not put this part of the configuration in version control?

My thought would be to have a dots.yml (or json possibly) file in the root of your ~/.local/etc/ dotfiles clone that has some configuration for that set of dotfiles along with some other global configurations for the dotfile repository itself. My current configurations would look something like this

# Prefix to use for explicit append points
append_prefix: '!!@@'

# The file suffix used for override files
override_suffix: override

# Compilation installation path.
# Supports environment variable expansions using ${VARIBLE}
install_path: ${HOME}/.config

groups:
  - base
  - machines/desktop
  - machines/work-laptop
  - common/work-system

# Groups to compile for all profiles
base_groups: [ base ]

# Configuration profiles. Each configuration profile should map to a list of
# source paths to compile. Order defines the cascade order.
config_profiles:
  desktop:
    - common/graphical
    - common/pulseaudio
    - machines/desktop
  macbook:
    - common/osx-homebrew
    - machines/macbook
  work-macbook:
    - common/osx-homebrew
    - common/work-system
  work-vm:
    - common/work-system

Something like dots config set desktop would select the desktop configuration.

Configuration lockfile

Right now it can be a little frustrating to test some new configuration files only to remove them from your source later and then find that they're still cluttering your configuration installation directory. This can be especially annoying when they have some continued configuration side effect.

Inspired by library package managers I had the idea of a 'dots/lockfile' which would be installed with the compiled files.

{
    "profile": "desktop",
    "installed_files": [
        "/home/evan/.config/bash/bashrc"
        "/home/evan/.config/git/config",
        "/home/evan/.config/termite/config",
    ]
}

This will simply allow us to know what files were installed previously so that we can know what files are no longer needed and can be removed.

Other things

• Better verbose output. It should say exactly what it's doing.
• TESTING

Hi,

Not neccessary an issue with the code, but maybe with the documentation.

When trying to execute the "dots help" or any other dots command I get warning about:

$ dots help
/usr/bin/env: python2.7: No such file or directory

Fixing the python pointer to my actual python version (2.6.6) yields:

$ dots help
Traceback (most recent call last):
File "~/.local/bin/dots", line 83, in
import argparse
ImportError: No module named argparse

So what I can read from this little "test" is that dots is not compatible with python < 2.7?

Maybe the requirements should be stated in the documentation? Or maybe I have misunderstood something and it should be compatible with python2.6 too?

Anyway, seems like a nice tool, Ill try it on some of my other system and see if it works there :) The system I had problem with is RHEL6.5

• Kristian -

I don't like keeping my repository in ~/.local/etc/, especially since I have my own conventions for storing repositories that I frequently update.

SOURCE_DIR should be able to be set from both the command-line, and be read from a configuration file. (e.g. ~/.config/dots/source_dir)

If we assume that the users source configuration directory is under source control ($HOME/.local/etc) then we can keep track of what global version of files have been installed. This would allow us to keep track of what files have been removed since the last configuration install.

So for example when calling the dots install command with no given path we could write a file called config-version to $XDG_CONFIG_HOME. Then during the next install we could look at that version and compare it with the current version of the source configuration files. We could then see what files have been removed and remove those from the installed dotfiles directory.

Dots should have a verbose mode that tells you all the files it is about to copy and what processing (substitutions, installation scripts, etc) are being performed.

Following that, it'd be nice to have a "dry-run" mode where it tells you what will be copied, but does not actually copied.

With the new implemented correct hashing of utf-8 files in commit d252369 the python 2.7 support gets broken, because the python 2.7 open command doesn't have a encoding argument.

When an enabled group is missing (the directory doesn't exist) then it should simply be ignored (and a warning should be displayed), instead of raising an error causing program termination.

A '--force' flag for install, or something similar, that forces dots to rerun all installation scripts (*.install files).

At the moment, dots only will execute an installation script if the corresponding configuration file has changed.

Instead of executing .install immediately upon installation of a configuration file, they should be executed after all files have been installed.

Currently, when an .install-script that isn't executable is to be executed, the application fails with a cryptic:

[Errno 13]: Permission denied

(which is what subprocess.Popen throws here, when it can't run a script) That's a terrible error message to debug.

Instead I'd suggest to handle it either by a) attempting to chmod +x it manually or by b) exiting with a message that explains what script caused the error.

It'd be nice if dots worked w/ both Python 2 and 3.

When I try to run it:

$ python3 ./dots
name 'single_directory_groups' is not defined

At the moment, config-groups is in ~/.config/. It's not obvious that this file belongs to dots.

Since #6 will require more configuration be stored, config-groups should be moved into ~/.config/dots/.

Since OSX uses bash 3 by default some of our completion features fail with errors. We should see if we can work this out so it either works with bash 3, or is simply disabled unless the user is using bash 4.

There are also some small inconsistencies in GNU vs BSD utils that the completion script uses (mainly with the find command for caching file and group lists)

If a directory has any files updated in it then we should execute .install files for that directory.

Need to look into this.

I have adopted Yan Pritzker's idea of separating vim settings in topical files under settings and a file settings.vim that calls them. Dots does not like this and complains that settings is a directory:

~$ DOTS_DEBUG=true dots install 
Traceback (most recent call last):
  File "/home/ing001/.local/bin/dots", line 602, in <module>
    config.install_tree(args.location, args.file, True)
  File "/home/ing001/.local/bin/dots", line 281, in install_tree
    [f.install(to, exec_install_scripts) for f in self.files(path_filters)]
  File "/home/ing001/.local/bin/dots", line 274, in files
    return [f for f in files if not f.is_named_fragment()]
  File "/home/ing001/.local/bin/dots", line 399, in is_named_fragment
    return match.group(2) in target_file.named_append_points()
  File "/home/ing001/.local/bin/dots", line 375, in named_append_points
    with open(path, 'r') as file:
IOError: [Errno 21] Is a directory: '/home/ing001/.local/etc/base/vim/settings'

~$ ls -l .local/etc/base/vim/
drwxr-xr-x 2  settings
-rw-r--r-- 1  settings.vim
-rwxr-xr-x  vimrc
-rwxr-xr-x  vimrc.install
drwxr-xr-x  vundles
-rw-r--r--  vundles.vim

I have worked around this by calling settings.vim for handle_settings.vim and the same with vundles.vim, but would prefer not to have to do that ;=) Is this a bug or a side effect of the way you handle merging different groups etc.?