Open raisedadead opened 1 year ago
I am also facing the same issue. Please provide a solution.
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
... 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.
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.
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
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