1Password / shell-plugins

Seamless authentication for every tool in your terminal.
https://developer.1password.com/docs/cli/shell-plugins/
MIT License
519 stars 170 forks source link

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

Open raisedadead opened 1 year ago

raisedadead commented 1 year ago

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 commented 5 months ago

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

mrjones2014 commented 5 months ago

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 commented 5 months ago

... 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 commented 5 months ago

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 commented 5 months ago

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