dotbot had a hardcoded behaviour that the BASEDIR was always passed to
os.path.realpath which "returns the canonical path of the specified
filename, eliminating any symbolic links encountered in the path".
This might not always be desirable so this commit makes it configurable
using a command line flag, `--no-realpath-base`.
The use case where `--no-realpath-base` comes in handy is the following:
You want to provide dotfiles in the Filesystem Hierarchy Standard under
`/usr/local/share/ypid_dotfiles/`. Now you want to provide
`.config/dotfiles` as a default in `/etc/skel`. When you now
pre-configure `/etc/skel` by running dotbot in it set has HOME, dotfiles
will refer to `/usr/local/share/ypid_dotfiles/` and not
`/etc/skel/.config/dotfiles` which does not look nice.
This is related to but not the same as the `relative` parameter used
with link commands.
Because 'bin/dotbot' is a hybrid sh/Python script that finds the
appropriate Python binary and then runs, the test code should not invoke
it as an sh script when sh does not source the pyenv initialization
script.
The fix implemented in this patch is to directly run 'bin/dotbot' as a
Python script using 'python', which when called from bash, will run with
the correct Python version (because bash is set up to source the pyenv
initialization script).
This patch removes the snapshot/rollback system for the tests and
replaces it with a simple cleanup script that removes the appropriate
files from the VM's $HOME before every test. A side benefit is that
there is no more dependency on the Sahara plugin.
The cleanup script may not provide as good isolation between independent
tests as the previous setup, but it is orders of magnitude faster to run
without a VM rollback for every single test, and it does not break any
of the current tests.
Previous to this patch, having a config like the following would not
work properly:
- link:
~/a: ~/b
This was because the '~' was expanded on the left hand side (the link
target), but not the right hand side (the link source). It was necessary
to use a workaround like this:
- link:
~/a: $HOME/b
This was because variable expansion was being done, but user expansion
was not being done.
This commit adds support for using '~' in the link source.
Prior to this patch, the following config led to incorrect behavior:
- link:
~/.folder/file:
path: file
create: true
relative: true
relink: true
Prior to the change, running the config the first time would result in
expected behavior. However, running the config for the second time would
result in deletion and re-creation of the link (even when the link is
correct).
This patch improves the interaction of relink and relative, taking
relative paths into account when checking the validity of existing links
in the `_delete()` method.
This commit adds an option to the extended configuration syntax for
linking files and directories. Enabling the relative option makes it so
that symbolic links are created with relative paths instead of absolute
paths.
