I use rsync
to share the ~/.config
folder among the servers I have access to. Only recently I realized that I've never configured DVC successfully in my local macOS, and it triggers some hard to understand errors.
According to https://dvc.org/doc/command-reference/config#description, it's said the global configuration location for macOS $HOME/Library/Application\ Support/dvc
differs from that in Linux $HOME/.config/dvc/config
. This can be quite confusing because many macOS commands are configured in ~/.config
just like Linux.
I don't know why it's designed so, I assume there's a reason to not respect ~/.config/dvc
folder but it would be more user-friendly if at least throw a warning for this. A new entry in the troubleshooting page might be helpful, too.
This basically comes down to "macOS is not Linux". DVC looks for and places config files in Library/Application Support/...
on macOS, because that is the correct location for a well-behaved macOS application to store configuration files.
The XDG config location spec (~/.config/...
) is really a Linux specific convention (even though the directory structure will work on any unix system). One easy way to tell that macOS is not intended to conform to the XDG spec is that Apple never sets any of the XDG environment variables on macOS.
The simplest workaround for your rsync use case would probably be to just symlink .config/dvc
to Library/Application\ Support/dvc
on macOS.
Though git uses $HOME/.config/git/config
on MacOS even if XDG_CONFIG_HOME
is not set.
Similar to the fish shell warning, I was hoping DVC could throw an instructive warning for this, too. Or perhaps print the overridden non-credential configuration in dvc version
output, which could make the diagnosis easier. (I was about to submit a fake bug report wrt dvc pull
until then I realized that my s3 configuration in ~/.config/dvc/config
in macOS never get read)
Though git uses
$HOME/.config/git/config
on MacOS even ifXDG_CONFIG_HOME
is not set.
Sure, and there are several other *nix apps that do the same, including ones that will also look for dotfiles and .config\...
directly in C:\Users\<username>\
on Windows, but that's also something that we probably don't want to consider doing in DVC.
In this case, where we put everything for --local/--global/--system
for linux/windows/mac is clearly documented at https://dvc.org/doc/command-reference/config#config
Including config locations with dvc version
is something we could consider, but our version output is already pretty verbose as it is, and all of our configs go in the "correct" default locations for their respective platforms.
How about adding an environment variable to control the global DVC config path. Something like JUPYTER_CONFIG_DIR
for jupyter notebook.
@pmrowla Good point about dvc version
(aka dvc doctor
) getting crowded, but I also do remember bug reports in which I wished that I knew all the config locations that the user was using. So it does make sense to me to include configs into dvc doctor
. The command is not really user-facing, but more of a debugging aid for developers, so adding 4 more lines (local, repo, global, system configs) makes sense.