I have a parseFile function that given a file parsing for certain information and returns a struct. How do I write a test for this function?
With Java, I could have a file in the test folder but I not sure how to best do it in Go.
Thanks and regards
You can do exactly the same in Go, albeit it is handled a bit differently.
Create a folder called "testdata" next to your *_test.go files.
This folder is by convention ignored by the go tools, as are all folders beginning with an underscore. This is why I name my resources directories for web applications _components instead of bower_components, for example.
Now, you can access said folder with a relative path from your tests, and it won't pollute your namespace or sth.
You should be able to commit a file to the same folder as your test, and read in a relative path by way of os.Open("./path_to_file").
If the issue is that you're looking for a file in a specific location, I'd recommend parameterizing whichever method loads the information to accept different filepaths.
Related
I have setup a simple website based off of this structure. I run main.go and everything works fine. I'd like to be able to use this webapp in another package, say "github.com/my/package". I copied "main.go" to the "github.com/my/package" directory and run it but then get:
"panic: open templates/user/view.html: no such file or directory"
What is the recommended way to modify the path to the template file in this file, for instance, so that I can access the templates? I can think of two solutions:
Hardcode an absolute path in view.go to the template file.
Have a global variable in view.go then figure out where the template files are in relation to the new main.go file & set the variable to that path.
The first will obviously break if someone else were to try to use the package. The second option is a bit convoluted b/c you need to find the path to main then work your way through & figure out where the templates are...seems very convoluted.
Is there a better way?
you could look at go-bindata. It makes external files, like templates, as part of the binary. Although it's not a great solution if you want to be able to change the templates without recompiling
If there is functionality meant to be used as a package/reused elsewhere, then the idiomatic way to do this is to move that functionality into a package - typically in the pkg directory.
Obligatory camlistore example is at https://github.com/camlistore/camlistore/tree/master/pkg
Another resource for how to do this is the '12 golang best practices' talk
My application uses json configuration files and other resources. Where should I place them in my project hierarchy?
I could not find the answer in http://golang.org/doc/code.html (How to Write Go Code)
Upd:
The question is not about automatic distribution of resources with application but much simpler: Where should I keep my resources in project hierarchy? Is there some standard place anyone expects them to be?
There is no single correct answer, nor are there any strong conventions assumed or enforced by any Go tooling at this time.
Typically I start by assuming that the files I need are located in the same directory from where the program will be run. For instance, suppose I need conf.json for myprog.go; then both of those files live together in the same directory and it works to just run something like
go build -o myprog && ./myprog
When I deploy the code, the myprog binary and conf.json live together on the server. The run/supervisor script needs to cd to that directory and then run the program.
This also works when you have a lot of resources; for instance, if you have a webserver with JS, CSS, and images, you just assume they're relative to cwd in the code and deploy the resource directories along with the server binary.
Another alternative to assuming a cwd is to have a -conf flag which the user can use to specify a configuration file. I typically use this for distributing command-line tools and open-source server applications that require a single configuration file. You could even use an -assets flag or something to point to a whole tree of resource files, if you wanted.
Finally, one more approach is to not have any resource files. go-bindata is a useful tool that I've used for this purpose -- it just encodes some data as bytes into a Go source file. That way it's all baked into your binary. I think this method is most useful when the resource data will rarely or never change, and is pretty small. (Otherwise you're going to be shipping around huge binaries.) One (kind of silly) example of when I've used go-bindata in the past was for baking a favicon into a really simple server which didn't otherwise require any extra files besides the server binary.
For static resource it might be the most convenient solution to include them in the binary similar to resources in Java. Newer Go version, at least 1.18 are providing the //go:embed directive to include content:
import (
_ "embed"
)
//go:embed myfile.txt
var myfile string
You can now use myfile in your code. E.g. IntelliJ provides also support for this.
There are also other options to include the content, e.g. as binary or dynamically, see the link.
I have a folder which contains an executable file (Exec.exe) and a lot of files that Exec.exe needs to run. Currently, it's pretty ugly having all of those files there when I only need to run the one executable. Is there any way to bundle them all into another executable that runs Exec.exe and also contains all of the files Exec.exe needs to run? Thanks for any help!
Yes, but I would recommend you only do it if you need to.
You can achieve this by adding your files as resources in your exe project, so they are added into the exe's binary at compile time. You can then access the files directly from your exe at runtime by using LoadResource and related functions. I'd recommend reading up on the Portable Executable (PE) file format if you're considering this route.
This is the way to do it if you, and again I stress, need to have only a single binary where you can still access your files. There are obvious downsides to doing this, such as it's much more coding to access the data as it's embedded in your application binary, and you can't easily update the files (check out resource hacker tool) without re-compiling your binary to include the new data.
If the only reason you want to do this is because it's "pretty ugly" seeing the additional files in the same directory as your exe, consider moving them into another directory, for example,
from:
MyExeDir
--myExe.exe
--myFile1.txt
--myFile2.dll
--myFile3.dat
to:
MyExeDir
--myExe.exe
--dat
----myFile1.txt
----myFile2.png
----myFile3.dat
or:
MyExeDir
--bin
----myExe.exe
--dat
----myFile1.txt
----myFile2.png
----myFile3.dat
So all the "ugly" looking files are out of the way.
Why don't you create a shortcut of "Exec.exe" and keep it somewhere handy ? If whats that you want ?
Or if you want to distribute your app, you can use Winrar/Winzip (winrar is the best) to create a compressed .exe of your entire folder, making "Exec.exe" as your startup app. Use the SFX option in winrar.
My application is to be written using wxWidgets, but the question may be related to using gettext in general.
For the application named app, some sources suggest I sould create <lang>/ subdirectory, create the app.po file inside with the translation, and convert it to the distributed app.mo file in the subdir.
Another approach is to create app.pot (i.e. the template from the sources via xgettext), and to msginit and msgmerge it to the <lang>.po for the language.
For the first approach, more .mo files can be put inside the <lang>/ subdirectory. Also the wxLocale::AddCatalog() gets the domain name (where the domain can naturally be app, wxstd, etc.). On the other hand, the <lang>.po file name is descriptive on itself -- wherever it is located.
What are the pros and cons of the two approaches? Is there any text that explains the path to be chosen?
Thanks for your time and experience,
Petr
The Unix convention is to use app.mo for binary catalogs, see the contents of /usr/share/locale directory. Sometimes lang.po is however used for the source ones, as done in wxWidgets itself (see its locale subdirectory), but they're still installed into language-specific subdirectory using the app-dependent name.
I did a bit of searching and found this thread on the topic but it's specific to XML files, and so the answer makes sense (/etc/) for XML files.
In my case, I'm actually storing a txt file, which happens to be an SVN version number that I dumped out within my modman script.
The place that I'm using this is within a frontend model (Blocks/System/Html.php) which outputs the version number within the module config. So I went with the Blocks/System/ directory for now - the filename is Version.txt - but it feels like there should be a better place to put this.
Since this SVN version number is being written by an external tool I would prefer it not mess with the contents of code directories (which in a live environment may have write restrictions) and instead have it write to the "var" directory. In which case to get the correct path within "var" you would use:
$fullpath = Mage::getBaseDir('var') . DS . $path;
The contents of "var" are disposable, they may be deleted at any time so be prepared for a missing file.
version numbers can be added to app/code/local/Your/Extension/etc/config.xml
<config>
<modules>
<Your_Extension>
<version>0.0.0.0</version>
</Your_Extension>
</modules>
</config>
magento knows how to handle your extension version changes and can call update scripts based on version number change. This is the preferred method for this kind of stuff.
if you need to add random non php classes files to your extension then add them to your extension folder and ask them from there:
Mage::getModuleDir('etc', 'Your_Extension');
Mage::getModuleDir('whateverfolder', 'Your_Extension');
This is not a good practice though as this might just break magento compilation feature or introduce other issues so it is better to handle external data also through php classes or xml files inside your extension structure
I ran into the same kind of problem when developing a shipping module. I had a bunch of CSV files that contained maximum weight / delivery cost mappings. For what it's worth, I created a data/ directory at the module level and threw everything in there.
I don't think this kind of situation doesn't happens often enough in the Magento codebase for there to be an established convention. As long as you use sensible naming, and provide a level of abstraction to cope with any change of file location in the future, I'd say put it in any folder at your module's root.