skylark plugins? about gnorm HOT 11 OPEN

Please expand, and how is this a bug?

from gnorm.

I removed the bug label... it was a misclick, but I can't remove the history of what happened (at least, I don't think so).

So... skylark is an embedded interpreter for skylark, which is a language that is essentially python-lite. It's exactly python syntax with some restrictions on what is and is not supported.

The nice thing is that python syntax is familiar to a lot of people (more so than Lua, the only other language offering an embedded interpreter in go). And it means that you can distribute plaintext files as plugins, with no external dependencies. That's a lot friendlier to end users.

from gnorm.

Ah! Okay, sorry I also missed the removed part, just saw the red flag and stopped there.

So you are saying adding native support for this? I thought the plugins as we know now have arisen from thinking in language agnostic way.

This can completely be handled by an external plugin that does skylark gymnastics leaving the gnorm binary to do what its best at i.e code generation.

Any ideas how you want to integrate this?

from gnorm.

interesting idea to have a plugin that handles skylark plugins. I like that it keeps the main gnorm code simpler.... but at the same time, it means you now have to worry about two executables when running any random gnorm build - gnorm and gnorm-sky (or whatever we'd call it)

I see skylark plugins as a really great option for people that want to distribute "themes" with no dependencies outside of the gnorm binary. For internal corporate use, you can just build any old binary plugin and not need to worry about the end user, because you know what your fellow devs will have installed on their workstation.

I don't exactly know how to integrate it yet, because I haven't had a chance to dive into skylark. I don't entirely understand how data gets into and out of a skylark plugin, for example (the API talks about setting global variables, but not entirely sure how that works in practice).

My idea is that it'll work basically like plugins do now. you say {{plugin "foo.sky" "funcName" .}} and then gnorm knows that because it's a .sky file, it should run it using the embedded skylark interpreter and somehow pass the data to the given function (that part I don't know how to do, or if there's a better way to do it given the way skylark works).

from gnorm.

A quick glance on skylark godoc shows that the globals doesn't mean global env vars as we know, more like global context on the program/file execution.

Still, I believe my idea to outsource skylark support is solid. We introduced plugins to allow extending the functionality without jeopardizing gnorm sanity.

So, here is what I am thinking.

Say you have a file dark.sky assuming the extension is .sky and you want to execute the file with the skylark plugin.

First, our current plugin is limiting in the number of arguments and contexts to pass. i.e

{{plugin "skylark" "dark.sky" . }} this will execute the file and render the output. However we might want to pass custom settings or call them flags to the plugin to add more context, like providing the global values for execution in addition to the context e.t.c.

One easy workaround is to add a helper function for assigning values to maps or slices, which returns new maps or slices with the new values added.

{{assign . "level" 4} provided context is a map[string]interface{} will return a new map with copies of original context and m["level"]=4.

This way the plugin will be extremely configurable.

The whole point of custom directories for plugins is for people serious enough with what they run i.e corporate e.t.c . If they were happy enough to have the gnorm binary it won't hurt them to have skylark plugin binary that they can ship with the templates.

from gnorm.

FYI - this is a good example of how to actually use skylark: https://github.com/google/skylark/blob/master/example_test.go#L21

from gnorm.

Very neat, maybe they were targeting embedding of the interpreter in Go.

from gnorm.

Yeah, that's exactly what I'm talking about - having the interpreter embedded in Go, so that plugin authors just need to write a .sky file and gnorm can run them with a few lines of code that imports the skylark package.... no external binary needed.

from gnorm.

Since the external plugin will still be a go program that embeds the interpreter. Instead of guessing, how about we start with external plugin, and when users like it enough we can add native support for it.

I'm skeptic because today is like the first time I heard about skylark, and natively supporting a feature that has no users is an overkill.

from gnorm.

that is a really really good point :) . I agree. :)

from gnorm.

relevant link https://github.com/natefinch/skyhook

from gnorm.