Open lhriley opened 3 years ago
Hi @lhriley, thank you for opening this issue.
The initial goal for creating more SDKs besides the full golang SDK was to provide an alternative method to the CLI for using secrets in your applications. The SDKs can be used to load secrets directly into your applications, instead of using secrethub run. This might be preferred, for example, when running a serverless function.
Extra functionality such as the functionality you describe would be awesome! It can very well be added, which indeed starts at https://github.com/secrethub/secrethub-xgo . We haven't made any plans for this yet. If you'd be interested to contribute, PRs are very welcome!
If you'd be interested to pick this up, I'm happy to answer any questions you may have about the implementation (or refer them to a colleague in case I don't have the answer :sweat_smile:). Feel free to ask any question here on GitHub or in the community chat.
@SimonBarendse I don't have the bandwidth to take this on at the moment, as my company hasn't yet made a decision on whether to use SecretHub. If we end up adopting this service, I may be able to schedule in some time to improve the feature set in the future.
As a developer, I want to be able to automate the creation of different resources within SecretHub by writing tools in Python.
Unfortunately, the Python SDK only handles basic functions centered around reading and writing secrets. This appears to be primarily a result of the current implementation of the https://github.com/secrethub/secrethub-xgo project as the features of the Python SDK are currently in parity with it.
Ideally, every SDK would have parity with the CLI / go code base functionality in order to avoid spawning the CLI in shell processes in order to accomplish various tasks.
High priority functionality might include:
Lower priority functionality might include: