New backend for getting credentials from environment variables

[wwuck]

I'm planning to implement a keyring backend for getting credentials from environment variables. This will be useful in CI environments (eg. Jenkins) for easily passing credentials from the CI credential store to pip and other tools that support keyring.

The current plan is to use environment variable format like this:

KEYRING_SERVICE_NAME_0=https://index0.example.com
KEYRING_SERVICE_USERNAME_0=myusername
KEYRING_SERVICE_PASSWORD_0=mypassword
KEYRING_SERVICE_NAME_1=https://index1.example.com
KEYRING_SERVICE_USERNAME_1=myusername1
KEYRING_SERVICE_PASSWORD_1=mypassword1

Is this format acceptable, or should I avoid using the KEYRING_ prefix?

I don't think there is any need to allow keyring to set any username or password environment variables through this backend, so it would end up being a read-only backend supporting the get operation but not set or del.

Are there any potential issues I've missed with an implementation like this?

[jaraco]

Your idea sounds feasible. I'd recommend to go ahead and implement your backend as a third-party plugin. You can even use the keyrings namespace. There's some guidance in the readme. All you need is a Python package with an entry point that indicates your backend. Then install it alongside keyring and it should be available.

Use that to get started and experiment. Once you have something you're happy with, publish it on PyPI and write back here and we'll get a mention of it in the readme for others to discover. If it becomes super-popular, we'll consider integrating it in as a default keyring.

Feel free to ask if you have any trouble getting started with your project.

[wwuck]

Ok thanks. I did look at using the keyrings namespace, but it appears that flit doesn't like packages with that naming format. I'll take a second look on that.

[jaraco]

Indeed, it looks like flit doesn’t support namespace packages. pypa/flit#370

You’ll need to use Setuptools or some packaging tool that supports them.

[wwuck]

Hmmm ok. Is it a hard requirement for new keyring backends to use namespaces? I can see that most of the third-party keyring backends listed do not use the keyrings namespace. I would like to use a namespace, however I don't feel like I should need to use the bloat of setuptools for such a tiny package.

Hopefully it will come to flit soon? pypa/flit#453

[jaraco]

For what it's worth, Setuptools is evolving and getting less bloated, but I respect (and share) the concern.

And you're right, the package doesn't have to be a namespace package. It only needs to be if it's called keyrings.*. Feel free to create a package with another name.

I would ask that you not name it keyrings_* just to avoid pseudo-colliding with the namespace.

[wwuck]

I would ask that you not name it keyrings_* just to avoid pseudo-colliding with the namespace.

That was my next question! My original thought was keyrings_envvars but I'll think of a different name for this, perhaps envvars-keyring? Suggestions welcome!

[matthewsht]

As a likely consumer of such a module, I'd ask that it be a namespace module - keyrings.envvars just makes the most sense to me. $0.02 consumed...

…

-- Hunter Matthews Scientific System Engineer [C] NIH/National Human Genome Research Institute ***@***.******@***.***> | (919) 491-2124 On Nov 9, 2021, at 7:23 PM, wwuck ***@***.******@***.***>> wrote: I would ask that you not name it keyrings_* just to avoid pseudo-colliding with the namespace. That was my next question! My original thought was keyrings_envvars but I'll think of a different name for this. Suggestions welcome! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#539 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ATFEQQ5VGEO3OUKZZF7KCXTULG3QLANCNFSM5HGCVTNQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[wwuck]

It looks like flit will soon support PEP 420 namespaces.

pypa/flit#468

I'm hoping this will be sufficient @jaraco? Some of the other keyring backend packages look like they are using the older pre-PEP-420 style of namespacing.

I will get onto this as soon as that feature lands in flit. The base code for the backend is mostly complete, just needing this extra packaging and some more unit tests to get to 100% coverage.

[jaraco]

I'm hoping this will be sufficient @jaraco? Some of the other keyring backend packages look like they are using the older pre-PEP-420 style of namespacing.

There are two styles of namespace packages that preceded PEP 420. Fortunately, keyrings is using the pkgutil-style namespaces, which are compatible with PEP 420, so shouldn't be a problem.

[wwuck]

This is currently blocked on pypi/warehouse#10030. I can't upload the new package for testing to TestPyPI or PyPI until that is fixed.

[wwuck]

Now that warehouse is fixed, I've published this to pypi at https://pypi.org/project/keyrings.envvars/.