Stellar's public monorepo of go code
This repo is the home for all of the public Go code produced by the Stellar Development Foundation.
This repo contains various tools and services that you can use and deploy, as well as the SDK you can use to develop applications that integrate with the Stellar network.
This repository is officially supported on the last two releases of Go.
gocommand will automatically download dependencies required for that operation.
You can choose to checkout this repository into a GOPATH or into any directory.
In addition to the other top-level packages, there are a few special directories that contain specific types of packages:
http.Handlerthat make it easier to incorporate portions of the Stellar protocol into your own http server.
Each of these directories have their own README file that explain further the nature of their contents.
In addition to the packages described above, this repository contains various packages related to working with the Stellar network from a go program. It's recommended that you use godoc to browse the documentation for each.
While much of the code in individual packages is organized based upon different developers' personal preferences, many of the packages follow a simple convention for organizing the declarations inside of a package that aim to aid in your ability to find code.
In each package, there may be one or more of a set of common files:
main.go(public symbols) or
internal.go(private symbols). These files contain, respectively, the exported and unexported vars, consts, types and funcs for the package. New packages do not follow this pattern, and instead follow the standard Go convention to co-locate structs and their methods in the same files.
mainfunction as part of an executable
In addition to the above files, a package often has files that contains code that is specific to one declared type. This file uses the snake case form of the type name (for example
loggly_hook.gowould correspond to the type
LogglyHook). This file should contain method declarations, interface implementation assertions and any other declarations that are tied solely to that type.
Each non-test file can have a test counterpart like normal, whose name ends with
_test.go. The common files described above also have their own test counterparts... for example
internal_test.goshould contains tests that test unexported behavior and more commonly test helpers that are unexported.
Generally, file contents are sorted by exported/unexported, then declaration type (ordered as consts, vars, types, then funcs), then finally alphabetically.
Often, we provide test packages that aid in the creation of tests that interact with our other packages. For example, the
support/dbpackage has the
support/db/dbtestpackage underneath it that contains elements that make it easier to test code that accesses a SQL database. We've found that this pattern of having a separate test package maximizes flexibility and simplifies package dependencies.
Contributions are welcome! See CONTRIBUTING.md for more details.
See DEVELOPING.md for helpful instructions for getting started developing code in this repository.