Open jack-mil opened 2 months ago
So I'm not sure if this would solve your problem, but just in case it's helpful I've dealt with something similar by having two seperate files and having them both load the same template.
Just note that this would mean that the powershell file in each would be dynamically generated and therefore any changes made wouldn't flow back to the original. That may or may not matter to you.
If you need help setting this up, just let me know.
Similar issue and for me here:
[vim.files]
"vim/vimrc" = { target = "~/.vimrc", type = "symbolic" }
"vim/vimrc" = { target = "~/.config/nvim/init.vim", type = "symbolic", if = '(is_executable "nvim")' }
I should just move on from vim and wholly onto neovim, but I think there might be other valid use cases for this pattern?
EDIT:
In my case, a simple manual symlink to ~/.vimrc will suffice, as dotter deploys the last one read based on dotter/cache.toml
I keep running into other cases where it might be useful to have a configuration file shared across multiple dotter "packages". Today it was because I want the same MPV config for regular mpv-git and for an different mpv distribution that has a different config location.
How complex would implementing this feature be? I am guessing there is some architectural reason that this doesn't work out of the box. In toml, a table cannot have duplicate keys (so your example @hartigan43 is invalid toml), but the powershell example in my original post is valid. I would expect that to work, but there must be something that dotter is doing that requires (all?) keys to be unique, regardless of which table they are in?
I'm still a Rust beginner, but I will take a look myself when I get the chance.
Addendum: A similar restriction requires all variable names to be unique, across all packages. This is actually something that confused me starting out, because I had the (mistaken) assumption that variables would be scoped to packages.
I encountered this problem with Visual Studio code as I use the Code
and Code - OSS
builds. My workaround is to symlink on directory to the other in the post deploy script.
However I would really like to see an official feature supporting this.
I see it's a pretty highly requested feature and I see the uses, but I don't have the time and motivation right now to implement it. There's a couple design restrictions here
""
target which needs to still be supportedI can't think of the top of my head of a satisfying design for how to specify it in the configuration file, and I'm pretty sure the implementation assumes that there's one target per source so it might need some sweeping changes to support this.
I'm welcoming PRs on this :)
Some thoughts on the user configuration side for supporting this feature. For example, this configuration is invalid toml, and would not be supported:
# global.toml
# INVALID
[code.files]
vscode = "~/.config/Code/User"
vscode = "~/.config/VSCodium/User"
What makes more sense is to scope each app to a seperate package, like this: This configuration would be supported with keys scoped to the table names.
# global.toml
# OK, cannot deploy both 'vscode' and 'codium' packages (currently)
[vscode.files]
vscode = "~/.config/Code/User"
[codium.files]
vscode = "~/.config/VSCodium/User"
I think this is what most people would need. I believe it would be simpler than allowing a list of targets, as that could complicate the specification quite a bit. This configuration works currently, as long as you only pick to deploy either 'vscode' or 'codium' packages. The issue arrises when packages are merged together into one global namespace.
When a local.toml configuration requests packages = ["vscode", "codium"]
, the implementation trys to merge all packages into one, and runs into a duplicate key error. This is done so that a local.toml config can override individual file targets at the filename level with the [files]
table. At the local level, all filenames and variable package scope is discarded, and merged into one "package". I found this confusing starting out, as I expected to be able to override targets at the local.toml level with additional [<package>.files]
tables.
(Consequently, allowing defining packages at the local (untracked) level might be a useful feature)
In summary, a proposed local.toml
format that would work with the above global definition could look like:
# local.toml
packages = ["codium", "vscode"]
# additional overrides can be specified like
[codium.files]
vscode = "~/my/local/location"
[vscode.files]
vscode = ""
# could even specify package level variable overrides...
[vscode.variables]
special_var = "value"
Environment
0.13.3
Multiple destinations for same package file?
From what I have tried, it doesn't seem like this is possible at the moment. What I am trying to achieve is something like:
with the package folder
pwsh/
looking likeThis works fine if only
"pwsh"
or"powershell"
package is chosen (mutually exclusive, as seen in examples), but I would like to pick both. I want to link the profile.ps1 file to both locations. Is it possible right now? The only potential workaround I could think of is have one profile symlinked to the other in the dotfiles repository. But that could get messy with doubly linked symlinks (which I don't know if it is even possible? Symlink to a symlink?)The error I get is (unsurprisingly):