Support loading a custom shared library path.

[itzTheMeow]

Adds an environment variable OP_SHARED_LIB_PATH to support loading a custom shared library file location.

Adds a WithSharedLibraryPath option to support loading a custom shared library file location.

This is useful for sandboxed contexts (such as nix) which don't have access to the /opt/1Password (or other) directory and must copy the library into the sandbox.

Related SDK PRs:

• Support loading a custom shared library path. onepassword-sdk-js#169
• Support loading a custom shared library path. onepassword-sdk-python#198

[itzTheMeow]

Perhaps I could also PR this to the other SDKs if this is approved?

[Marton6]

Thank you for the contribution! I like the idea of making the shared library path configurable in the SDKs.

However, I'm not convinced is the best way to achieve this. This approach conflicts with one of the design goals we had for the SDKs. Essentially, with this change, every app that uses the SDKs (with the desktop app integration) will start to behave differently depending on the value of an environment variable read by the SDKs (OP_SHARED_LIB_PATH).

This is not something a typical developer would expect of an SDK.

In my opinion, a better way to make this configurable would be to let integration developers opt into this behavior explicitly, e.g. by using a custom configuration function:

	onepassword.NewClient(context.Background(),
		onepassword.WithDesktopAppIntegration("YourAccountName"),
		onepassword.WithCustomDesktopAppPath("/my/custom/path/"),
	)

I think we can achieve this by adding a new field to the config and passing it into the GetSharedLibCore function here.

What do you think, @AndyTitu ?

[AndyTitu]

I agree with the above comment. Moreover, we should make sure this change is consistent across all SDKs (including python and JS).

[itzTheMeow]

I changed this to add a WithSharedLibraryPath function.
I opted to pass the custom path to find1PasswordLibPath() so that if the custom path is not found, it will fall back to the desktop app locations.

[itzTheMeow]

Since the structure has changed, would it make sense to put the WithSharedLibraryPath option in the _cgo file and add an error for non-cgo compilation similar to how WithDesktopIntegration now works? Since the two options are directly related.
I'll resolve the merge conflict with whichever option.

[CodeCorrupt]

+1 on this! I'm waiting for this merge so I can add support to the TF provider.

I have this work-aroundin my system configuration to make the TF provider work on NixOS.

{ pkgs, ... }:
{
  systemd.tmpfiles.rules = [
    "L+ /opt/1Password - - - - ${pkgs._1password-gui}/share/1password"
  ];
}

I'd like to be able to remove that so I don't have anything required to work on my project outside of the development shell.