Executable config

[j0tunn]

No description provided.

[SevInf]

What problems does the executable config solves which current config and plugins can not solve? YAML config is nice and readable and I can get what is going on with just glance on it which is not the case, for example, enb and Karma config.
Config already supports overriding options, plugins can be used to launch something before or after the launch or alter config before execution. So, what does it solves exactly?

[j0tunn]

@SevInf It allows the communication between plugins. For example we can pass function as an option to some plugin.
Anyway this PR adds ABILITY to use executable config. One can still use .yml

[SevInf]

@j0tunn I assume it is for gemini-testing/gemini-tunnel#9.
What kind of complicated logic for picking a free port requires a function and why this function can't be a part of a plugin?

[j0tunn]

The problem is we should start server first (thats a not a vanilla http server). And we have a plugin for that. Both plugins should know about that free port.

[SevInf]

Why the plugin thats start the server can't just set the port for a tunnel once it started the server?

[j0tunn]

The order of plugin execution is not guaranteed. And free port allocation is an async operation

[SevInf]

Async is not a problem, startRunner event uses emitAndWait. Regarding the order:

1. Plugins are executed in order of keys of plugins config object, which is guaranteed in ES2015 by standard and de-facto guaranteed in ES5 by v8.
2. Making the order of plugins defined will be generally a good idea.

[j0tunn]

Async in fact is a problem, because emitAndWait doesn't help us: second plugin should start only when first has finished its work.
Also it would be not very nice to have plugin that somehow affects other plugin (silently)

[j0tunn]

Why are you against the .js configs?

[SevInf]

Config file should be declarative and easy to read. Any JS config I've ever seen is a horrible mess that requires you to gaze into it for a long time to get what is going on there (enb, grunt, karma, webpack, list continues).
A lot of effort was put into making sure that existing config is powerful enough without needing to be executable. The stuff like per-browser overrides, env variables overrides or plugins probably woudn't be there if we went with js configs from the beginning, but it keeps the config easy to read without having mentally execute JS.
Yes, YML configs are not going away, but existence of JS config encourages bad practices.

[j0tunn]

A lot of effort was put into making sure that existing config is powerful enough without needing to be executable. The stuff like per-browser overrides, env variables overrides or plugins probably woudn't be there if we went with js configs from the beginning, but it keeps the config easy to read without having mentally execute JS.

All this stuff will help to make config easy and readable

[SevInf]

No, it will not, because why would you go through publishing a plugin when you can just write all the stuff you need inside a config? Why would you configure environment on your CI if just can do if (isDev) computeConfigA() else computeConfigB() Nobody will care about config transforming to program until it becomes another enb/make.js.

[j0tunn]

why would you go through publishing a plugin when you can just write all the stuff you need inside a config?

to localise specific functionality. Yes, I'll do it

Why would you configure environment on your CI if just can do if (isDev) computeConfigA() else computeConfigB()

Don't you think that it would be convenient to make such configuration in gemini config file instead of some top level script, that will generate .gemini.yml and than launch gemini with that config? Just because gemini can't read executable script. Thats a real case, we already have such project!

Nobody will care about config transforming to program until it becomes another enb/make.js

Thats totally up to the users. If they want to have simple config - they will have simple config, gemini provides ability for that. If they don't - they will have totally messy crap around gemini anyway.

Such restriction just moves complexity from gemini config to some additional stuff.

[SevInf]

Don't you think that it would be convenient to make such configuration in gemini config file instead of some top level script, that will generate .gemini.yml and than launch gemini with that config

I don't think either approach is good. In the end, if the plugins are so dependent on each other why are they separate? All need for for executable config will go away if you just merge them into one.

Before you say "We want to keep public tunnel plugin": plugin is just a function and nothing prevents your private plugin from depending on it and doing require('gemini-tunnel')(gemini, {port: 123456}) when you know the port.

[j0tunn]

We want to use tunnel plugin with or without server plugin. One project - only tunnel plugin, other project - tunnel with server. They are about different stuff, they can work separately. They will work separately. Why should we join them? Just to keep our config simple? Just to keep somebody's config simple?

Your point is "Do any spikes you need, but don't make config executable". But we want a simple straightforward way to do some configuration stuff. Config file is the best place for that stuff.

Again, this PR adds ABILITY to do more complicated things in config. Still anyone can use simple .yml configs.

[j0tunn]

@SwinX @sipayRT @arikon take a look, please

[sipayRT]

config config

[j0tunn]

ну да, сначала имя параметра - config, а затем описание - config or path to config file