I'm developing a small tool with Go. And recently, I noticed that the tool needs to be invoked from a shell script, because it's using shell function.
Assume my tool is called atool. So, go build generates a binary atool, and my tool has a Go structure as github.com/myaccount/atool. Now, i want to build atool-cli binary with go build, and invoke it from shell script atool. How can I achieve this?
The only way coming in my mind is change go structure as github.com/myaccuont/atool-cli. But I don't want to do this because the already announced, and also, the path seems a bit funny name.
Just to make my comment "official":
go build -o atool-cli github.com/you/atool
One way packages structure themselves as a library, and provide main packages is to put their main entrypoints in subdirectories.
You can have a main package in github.com/myaccount/atool/atool-cli, which imports github.com/myaccount/atool and implements func main(). Some packages with multiple commands even have a /cmd/ directory with multiple cli tools that can be built (see camlistore as an example)
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 can specify dependencies to be downloaded by go get after checking out my project by importing them. I can even force the download of packages that are not used in the code by importing them for side effects:
import _ "github.com/jteeuwen/go-bindata"
Furthermore, on the shell I can apparently install a program with go get by using an ellipsis after the path:
$ go get github.com/jteeuwen/go-bindata/...
However, it seems I cannot combine both techniques:
import _ "github.com/jteeuwen/go-bindata/..."
$ go get
main.go:9:8: open c:\gopath\src\github.com\jteeuwen\go-bindata\...: Access denied
I would like to tell go get that for building (actually go generateing) this project, go-bindata has to be installed. Is it possible to specify install-dependencies?
To answer your question: No.
But you could vendor go-bindata into your project which would make it available after after go geting your project.
But maybe there is a slight confusion about when and why to run go generate: The intended use for go generate (as I understand it) is for package or command authors to generate code during the development phase. Code which is checked in and processed "normally" by go {build,install,get}. So you run go generate, check in the generated stuff and users of your package go get it and do not run go generate. They don't need to, the code comes in the proper checked in version during geting.
For more complicated builds which a end-user has to perform: Use Makefiles or similar tools as such stuff is out of the scope of go get.
In one of my projects I use Godep. According to its page:
This tool assumes you are working in a standard Go workspace, as
described in http://golang.org/doc/code.html. We expect godep to build
on Go 1.4* or newer, but you can use it on any project that works with
Go 1 or newer.
You'll have your dependencies in a JSON file, just like Node, Bower, etc... It's vert simple to use.
In your case, assuming you already have go geted the package, run:
godep save
This will generate the JSON file with all your other dependencies and save to a folder in your project. Thanks to it I was capable of cross compiling my project.
I'm playing with golang and made a tool for password generation. Initially it was intended to be used as a command line tool. I later separated the generation logic into a separate package (still same github repository) and left the main function in the root of the project. Now I also want to add a simple web frontend (nothing fancy), but I don't know how to structure the packages.
Am I supposed to put both the command line entry point as well as the web UI into their own packages in the same project (which leaves the root empty). Or maybe I should move the actual generation library to the root and the UIs in separate packages. I guess the other option is to have the UIs in separate projects on github, but they are only going to be used for this library, so it does not seem like a good idea.
I remember seeing in some projects packages named cmd for example, but never have I encountered one, with multiple front ends. Is there a go(-gettable-)way for doing this?
I agree that there's not much point in making separate projects/repositories if they're only going to be used for this library. I would just have a cmd directory with a subdirectory for each executable you're building.
Something like this:
github.com/user/project
generation
cmd
cmdline
main.go
web
main.go
The main.go files can use the functionality that you've broken out into your "generation" package.
The name of the executables produced by go build will be the name of the parent directory, so cmdline and web in this example (you would want to choose better names).
Note: you don't actually have a package cmdline or web. The files in those directories would all be in [their own separate] package main.
I would like to use signatures for a program that I am writing in Go, but I can't figure out the documentation, which is here. In particular, I would like to use the SignPKCS1v15 and VerifyPKCS1v15 functions, but I'm not sure exactly what I have to pass as arguments. I would greatly benefit from some example code of these two functions. Thanks.
Note: The message that I would like to send is a struct that I defined.
I think the src\pkg\crypto\rsa\pkcs1v15_test.go file in the Go source tree should be a good start.
An update striving provide more context… Go source contains many tests for the code in its standard library (and the crypto/rsa package is a part of it), so whenever you have no idea how to use a standard package (or, actually, any other Go package), a good place to start is to look at the tests involving that package as testing code naturally uses the package! Tests are kept in files ending in _test.go, usually have meaningful names and are located in the same directories actual code implementing a particular package is kept.
So in your particular case you could do this:
Download the Go source package of the version matching your compiler (what go version shows) and unpack it somewhere.
Navigate to the directory matching the package of interest. Code for standard Go packages is located in the "pkg" directory under the "src" top-level directory, so if you're interested in the crypto/rsa package, you need the src/pkg/crypto/rsa directory.