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
Related
I'm writing my first Go code which among other things, sends an email. After finding out that the package net/smtp only supports Plain Auth (but some providers like outlook doesn't support it), I asked for a solution and got pointed out to https://gist.github.com/andelf/5118732.
That code works like a charm, but as it's not something written by myself, I would like to add it in a separate file and just reference it in my main.go.
What's the right approach to have multiple files in the same package? I don't want to create a different package just for that code, first because it's not mine, and secondly, because I think it's an "overkill" approach, isn't it?
I thought that as long as the files are in the same directory, I could have many *.go files, but it seems it's not working out. If I just create a file with the content of that gist, the compiler fails because expected package, found import. If I add something like package auth, then it fails because found packages auth (auth.go) and main (main.go)
So, what's the general practice in this situations? Just create packages for everything?
You can have only one package in a directory, and it looks like you don't need a package for this addition, so you can simply put that in a separate file, and add package main at the top. Having a main package and putting everything under it works up to a point. As things get larger, you have to break it up into self-contained packages.
If your current working directory is in GOPATH, then you can just add new go file with same package name main.
If your current working directory is not in GOPATH, you can still put them in multiple go files and when you run the program, you should use go run *.go instead of just go run main.go.
There are also other options which you can refer Run code with multiple files in the same main package in GoLang for detail.
I am writing a Go command-line tool that generates some files based on templates.
The templates are located in the Git repository alongside the code for the command-line tool itself.
I wanted to allow the following:
The binary, wherever it is called from, should always find the templates directory.
The templates directory can be overriden by the user if need be.
Since this is a Go application, I went with something like:
templateRoot := filepath.Join(
os.Getenv("GOPATH"),
"src/github.com/myuser/myproject/templates",
)
But being rather new to Go, I wonder if this approach is reliable enough: is it guaranteed that my application template will always be accessible at that path ?
What if someone vendorize my application into their own project ? Does that even make sense for a command-line tool ?
Because of 2., I obviously can't/won't use go-bindata because I want to allow for the templates to be overriden if need be.
In summary: what is a good strategy to reliably refer to non-go, static files in a Go command-line tool ?
GOPATH is used for building the application. While you could look for GOPATH and check relative locations to each GOPATH entry at runtime, you can't be sure it will exist (unless of course you make it a prerequisite for running your application).
go get itself is a convenience for developers to fetch and build a go package. It relies on having a GOPATH (though there's a default now in go1.8), and GOBIN in your PATH. Many programs require extra steps not covered by the simple go tool, and have scripts or Makefiles to do the build. If you're targeting users that aren't developers, you need to provide a way to install into standard system paths anyway.
Do what any regular program would do, and use some well-known path to locate the template files. You can certainly add some logic in your program to check for a hierarchy of locations: relative to $GOPATH, relative to the binary, working directory, $HOME, etc; just provide a list of locations to the user that your program will look for templates.
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.
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 am using Xcode as part of my build for OS X, but since it is not the only IDE used, files may be added from the file system directly.
As far as I can tell, there are two ways of adding folders:
Folder reference picks up all the changes on the file system but does not register any of the files as sources.
Recursive copy allows for the files to be built but I need to constantly maintain the file structure
I am wondering if there was a way to setup Xcode to build all of the files that are a part of the folder reference or failing that, if there is a quick script to automagically fix file system discrepancies.
I came up with proof-of-concept solution that works, but will require some work to use in production. Basically, I set up a new "External Target", which compiles all source files in a given directory into a static library. Then the static library is linked into the Main Application.
In detail:
Create a directory (lets call it 'Code') inside your project directory and put some source code in it.
Create a Makefile in the Code directory to compile the source into a static library. Mine looks like this.*****
Create an External Target (lets call it 'ExternalCode') and point it to the Code directory where your source and Makefile reside.
Build the ExternalCode and create a reference to the compiled static library (ExternalCode.a) in the Products area of your project. Get Info on the reference and change the Path Type to "Relative to Built Product".
Make sure ExternalCode.a is in the "Link With Binary Libraries" section of your main target.
Add the ExternalCode target as a dependency of your main target
Add the Code directory to your "User Header Search Paths" of your main target.
Now when you drop some source files into 'Code', Xcode should recompile everything. I created a demo project as a proof of concept. To see it work in, copy B.h/m from the 'tmp' directory into the 'Codes' directory.
*Caveats: The Makefile I provided is oversimplified. If you want to use it in a real project, you'll need to spend some time getting all the build flags correct. You'll have to decide whether it's worth it to manually manage the build process instead of letting Xcode handle most of the details for you. And watch out for paths with whitespace in them; Make does not handle them very well.
Xcode's AppleScript dictionary has the nouns and verbs required to do these tasks. Assuming your other IDE's build scripts know what files are added/deleted, you could write very simple AppleScripts to act as the glue. For example a script could take a parameter specifying a file to add to the current open project in Xcode. Another script could take a parameter to remove a file from the current project. Then your other IDE could just call these scripts like any other command line tool in your build script.
I'm not aware of any built-in functionality to accomplish this. If you need it to be automatic, your best option may be to write a Folder Action AppleScript and attach it to your project folder.
In all likelihood it would be a rather difficult (and probably fairly brittle) solution, though.
It's not pretty, and I think it only solves half your problem but... If you recursively copy, then quit xcode. Then you delete the folders, and replace them with simlinks to the original folders, you at least have files that are seen as code, and they are in the same files as the other IDE is looking at... You still will need to manually add and remove files.
I sort of doubt that there's a better way to do this without some form of scripting (like folder actions) because xcode allows you to have multiple targets in one project, so it's not going to know that you want to automatically include all of the files in any particular target. So, you're going to have to manually add each file to the current target each time anyway...
One way to import another file from add/existing file:
and set your customization for new file that added .
see this