Dead ?

[joeblew99]

Just asking because i am using this with kubernetes and trying to avoid any c++ dependencies.

[jbeda]

While this hasn't been worked on recently I'm hoping we can motivate enough use via Kubernetes so it makes sense to start again. On Sun, Apr 23, 2017 at 9:29 AM jow blew notifications@github.com wrote:

Just asking because i am using this with kubernetes and trying to avoid any c++ dependencies.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/google/go-jsonnet/issues/14, or mute the thread https://github.com/notifications/unsubscribe-auth/AACRvhQurR0lqD4l6Q9Qpkpw33MTwDMiks5ry3xZgaJpZM4NFdWL .

[sparkprime]

Not dead, just resting :)

I'm not as plugged into the k8s community as I used to be (which wasn't very much anyway). If there is growing interest, is there some way we can track it? I have an intern coming in the Summer to work on Jsonnet, and not yet decided where to invest that effort.

[joeblew99]

there is a c --> golang converter. Its newish and has some loos edges still.

https://github.com/elliotchance/c2go

[jbeda]

Tagging @hausdorff to keep him in the loop as he has been working on https://github.com/heptio/kube.libsonnet and https://github.com/heptio/vscode-jsonnet.

[hausdorff]

To answer your question about how you can track the interest of the k8s community in Jsonnet, @sparkprime: there is a sig-apps thread where the community is starting to hash out what the next steps of improving the general app config story looks like, which has been influential enough that you can start to see this sentiment percolating to other parts of the community as well.

So, you could keep an eye out for those threads and threads like them, as they appear. If that's too much work for you, you can always just ask me when you want to know, since I think it is fair to say I probably have the most context about the direction the community is headed.

As those threads relate to this discussion, let me try to summarize briefly:

• A bunch of different companies have independently started using Jsonnet as the basis for various configuration problems the k8s ecosystem has. Particularly Bitnami, CoreOS, and Heptio (which I am an employee of).
• An effort to coalesce these efforts is actively underway, and this week we will have a sort of round table to discuss these efforts. Speaking for myself, I'm hoping to get a clearer idea of whether my picture of the problems people are having writing app config is accurate, and if so, how close our thoughts on how to solve those problems are to resonating.
• We have a number of problems to solve, so it's not yet clear to me how high a priority porting Jsonnet to Go is going to be, but my view is that it's fairly likely that this will be a common requirement among enough people in the group that it's something we'll want to start somewhat soon. Talking to the Helm folks, for example, my understanding is that it will be quite a lot easier to develop a plugin against a Go implementation, which is fairly high-leverage, since if that bears out well in terms of value, the plan would likely be to start transitioning the user base over to Jsonnet.

Let me know if you have any other questions.

[joeblew99]

@jbeda thanks for the links.

I am planning to use the jsonnet for k8, but also for code gen (sort of ) for go-kit and go micro. The reason jsonnet was chosen for K8, is the same for the microservices because you want each stage of the code gen to be driven from JSON, and each stge takes in JSON and outputs JSON. Its very similar to a Flow base programming idea with Inputs, the node that does the work, and outputs that can go to many places. This is perfect example that i can extend https://github.com/tockins/realize

Microservice Frameworks

• go-micro
  • https://github.com/micro/go-micro
  • https://micro.mu/explore/
• go-kit
  • https://github.com/go-kit/kit

[joeblew99]

@hausdorff yes please keep me in the loop if you can. Its nice that you offer.

golang based jsonnet is the ticket if you ask me. So its great to hear that k8 team is heading that way.

[sparkprime]

Thanks for that report. If we're in a position where adoption of Jsonnet is being held back by the unfinished go-jsonnet then that would definitely motivate me personally to prioritize this.

Although the Jsonnet language has moved on a bit since work ceased here, we can stage the development by first completing the language as it stood then, and then having some rounds of backwards compatible changes to add the new stuff. In the mean time people can integrate it / use it as long as they don't use the features that were introduced since then (named params, default arguments, etc).

The intern is here July -> October and I'm going to make a post nearer the time to gauge community interest in what he should do. We don't have to wait for him to do go-jsonnet of course.

[hausdorff]

My belief is that the Go port is probably not the biggest impediment to k8s adoption at this point. I'll say why, then briefly what I think is the biggest impediment.

The sig-apps round table happened on on Tuesday. Rick Spencer compiled the meeting notes here (and also a more concise, but also more opaque, summary is available on the sig-apps thread). If you read through the notes, you will see that the sig-apps community has already provisionally agreed to standardize app templating on Jsonnet.

While a feasible Go port certainly doesn't hurt, it seems to me that Jsonnet's biggest chance to lose this standing is if it became clear we'd have trouble accomplishing one of the important goals we have for adoption. To me the biggest unknowns lie in:

• Whether we can agree on a standard base library for the k8s API objects; we have a candidate PoC-quality library that we are piloting this with a partner who has > 10k lines of configuration.
• Toolability. If we can move the needle on even fairly simple static analysis features (tab completion, highlighting errors, calling up docs with onHover, etc.), then I think that will be the surest way to move the needle in Jsonnet's favor.

If we can execute on those things, I believe it will be trivial to stimulate demand for a Go Jsonnet port.

[sparkprime]

It's very interesting you say that (about tooling specifically) because my original proposal for this intern included a lot of options in that space -- doc gen, linter, better formatter, profiler, static analysis (find definition of), etc. These kinds of projects are likely to be much more interesting for an intern anyway than porting something that already exists, no matter how useful that port is.

[hausdorff]

Oh excellent. I've already started working on such things. Here is a working prototype of autocomplete:

We also have prototypes of other features, such as calling up the docs in response to an onHover event, etc. If there is shared interest, I would love to work with more people on the tooling story together. If this is something you're interested in, let me know how you'd like to proceed. I can, if you like, start a thread on the mailing list; or, I'm happy to let you guys take the lead if that more suits your taste.

[joeblew99]

i already installed it :) Nice Have not had time to play yet.

[hausdorff]

Oh, great! But, it will be some days before we roll out dot completion features. This is meant only to illustrate that we are serious about the tooling story. :)

[joeblew99]

got it. i am hoping that the google repo with the pure golang version gets some love. Will make it much easier to use in general

[sparkprime]

This is now being actively worked on.

[robfig]

Random question: Any plans to port the jsonnet formatter to Go? The motivation: I've written a Go program that generates jsonnet, and I'd like to pass the resulting jsonnet through a formatter without shelling out or using cgo.

Apologies for the drive-by, and thanks for the great technology!

[sbarzowski]

I think we will do it eventually, but it is not our top priority.

Actually "shelling out" seems to me like the best solution both long and short term.

• Unlike the language interpreter, tools such as the formatter are implementation-defined. Maintaining two versions at once would be really painful (it is already quite painful with the language, and we have a spec!). So I guess we will need to at least deprecate to cpp formatter when releasing one in Go, so that there is only one fully maintained version of formatter.
• It is useful to have a specific version of formatter pinned down per-project. So when formatted code gets committed, it won't get reformatted just because someone uses a newer version of some tool, which includes a newer formatter.

BTW please feel free to just open new issues when you have questions (definitely better than asking questions in an unrelated thread). Thanks 😄