feature: Configuration file.

[cristianoliveira]

This issue is needed in order to enable run ergo using a custom TDL like .test or any other the user would like to use.

We need to decide the name of this file and its format.

[adiclepcea]

I would say it should follow (more or less) the layout of the config structure:

ergo/proxy/config.go

Lines 26 to 33 in 4ad9ad1

	type Config struct {
	Port string
	Domain string
	URLPattern string
	Verbose bool
	Services []Service
	ConfigFile string
	}

It should have at least port and domain. URLPattern can be deduced from the domain.
It could be a json or a yaml perhaps. In this respect, we should think about putting the services in the same file. This way we will have just one file, not two (config and services). I'm not sure if this the best ideea, but we already have them together in the config mentioned earlier.
Using an established notation (like json or yaml) would only make the things easier. For example an error when adding a service through ergo command line is much more less likely. Also there are tested and tried tools for working with them.

[cstadach]

isn 't there already the option to include a config file during the run option?
or is this a different one?

I'd like to try solving this by using the https://gopkg.in/yaml.v2 and a yaml file that can be called via a command line option hook

[ghost]

TOML is pretty common for unix-based OS's... and it has pretty good support in Go. Thoughts?

[ghost]

My biggest problem with using something like YAML (don't get me wrong.. it can be really cool), is that it can be pretty hard to create simple/trouble-free mappings for very simple configs. JSON is pretty verbose but is well known/easy to write, TOML is pretty simple but not very well known, HCL is super nice but also not very well known... don't get me started on code (Turing complete) based options (as cool as that could be).

[cstadach]

from what I understand we are just looking for 5 simple key value pairs which is really easy to write in both yaml and toml

[adiclepcea]

If you include the services, then you can have an arbitrary number of values.
Granted, it is not a complex structure, but there can be a lot of values.
There are both advantages and disadvantages to all.
The advantage for json is that it is already integrated into Go. You can simply map a structure to json and back.
For yaml you need a library, but that is not such a big issue.
For TOML is the same as yaml.
If we go for YAML, we should discourage manual editing of the configuration file. Yaml uses only tab indentation.
If we go for TOML we should explain that in the readme (and that can be quite simple).
If we go for JSON, then we have less explaining to do.
But... we have another option ...
We can have an interface that loads the config, then we can have simple implementations in all of them. This way a user has a choice.
In my opinion, if I have to choose only one, for ergo, that would be TOML.
There are huge projects (like CloudFoundry) that have the configuration in YAML, so that is also a valid choice.

[cstadach]

I think it is smarter to stick to one and mention it in the readme.
otherwise somebody will decide to use a filetype we have not anticipated

[adiclepcea]

Ok. Let's vote.
I'll choose TOML. 👍

[cstadach]

something like this?

Port = 8080 
Domain = .dev 
URLPattern =  
Verbose = false

[services]
foo = http://localhost:3000
bla = http://localhost:5000
withspaces = http://localhost:8080
one.domain = http://localhost:8081
two.domain = http://localhost:8082
redis://redislocal = redis://localhost:6543

[ghost]

I like the look of the TOML 😋

…

-sent from my OnePlus X

On Oct 25, 2017 3:39 PM, "Christian" ***@***.***> wrote: something like this? Port = 8080 Domain = .dev URLPattern = Verbose = false [services] foo = http://localhost:3000 bla = http://localhost:5000 withspaces = http://localhost:8080 one.domain = http://localhost:8081 two.domain = http://localhost:8082 redis://redislocal = redis://localhost:6543 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#69 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIIciL2cV7BkH56KAqnovA8sA8cIVfknks5sv454gaJpZM4QEZmv> .

[cstadach]

I had to make the toml look a bit different, but this is a first wip commit
After the tests are changed accordingly this should work

[cristianoliveira]

My only concern about having the services inside the configuration files is that it becomes being a little bureaucratic to manage. :/

Today for adding a new service you can use a simple

echo "foo http://localhost:3000" >> .ergo

and is pretty much it for adding a new service. The idea is to have the same flexibility of /etc/hosts. Do you guys think worth having them inside this config file?

I was thinking in this file more like something apart from the common flow. If you don't want to have custom configurations for ergo you don't need to be aware of its syntax or even its existence. Just use plain old "hosts" like syntax.

I am familiar with TOML syntax I know it from Rust's cargo config file. I think it is pretty simple, my vote would be for it also. :)

[cstadach]

That would make the implementation a lot easier.
I seem to remember an AddService method implemented somewhere. Shouldn't that be the way to add services?

[adiclepcea]

I do agree that having services inside the config would make it a bit more difficult to manage.
I think however that by having two files (one for services and one for config) would also somewhat complicate the solution. On the other side, it would be easier for the user to manually add services.
In my mind, the one file solution would be the the way to go, but that is only one opinion. Below I will say why.

• Think about the fact that you would have two files with two different formats for services and configuration.
• Also, you have the possibility to use ergo itself to add services (and soon to remove them).
• Manual edit of the file should be discouraged in my opinion as user error is more likely to happen when doing manual edits. Just imagine a scenario where a user has some 100 services, does a manual edit and ... deletes by mistake two lines, or two lines and a half...
• There are lots of services in linux using other formats than the plain hosts file, and if someone prefers using that format, then they can just use the old /etc/hosts file.
• I do not believe that the difficulty of adding a service is much increased with a format like TOML.

That being said, I will bow to the power of the crowd 😃 And, of course, to the power of the project owner.

[cstadach]

the -config configFile option is included quite deeply into ergo.
adding the new config file like I imagined it would need a huge overhaul of the code and would lead to conflicts to other issues (f.e. remove services).

Unfortunatelly I do not have so much time on my hands to do this right now.

I will add a Pull Request with the work I have done so far (watch the first commit)
But I will not have time to work on this any longer.

[cristianoliveira]

I was thinking to use ENV variables to solve those configs. What do you think about it?

Something like:

export ERGO_DOMAIN=.foo
export ERGO_PORT=8080

# or
ERGO_DOMAIN=.foo ergo run

Pros:

• Very Simple
• Very Flexible

Cons:

• It is not configurable by "folder" but globally
• No structure at all

[adiclepcea]

That is a good ideea, but I also think we should consider two configuration options.
Like you have for most of the programs that use env as their configuration source (see JAVA - CLASSPATH).
So we should have env (as the ultimate source of truth) and also some flags for ergo.
So basically, if the flags are set and the env is not set, then the flags are considered the valid setup, but if the env is also set, then the env is considered the valid setup.
This way you can also use ergo in dockers (by passing env variables or running it inside a docker with parameters).
For the docker side, however, a config file could be "beneficial" at least, because you could have configs passed as secrets in docker.
However, since there is no need for much secrecy, I guess, the env solution is a good option.
I was going to try to work on the config file solution, but ... I am kind of caught up in work now.

[cristianoliveira]

I was going to try to work on the config file solution, but ... I am kind of caught up in work now.

No worries, let decide it first

[cristianoliveira]

PR related #95