remove the need for config init function

[twhiston]

This PR:

• removes the need to have config.json in bindata
• makes config init function into ConfigInit and called from the cli main function
• Refactors ConfigInit to escape early if in setup mode, and simplifies around config file loading
• renames pwd var for clarity

One change in how things work is that now it requires that you pass in the config file option, as there is no default, i believe this should be the correct behavior. However perhaps we wish to make it more user friendly by looking in the pwd if no value is passed in?

[strangeman]

In doSetup() we creating a config file. I think we should provide it as a default value for -config.

[strangeman]

This is not directly related to this PR, but why we use two dashes for migrate here? flag package uses one dash by default.

[twhiston]

Well technically it should be 2 dashes with a long option as the posix standard is a single dash when its a single letter name and a double dash for a word.

https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html

[strangeman]

I know but go has its own way. :)

[twhiston]

I would say in this case the wrong way 😝 why break with tradition? I actually prefer the flags packages that impose the posix standard on go flags! (for example pflags or viper). We had a ticket about this too somewhere as someone asked why we don't follow the standard. In reality as the flags package lets us specify either I think we are all good for now 😄

[twhiston]

In reference to your other comment... As far as I can see we only create a config file if the -setup option is passed and that puts us in to the interactive setup mode to create the config (or in the docker script also passes in a set of options stdin to make it non interactive) this option being passed now causes ConfigInit to bail early before the file checking is done so we don't need to provide a default. Is there something else I'm missing here?

[strangeman]

Right, so (in my opinion) we should support following flow:

1. The user doing an initial setup via -setup option
2. Then he just launching semaphore without any options and get fully functional service

[twhiston]

how can we enforce that? part of the setup is to ask where the temp dir should be and save the config file there (though this will change a little due to #457). We have no way of knowing where the user told us to save the file once the setup command exits, so on the next run we have no way of knowing what the 'correct' config file is to use.
IMO the fact that the end of the setup function explicitly tells you to call semaphore again with the config flag, and prints the location you need to use, is an indicator that it will not run properly without this value.

[strangeman]

Oh, sorry, I forgot that. I thought that semaphore saves config to his own directory. Yeah, then we can just explicitly say something like 'run ./semaphore -config blahblah for using your settings' and there is no need to default value.

[twhiston]

Thanks for the approval.

I think you have a nice idea here though and I'll add it in #457 - Ask for a seperate config output dir, offer the cwd as a default and if no -config option is provided look in the cwd for a file to use