dotter
dotter copied to clipboard
[FEATURE] Add copy target type
Is your feature request related to a problem? Please describe.
I am configuring a theme for SDDM (an X display manager) that requires an image file to be placed somewhere in /usr/share/sddm/themes/
, so privilege escalation is required.
My dotfiles folder is located in my home directory, so it is not ideal to use a symlink because firstly, it is a security risk; and secondly, it doesn't really make sense for a system-wide configuration file to symlink to a user file.
Furthermore, my home directory is encrypted using fscrypt
, and is only unlocked after logging in, so using a symlink wouldnt't work.
Using the template
target type allows us to copy text files, but for non-text files, we get stream did not contain valid UTF-8
as the file stream is interpreted as UTF-8.
Describe the solution you'd like
A new copy
target type that can be specified when configuring a complex target:
[some_package.files]
'some_image.png' = { target = '/some/system/directory/some_image.png', type = 'copy', owner = 'root' }
I think this would be useful in conjunction with the owner
field and for other scenarios in which symlinks aren't desirable.
Describe alternatives you've considered I've tried:
- using the
template
target type, but as mentioned above, this won't work for non-text files - using the post-deploy hook to manually copy the file, which works, but it's not really an elegant solution
- creating a separate dotfiles folder in the root directory and then running
dotter
as root, which also works, but ideally I would like to have all my dotfiles in one location
Additional context
$ uname -srvo
Linux 5.10.42-1-MANJARO #1 SMP PREEMPT Thu Jun 3 14:37:11 UTC 2021 GNU/Linux
This does seem pretty important to support to me. I'm debating whether it should be a new type or if it's enough for the template type to fallback to copying on non-utf files... I'm leaning towards the latter, but I need to check which would make more sense in the context of the code.
PR appreciated :D
I think it would make more sense semantically for it to be a new type as it doesn't really make sense to template non-text files (e.g. binaries, media, etc.). Relying on a fallback to copy feels more like a hacky approach, and may not be intuitive to users.
There's also an opportunity for a performance benefit. If I have some non-templated text files that I want to copy somewhere as is, I could specify the target type as copy
instead of template
so that we don't run all the Handlebars processing unnecessarily.
I'd be happy to write up a PR! Though I'm quite limited on time so no guarantees.
Good points and I agree. Also, the error message for non-utf templates could hint you to use copy instead.
Until this happens can there be a warning when the target is outside $HOME.