Allow disabling keyring

[Popkornium18]

This PR allows disabling the keyring completely. I have found myself often in situations where the keyring caused a lot of trouble. Checking whether the keyring was available would cause poetry to hang indefinetely. Rather than fixing broken keyring setups on various Linux systems I would much rather just disable the keyring altogether and accept the risk of plaintext credentials.

• Added tests for changed code.
• Updated documentation for changed code.

[github-actions]

Deploy preview for website ready!

✅ Preview
https://website-owlh0kvmj-python-poetry.vercel.app

Built with commit de19d4a.
This pull request is being automatically deployed with vercel-action

[radoering]

Looks good in general. I wonder if we should add some kind of tests in password_manager to check that keyring is not used when calling certain methods or if this does not add much value?

[Popkornium18]

I made all the changes you requestet @radoering.

Looks good in general. I wonder if we should add some kind of tests in password_manager to check that keyring is not used when calling certain methods or if this does not add much value?

What certain methods would this be?

[radoering]

It's probably just like "when use_keyring is not set, then none of the methods of PasswordManager tries to access keyring. I can imagine a test that replaces keyring with a mock, then calls each method and afterwards checks that the mock was never called.

[Popkornium18]

It's probably just like "when use_keyring is not set, then none of the methods of PasswordManager tries to access keyring. I can imagine a test that replaces keyring with a mock, then calls each method and afterwards checks that the mock was never called.

I implemented such a test and actually found an issue with it, so I guess it is necessary. Not sure what you think of the attempt to detect code-changes that were not reflected in the test. Looks weird, but I think it might be worth it. Better to have one more place to make a change than a bug.

[radoering]

I implemented such a test and actually found an issue with it, so I guess it is necessary.

Nice.

Not sure what you think of the attempt to detect code-changes that were not reflected in the test. Looks weird, but I think it might be worth it. Better to have one more place to make a change than a bug.

I completely agree. I don't think it's an issue that the unit test of password_manager has to be adapted if password_manager is changed.

The test looks good to me. Just a small suggestion to make the idea behind the test more clear.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.