search

nikaro / sopsy

sops python wrapper library
http://sopsy.nikaro.net/
MIT License
17 stars 1 forks source link

Embed SOPS binary in the python package #62

Open nikaro opened 4 months ago

nikaro commented 4 months ago

Maybe find a way to embed SOPS binary in the python package to avoid depending on the system one.

nikaro commented 4 months ago

It would need to be included at build time and would require to build a wheel per-platform. Not sure i want to complicate the build process for this...

nikaro commented 2 months ago

Re-open as this is something i still may want to do. The wheel per-platform could be easily done thanks to https://github.com/nikaro/sopsy/pull/71.

walidmujahid commented 2 weeks ago

I am speaking with no familiarity with this codebase, but how trivial might it be to implement a way to provide your own path to SOPS binary compared to packaging it straight up? I'm thinking if sopsy allows us to provide paths to the required binary in our own packages, we can handle it on our end.

I found this library today as part of some research I am doing for a deployment of an internal tool to a serverless function, and my first thought actually was "how do I get sopsy to read the SOPS binary I'm prepackaging/that's in non-PATH location?"

nikaro commented 2 weeks ago

I am speaking with no familiarity with this codebase, but how trivial might it be to implement a way to provide your own path to SOPS binary compared to packaging it straight up? I'm thinking if sopsy allows us to provide paths to the required binary in our own packages, we can handle it on our end.

It should be pretty easy to do it. And it could be a good step towards solving this issue. Let me give it a try.

BTW, initially i was thinking into embedding the sops binary into the sopsy package, but finally i prefer to have the choice available:

walidmujahid commented 2 weeks ago
  • a "light" sopsy package like it is today
  • and a sopsy[binary] version that would depend on an extra and independent sops-binary package

I like the idea of having a binary option by the way, but I think having two options is the best route as you seem to have concluded. Maybe in the end, most people may end up using the binary version over vanilla/light (getting community feedback over the long term would be a good idea and could determine whether eventually make a major change by having the binary as default while keep vanilla/light around for backwards compatibility) :-)

By the way, I will be joining the community of users for sopsy. Thank you for the effort of making and maintaining this library.