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: https://github.com/1Password/shell-plugins/blob/bd3f3edc2cc235e77a8163451c23d9c87e0045d2/nix/shell-plugins.nix#L55-L82

[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

[corneliusio]

Is there any movement on addressing this? The workaround provided doesn't appear to work for me. I think it's probably because I'm not symlinking the plugins.sh explicitly but instead I'm using gnu stow to link .config (everything is ignored by default with explicit .gitignore entries for what I want to track).

But also, I'm not explicitly using a plugin in this instance. I have my AWS credentials setup to load from 1Password using the cli. Below is how I've set that up in .aws/credentials

[default]
credential_process = sh -c "op --account=ACCOUNT.1password.com --vault=Private item get --format=json --fields=label=AccessKeyId,label=SecretAccessKey 'Amazon AWS' | jq 'map({key: .label, value: .value}) | from_entries + {Version: 1}'"

But this command gives me the error that it can't proceed due to .config/op being a symlink.