[SM-1147] Switch to try_init with pyo3_log

[coltonhurst]

Type of change

• Bug fix
• New feature development
• Tech debt (refactoring, code cleanup, dependency upgrades, etc)
• Build/deploy pipeline (DevOps)
• Other

Objective

When running the ansible-playbook command, we needed to export the following variable: export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES. This suppresses fork safety warnings on Mac OS. With this set, you can safely query for individual secrets. However, if you query for secrets within an Ansible loop or with a Jinja2 template, we receive an error that is caused by setting up a logger more than once. (This error comes from the pyo3_log crate.)

If we switch to using the pyo3_log::try_init function, we ignore the case where a logger is already set up if the attempt fails. This happens because the pyo3_log::init function can panic. This also introduces panic safety.

Code changes

• client.rs: Switch to try_init

Before you submit

• Please add unit tests where it makes sense to do so

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 4 lines in your changes are missing coverage. Please review.

Project coverage is 60.59%. Comparing base (67e743f) to head (4c5b926).

Files	Patch %	Lines
crates/bitwarden-py/src/client.rs	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #676      +/-   ##
==========================================
- Coverage   60.61%   60.59%   -0.02%     
==========================================
  Files         170      170              
  Lines       10387    10390       +3     
==========================================
  Hits         6296     6296              
- Misses       4091     4094       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dani-garcia]

LGTM, we're already doing the same thing for the c and napi bindings, seems like we forgot this one.

sdk/crates/bitwarden-c/src/c.rs

Line 27 in 67e743f

let _ = env_logger::try_init();

sdk/crates/bitwarden-napi/src/client.rs

Lines 34 to 36 in 67e743f

	let _ = env_logger::Builder::from_default_env()
	.filter_level(convert_level(log_level.unwrap_or(LogLevel::Info)))
	.try_init();

[Thomas-Avery]

LGTM

[coltonhurst]

Added a comment and let for consistency across crates in 4c5b926.

[mittkkoo]

I'm sorry for the dumb question, but how to implement this fix on my side? I'm using Bitwarden Secrets with the ansible lookup plugin. I did cargo build in crates/bws as in the newest state of the main branch and then cargo install --path ., but what next? The lookup plugin still fails with a panic error as before.

[jacobfelknor]

@mittkkoo, I'm facing the same issue as you with the Ansible integration.

If you followed the directions for setup in the Bitwarden Documentation, I believe it doesn't use the bws cli you installed/built with cargo (maintainer, please correct me if I'm wrong), but instead only uses the bitwarden-sdk PyPI package.

I think we must wait until a new version of bitwarden-sdk is published to PyPI