Open bgandon opened 6 years ago
And the only small improvement to make in this direction is for go-patch to accept op as an alias for type
im hesitant to add this change because it now introduces multiple ways to specify type of operation. now there is a choice of what key to use which i think would add unnecessary complexity to the overall interface.
As a BOSH deployment framework author, I'm concerned about this library not being an extension of RFC 6902 patches and RFC 6901 pointers. The only incompatibility right now, is the
type
key instead ofop
. The rest are (useful) extensions to the RFC standards.Let me tell you a bit more about my use-case. The point of GBE is to express many BOSH deployments that are tied together in order to collaborate nicely in an integrated way. Currently, GBE uses go-patch ops files for building deployment manifests. So only
go-patch
syntax is currently used and it's OK because ops files are specific to BOSH.Now in the near future, I need to introduce upstream sets of integrated BOSH deployments (that one could also call “GBE distributions”), that would be customized (or just configured) by downstream actual deployments.
GBE is based on modular subsystems, each one of these being described in a
spec.yml
file. I'd like to provide my GBE downstream users with the possibility to customize those subsys specs with elegant YAML patches. And I guess I'll need expressive operations for those YAML patches to actually be elegant. As I see thatbosh int
is quite limited in its feature set, I'm therefore wondering whether I should stick to it.For example, PCF-pipelines people have chosen the
yaml-patch
tool for customizing their pipelines.But in adopting a richer YAML patch syntax, I'd like it to find a balance with those 3 requirements:
go-patch
, because GBE is a great place for experimenting with new BOSH ops files. I expect my users to write ops files and possibly submit them to upstream release repositories if they turn out to be useful.That's why I'm advocating here for convergence between
go-patch
andyaml-patch
. And the only small improvement to make in this direction is forgo-patch
to acceptop
as an alias fortype
. And I wanted you to understand more in depth the reasons that are behind this request.So, could we accept
op
as an alias fortype
? I'll be happy to submit a PR for this.