-
-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New backend for getting credentials from environment variables #539
Comments
Your idea sounds feasible. I'd recommend to go ahead and implement your backend as a third-party plugin. You can even use the 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. |
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. |
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. |
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 |
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 I would ask that you not name it |
That was my next question! My original thought was |
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>.
|
It looks like flit will soon support PEP 420 namespaces. 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. |
There are two styles of namespace packages that preceded PEP 420. Fortunately, |
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. |
Now that warehouse is fixed, I've published this to pypi at https://pypi.org/project/keyrings.envvars/. |
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:
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 notset
ordel
.Are there any potential issues I've missed with an implementation like this?
The text was updated successfully, but these errors were encountered: