<p>So I've been learning Go while doing my final degree and I have one question that I’ve been trying to solve with no luck, how can I externalize some settings on Go?</p>
<p>So far I’ve been writing them on JSONs that I parse in the main function, but those JSONs are not included in the compiled version of my project (when using go compile) and my main fails to open them as I use “./settings.json”.</p>
<p>During my degree, my teachers always said that it is good to externalize some settings, as well as other things that won’t change very much (such as the URI of an API REST) so that if you have to change some of it, you won’t have to recompile all the project just because one URI changes a letter but nothing more. I’ve always done this with Java (that’s the language my teachers always used and ask us to do it) so I always include those settings in the project and they are always within the exported version.</p>
<p>My question is if I can do something like that or what’s the best option that I could do to simulate that and why.</p>
<hr/>**评论：**<br/><br/>nsd433: <pre><p>If you want your settings compiled into the executable, but not strewn all over the code, create a settings.go file, put then there, compile it.</p>
<p>If you want your settings to be outside the executable then they need to be in that settings.json file you mention.</p></pre>TetAlius: <pre><p>The thing is that if I use the settings.go, every time I change one thing, I would have to recompile all my project, instead of just stop and start the execution, and this is what all my teachers said it was better in case you have a project that the compile process takes too much time. But, then again, they were only using java and when creating the jar in eclipse selecting those files to be included, so maybe in Go I cannot achieve that same behaviour and I have to choose between those two.
Thanks for the quick answer.</p></pre>Fwippy: <pre><p>You've probably noticed by now that go compiles pretty darn quickly, so that's not a super compelling reason to rely on external settings.</p>
<p>I suggest setting reasonable defaults in your go code, and for stuff that should be changed at runtime, use command-line flags (like <a href="/u/lespritd" rel="nofollow">/u/lespritd</a> mentions). If the settings are more complicated, you can use a <code>-configfile settings.json</code> type of option.</p>
<p>Basically, if your program <em>can</em> work without external configuration, you should provide reasonable defaults, and allow the user to override them if necessary. </p></pre>TetAlius: <pre><p>Yeah, I noticed Go compiles very quickly but, as I said, it is my final degree project for the university so it was kind of important to use the things they taught us and externalization was one of them, so I was asking in order to know if it was possible or not and why I used it or not.
The JSONs I’ve been using have no settings (yet) they have parts of the URIs I have to call for a REST service I’m using, so flags and environment variables (as <a href="https://www.reddit.com/user/lespritd" rel="nofollow">/u/lespritd</a> said) cannot be applied to this project (but maybe in a future project it can :D).
So, I think I’ll try to bundle the jsons on a zip (I like to have the parts of those URIs on a JSON) as <a href="https://www.reddit.com/user/vhodges" rel="nofollow">/u/vhodges</a> suggested</p></pre>lespritd: <pre><p><a href="http://12factor.net/" rel="nofollow">12 factor apps</a> recommend that all external settings be set via environment variables.</p>
<p>I've personally relied on command line flags. If you're not a fan of the built in <code>flags</code> package, there are a bunch of third party libraries that implement a variety of different behavior.</p></pre>TetAlius: <pre><p>I've never used the flags package, my project is in its early stages so I don't know if it will need them, but I am trying to use as few as possible third party libraries, so in case I would need anything, I would opt for the flags package. The things that I have externalized are some URIs that I have to call because I am using a REST API, so flags cannot be used in this context.
I wanted to know about externalization in general, so now I know that I can use flags for some settings (which I would love to try on a future project)</p></pre>ecmdome: <pre><p>I saw a few different good responses.</p>
<p>My favorite way is to give the user some options.</p>
<p>Option 1 and first to be loaded/checked are environment variables... Best place hands down to hold data.</p>
<p>If that fails, check for a json file with settings. Make sure to document where this file should go.</p>
<p>Last I would either notify the user he needs to add some settings, or fall back to default settings that your program will decide for the user.</p></pre>lacion: <pre><p>now days you can have dynamic settings (hot reload) easily using env vars or having a go routine looking for changes in the file to reload your settings.</p></pre>vhodges: <pre><p>If I understand your question (which is: "how can I bundle a config file with my executable like I do when I make a jar file" - but... I could only guess that after your response to <a href="/u/nsd433" rel="nofollow">/u/nsd433</a> ) then the answer is to use tar or zip to create a compressed file with the files you would like to distribute in it.</p>
<p><a href="https://en.wikipedia.org/wiki/Tar_(computing)" rel="nofollow">https://en.wikipedia.org/wiki/Tar_(computing)</a>
<a href="https://en.wikipedia.org/wiki/Zip_(file_format)" rel="nofollow">https://en.wikipedia.org/wiki/Zip_(file_format)</a></p>
<p>Jar files are the same kind of thing:
<a href="https://en.wikipedia.org/wiki/JAR_(file_format)" rel="nofollow">https://en.wikipedia.org/wiki/JAR_(file_format)</a></p></pre>TetAlius: <pre><p>Yeah... It was a bit complicated to express my question, but that was sort of it. The example that is more correct is that, during my degree we made a JSF web page with an sql and REST, but we used JBoss as the server, and when we run/compile it with eclipse (they wanted us to use eclipse u.u), all the settings, properties, sql and two different languages for the i18n (all of that were externalized in .xml, .properties and .sql) were inside a .WAR and that .WAR was automatically deployed inside the JBoss. So… now I wanted to replicate that behaviour, but I do not need anything like JBoss to serve my page, so I cannot deploy the files inside, but I wanted to know about externalization in general and not only in particular for my case. I now see that I did not express myself very well, although I can use the answers I received for my project
I hope this explanation does not confuse more.</p></pre>tv64738: <pre><p>"you won’t have to recompile all the project" -- and save all of 5 seconds? Do the simplest thing.</p></pre>TetAlius: <pre><p>It is not about the time go takes to compile (so far it's been like 1 or 2 seconds :D) but the fact that in our degree they teach us to externalize some properties, sql and more things that, if they change, anything in the code has to change again (for example the i18n translations) and, as this is my final degree project, I have to apply the knowledge they give me but, if externalization in go cannot be done the same as the tell us with java, that’s fine also, as long as I know the differences (in this case I didn’t and that’s why I asked).</p></pre>tv64738: <pre><p>The closest equivalent is putting your "externalized" things into a separate package. That means all the other <code>*.a</code> do not need to be recompiled, just linked.</p>
<p>Also, beware CS education that is stuck in "the one true way". Especially when that way smells of Java.</p></pre>
