Allow plugins.sh to be stowed or tracked in dotfiles as symlinks

[raisedadead]

op CLI version

2.19.0-beta.01

Goal or desired behavior

Currently, the CLI expects ~/.config/op/plugins.sh to be a file. I would like to keep it in my dotfiles and symlink it to the requisite location.

Current behavior

[ERROR] 2023/09/03 01:15:00 Can't continue. We can't safely access "/Users/mrugesh/.config/op/plugins.sh" because it's a symbolic link. Replace the linked file with the original file and try again.

Relevant log output

No response

[parikshith078]

I am also facing the same issue. Please provide a solution.

[mrjones2014]

This is definitely something we should address. I'm not sure the best solution. Possibly just documentation?

This isn't documented very well, but the plugins.sh is basically just aliases to alias plugin="op plugin run -- plugin", and if you set OP_PLUGINS_SOURCED=1 as an environment variable, the CLI will assume the aliases have already been set up. Thus, you can configure the plugins via your own file that you can track in source control and not use plugins.sh at all by adding, for example, for GitHub CLI:

export OP_PLUGINS_SOURCED="1"
alias gh="op plugin run -- gh"

to your own shell config file.

This is essentially how the Nix Flake integration works:

shell-plugins/nix/shell-plugins.nix

Lines 55 to 82 in bd3f3ed

	# Explanation:
	# Map over `cfg.plugins` (the value of the `plugins` option provided by the user)
	# and for each package specified, get the executable name, then create a shell alias
	# of the form:
	# `alias {pkg}="op plugin run -- {pkg}"`
	# where `{pkg}` is the executable name of the package
	aliases = listToAttrs (map (package: {
	name = package;
	value = "op plugin run -- ${package}";
	}) pkg-exe-names);
	packages = [ pkgs._1password ] ++ cfg.plugins;
	in mkIf cfg.enable (mkMerge [
	({
	programs = {
	bash.shellAliases = aliases;
	zsh.shellAliases = aliases;
	fish.shellAliases = aliases;
	};
	} // optionalAttrs is-home-manager {
	home = {
	inherit packages;
	sessionVariables = { OP_PLUGINS_SOURCED = "1"; };
	};
	} // optionalAttrs (!is-home-manager) {
	environment = {
	systemPackages = packages;
	variables = { OP_PLUGINS_SOURCED = "1"; };
	};

[raisedadead]

... Thus, you can configure the plugins via your own file that you can track in source control and not use plugins.sh at all ...

That's a decent workaround. Assuming this can be documented? The thing to note is doesn't the command op plugin init <plugin> initialize the plugin.sh file in the first place?

How about adding a note (as comments) in the plugin.sh files, I am thinking on the top the file that explains the workaround you suggested? That should be enough information IMHO.

[mrjones2014]

Yeah, the current default flow is that plugins.sh is managed by op plugin init. This admittedly is not ideal for setups where you're tracking config files in a git repo, and it's what motivated me to build the Nix Flake for Shell Plugins (as I'm a Nix + home-manager user myself and had run into the same problem with my own setup, especially since Nix uses a readonly filesystem).

@SimonBarendse maybe we could even explain this in the output of op plugin init itself? Curious to get some ideas from others.

[troponaut]

Well I don't really remember where I got this, but I used to set OP_PLUGIN_ALIASES_SOURCED=1, which at some point stopped working. So I guess OP_PLUGINS_SOURCED is the correct env var