feat: add cue encoder (#1)

[maurerbot]

• feat: add cue encoder

[github-actions]

👋 Thanks for contributing to Viper! You are awesome! 🎉

A maintainer will take a look at your pull request shortly. 👀

In the meantime: We are working on Viper v2 and we would love to hear your thoughts about what you like or don't like about Viper, so we can improve or fix those issues.

⏰ If you have a couple minutes, please take some time and share your thoughts: https://forms.gle/R6faU74qPRPAzchZ9

📣 If you've already given us your feedback, you can still help by spreading the news,
either by sharing the above link or telling people about this on Twitter:

https://twitter.com/sagikazarmark/status/1306904078967074816

Thank you! ❤️

[sagikazarmark]

Thanks for your PR @maurerbot !

Please see #1167 which will have to be merged first (containing some changes to the encoding interfaces).

Also, the plan is to not accept any more encoding packages in the core, but make them separate packages. I'd be happy to accept it for now though, because all the other packages are still in the core.

I have one problem though: dependencies (https://github.com/cuelang/cue/blob/master/go.mod)
It pulls in quite a few heavy dependencies which I'm not really happy to add back to the core.

In any case, #1167 will have to go first. Then we can decide whether this should go to the core or into a separate package.

[maurerbot]

hey @sagikazarmark, makes sense. I assume the plan is to use the new plugin/dynlinking feature for encoding extensions?

When the new encoding interface is merged will that be part of this version or v2?

I also think 17 will address the module size golang/go#36460

[sagikazarmark]

I assume the plan is to use the new plugin/dynlinking feature for encoding extensions?

No, than plan is for users to explicitly register codecs (ie. by importing them similarly to how sql drivers work). This is not clarified yet.

When the new encoding interface is merged will that be part of this version or v2?

The plan is to implement it in a way so we can use it in v1 as well. Initially, the implementation will remain in an internal package while we are working on the API, but the plan is to use it in v1 in the meantime as a sort of test to make sure it fits our use cases.

Apologies for the delay, but we are on summer holiday, so reviews will take longer than usual.

[maurerbot]

just merged upstream. anything with the new encoder registration that needs to change?

[sagikazarmark]

@maurerbot I merged the encoding layer refactor. I'm still reluctant to merge this as is because of the circular dependency question. The code can still be updated to use the new interface. I'll try to figure out a way to either merge it into the core or move it out of tree and use it from there (eg. through automatic registration).

I also think 17 will address the module size golang/go#36460

That doesn't work in 1.16 compatible mode.