Handle Tree operations in a separate class about sops HOT 8 CLOSED

From #48 :

The current implementation of SOPS is functionally based. This is good for programs that rely on transforming data. However, it's beginning to get unwieldy with all of the state passing it is doing (e.g. digest, iv, key, and in #47 unencrypted_suffix).

I suggest considering a refactor to swap out the core with something more class based so state is always located on self. I will create a gist to provide examples of what I mean.

from sops.

I started re-pitching this idea in #48. Here was an example approach for the tree:

https://gist.github.com/twolfson/d00d88af4c0a68749cf3

from sops.

To be honest, given all the issues we've had deployed sops as a client python app, I'm very tempted to rewrite it in Go and distribute statically compiled binaries. It's not just python 2.7/3 compat' that's the issue, but also dependencies on openssl for the crypto package, and others.
So, before we invest too much time rewriting a lot of the core, maybe we should evaluate the cost of rewriting in Go instead, just for the sake of the discussion.

from sops.

Can you explain further about OpenSSL/crypto for those unfamiliar with the problem (e.g. myself)?

from sops.

On El Capitan, Apple stopped shipping the OpenSSL headers, so to install sops one needs to first install the cryptography package with the following command: env LDFLAGS="-L$(brew --prefix openssl)/lib" CFLAGS="-I$(brew --prefix openssl)/include" pip install cryptography.
which is significantly more complex that just running pip install sops, but there's no way around it.

from sops.

Note that there are several limitations of the YAML support in Go which may make it a bad fit for sops, namely that the YAML package doesn't preserve comments through round-trips, and that we would need to walk the tree using reflections mostly, which can be painful and slow. Maybe, for the time being, sticking to Python is a better plan.

from sops.

Ah, that is unfortunate. Sorry, I totally skimmed over the OS X instructions in the README.

Throwing out Python for OpenSSL issues sounds like we are throwing the baby out with the bathwater.

Maybe we should consider also bundled Python packages (e.g. distributions which have dependencies in the same package)? requests does this https://github.com/kennethreitz/requests/tree/v2.9.1/requests/packages

Although, I think we could be wiser and not make them required during development but only as part of distribution (e.g. GitHub releases).

from sops.

We're now 100% Go so this can be closed.

from sops.