[16,17,20,37,38] Support for both versions in scripts

https://github.com/tmatilai/direnv-1password

🎉

I guess the OS env var issue has to be addressed in some way or the other. That can lead to hard-to-debug problems now.

Do you have examples of scenarios where you ran into hard to debug problems? Do you agree that OS envvars should be opt-out or do you think it'd be better for them to be opt-in?

I'm also planning to add opt-in sign-in support.

Just a heads up that there's a couple of changes coming up to the way op signin is used together with the new Biometric Unlock functionality. If you have it enabled, when you're not signed in, using any op command will prompt you to log in using your biometrics, so there's no need to have a separate op signin action in these cases. We're looking into adding the same behavior when you don't have the biometrics integration enabled.

So that'd mean you'll get the sign-in added to the direnv integration without any changes needed :)

the aim is that less and less secrets are needed on the workstations at all, and deployments, inter-service authentication, etc. are handled automatically

💯

We're planning on making the CLI available in these automated settings as well. op run, op inject andop read` already support using 1Password Connect (I see that's hidden in the https://developer.1password.com/docs/cli/reference/commands/run/, and there's no guide on using Connect for provisioning secrets using the CLI yet. I'll make sure we add more docs on that), and we're exploring adding Service Accounts. Here's a https://1password.community/discussion/125815 on authenticating these workflows. I'd love to hear your thoughts on that!

Besides this "raw" use of the CLI, we're also building integrations on top of it that integrate natively with workflows such as CI providers and orchestrators. Currently https://github.com/1Password/load-secrets-action and https://github.com/1Password/onepassword-operator are currently supported.

That said, just like you said I imagine there will continue to be a need to run some things locally. For example, if your developing an app that integrates with third-party services, you'll probably want to be able to run it locally with credentials to a development environment of those third-party services passed to the apps runtime. When doing incident response, you may need credentials to connect to the servers you're looking after.

The main issue with op run (or aws-vault which we had to use before Terraform supported AWS SSO natively) is that it is extra wrapper, which has to be remembered to type or scripted, and one extra component to debug and track issues with versions etc. Especially for a fast growing organisation.

I think this is one of those cases again where it's good to have multiple options. Depending on your workflow, one or the other fits better.

Personally, I'm a huge fan of Makefiles. They self-document what actions you can take in a repo and what commands to use for them. For fast growing organizations I really like the on-boarding aspect of that self-documentation. It also helps with standardizing, even beyond programming language barriers.
Using Makefiles, you don't even notice the new wrapper until you look in the contents of the file.

In your case, I imagine the dotenv integration or maybe using the https://github.com/1Password/terraform-provider-onepassword (backed by 1Password Connect) fits better?