Thanks@lmmx for the proposal and the PR 🙏

The CI workflow does not install the project dependencies so the linting step is failing.

You can addkeyring to thelinting requirements and then runpip-compile --output-file=requirements/linting.txt requirements/linting.in

Is the approach of try/except ImportError: pass acceptable? An alternative would be to set a variable that could be used to gate the calling of the keyring module.

We haveemail-validator as an optional dependency inPydantic. Please take a look atpydantic.networks.py and especiallyimport_email_validator.
Also, I think we need to includeKeyringSettingsSource in sources ifkeyring is installed.

How should I implement error handling for the access of the variables? (As mentioned in the original proposal). If the keyring is locked it will raise an error. I haven't added this handling to keep the original proposal simple.

I think you can raise aSettingsError

I think we need to have:

• Proper support on Linux and Mac
• Tests
• Documentation

TODO list

• pip compile
• Optional dependency import
• Settings source edit
• raiseSettingsError upon keyring variable access error
• Linux support
  • Implemented viasecretstorage as described
• Mac OSX support
• Tests
• Documentation

No comments 👍

• pip compile
• raiseSettingsError upon keyring variable access error
• Linux support
• Documentation

Optional dependency import

The example ofemail_validator goes like so:

• TYPE_CHECKING conditional block that imports the optional dependency else sets it to Nonesource

• Helper function calledimport_email_validator() that may raiseImportError, followed by differential declaration of a class that relies on it dependent on theTYPE_CHECKING context (if so, just declaring asAnnotated[str, ...]).source

Settings source edit

Also, I think we need to includeKeyringSettingsSource in sources ifkeyring is installed.

I hadn't thought of that, I just added it and let it default toNone, I'll review...

Mac support

OS X has asecurity module whichkeyring can access and adump-keychain method which would provide equivalent functionality. I need to look at this in more detail.

Tests

I used this as a dependency in an early stage projectmagic-scrapehere (dependency declaredhere) and by patching thepydantic_settings.KeyringSettingsSource.__call__ methodhere (equivalently I could also have patched the_read_keyring method) I have been able to test the integration of this with my package.

This already helped me uncover and fix bugs in the implementation (in case sensitivity handling), so testing should be easy to build off of this.

I thought about the way pydantic is importing optional dependencies and as I recalled seeing a cleaner way in pandas, I reviewed their approach,import_optional_dependency.source ->example usage

The rest of the comment explains why I'm choosing a combination of both, if it's of interest!

Theirs is not type equivalent: in pydantic the TYPE_CHECKING block ensures the type of the module name is always an imported module's type, whereas in pandas the return type of the helper function isOptional. This is only permissible there because they use--skip-unannotated and said helper function has no annotated return type.

Theirs is however cleaner: the import site is not required to be wrapped inif TYPE_CHECKING, and indeed their_optional.py module has scaled well to handle many optional deps.

pydantic's approach usesglobal to redefine the module which was imported asNone in the else condition of theif TYPE_CHECKING block used to spoof the module type as if it were a non-Optional dependency.

We can parameteriseglobals()[package_name] instead and put theTYPE_CHECKING condition within the helper function, thereby achieving the same outcome (spoofed always-module that's actuallyOptional) but without the overhead at site of use. I expect this would look cleaner and hope this would therefore be acceptable in my PR.

In this case I would need to add multiple import lines to the block:

ifTYPE_CHECKING:importkeyringfromkeyring.backends.SecretServiceimportKeyringasSecretServiceKeyringelse:keyring=NoneSecretServiceKeyring=None

as opposed to one line, without aTYPE_CHECKING block

keyring,SecretServiceKeyring=import_optional_dependency("keyring","keyring.backends.SecretService.Keyring")

I'll put it together and fall back to the template of the single-module import function if I've misjudged part of this or if you don't like the idea.

May I ask what the status of this PR is?