SQLPL Go Ruby RPC Shell PLpgSQL Other
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
.vscode cleanup Jul 26, 2017
address fixed assert in main_test.go Nov 3, 2017
amount Update regexp Aug 13, 2018
build Add BumpSequence to "build" package Jul 31, 2018
clients Update docs for horizon client StreamPayments func Aug 16, 2018
crc16 Initial import from go-stellar-base Aug 4, 2016
docs/reference Add error handling to examples Jan 27, 2018
examples Add network passphrase to the transaction parameters Feb 8, 2018
exp Add examples and benchmarks Nov 8, 2017
handlers Fix federation.Handler tests Nov 16, 2017
hash Initial import from go-stellar-base Aug 4, 2016
keypair Go imports Nov 28, 2017
meta hanlde bumpseq effects Jul 30, 2018
network build: Remove default network setting Oct 3, 2016
price Update regexp Aug 13, 2018
protocols Add SDK version with full support to protocols/horizon Aug 14, 2018
services Fix typo in payments-for-account docs Aug 16, 2018
strkey build,xdr,strkey: add support for new signer types Jan 25, 2017
support replace LogglyHost with LogglyTag (#589) Aug 15, 2018
tools Switch to github.com/tyler-smith/go-bip39 from github.com/bartekn/go-… Jun 19, 2018
xdr Update XDR and result codes Aug 3, 2018
.dockerignore add simple dockerfile that builds all the monorepo tools Jan 8, 2018
.gitignore Add debug builds to .gitignore Apr 5, 2018
.travis.yml Use dep for dependency management (#571) Aug 6, 2018
CHANGELOG.md Update changelog Jan 25, 2017
CONTRIBUTING.md Adds some more supporting docs Aug 17, 2016
COPYING Add license notice, imported from stellar/archivist Aug 8, 2016
Dockerfile add simple dockerfile that builds all the monorepo tools Jan 8, 2018
Gemfile Upgade scc again, switch to https-based dependencies in Gemfile Feb 7, 2018
Gemfile.lock Update deps and scenarios Jul 30, 2018
Gopkg.lock Use dep for dependency management (#571) Aug 6, 2018
Gopkg.toml Add github.com/sirupsen/logrus to Gopkg.toml Aug 7, 2018
LICENSE-APACHE.txt Add license notice, imported from stellar/archivist Aug 8, 2016
README.md Update dependencies section Aug 9, 2018
Rakefile update xdr definitions (#397) Apr 6, 2018
doc.go Update README Aug 17, 2016
main_test.go Return errors in builder functions Jan 15, 2018

README.md

Stellar Go

Build Status GoDoc Go Report Card

This repo is the home for all of the public go code produced by SDF. In addition to various tools and services, this repository is the SDK from which you may develop your own applications that integrate with the stellar network.

Dependencies

This repository depends upon a number of external dependencies, and we use dep to manage them. Dep is used to populate the vendor directory, ensuring that builds are reproducible even as upstream dependencies are changed. Please see the dep website for installation instructions.

You can use dep yourself in your project and add stellar go as a vendor'd dependency, or you can just drop this repos as $GOPATH/src/github.com/stellar/go to import it the canonical way (you still need to run dep ensure -v).

When creating this project, we had to decide whether or not we committed our external dependencies to the repo. We decided that we would not, by default, do so. This lets us avoid the diff churn associated with updating dependencies while allowing an acceptable path to get reproducible builds. To do so, simply install dep and run dep ensure -v in your checkout of the code. We realize this is a judgement call; Please feel free to open an issue if you would like to make a case that we change this policy.

Directory Layout

In addition to the other top-level packages, there are a few special directories that contain specific types of packages:

  • clients contains packages that provide client packages to the various Stellar services.
  • exp contains experimental packages. Use at your own risk.
  • handlers contains packages that provide pluggable implementors of http.Handler that make it easier to incorporate portions of the Stellar protocol into your own http server.
  • support contains packages that are not intended for consumption outside of Stellar's other packages. Packages that provide common infrastructure for use in our services and tools should go here, such as db or log.
  • support/scripts contains single-file go programs and bash scripts used to support the development of this repo.
  • services contains packages that compile to applications that are long-running processes (such as API servers).
  • tools contains packages that compile to command line applications.

Each of these directories have their own README file that explain further the nature of their contents.

Other packages

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.

Package source layout

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: Every package should have a main.go file. This file contains the package documentation (unless a separate doc.go file is used), all of the exported vars, consts, types and funcs for the package.
  • internal.go: This file should contain unexported vars, consts, types, and funcs. Conceptually, it should be considered the private counterpart to the main.go file of a package
  • errors.go: This file should contains declarations (both types and vars) for errors that are used by the package.
  • example_test.go: This file should contains example tests, as described at https://blog.golang.org/examples.

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.go would correspond to the type LogglyHook). This file should contain method declarations, interface implementation assertions and any other declarations that are tied solely to 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.go should 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.

Test helpers

Often, we provide test packages that aid in the creation of tests that interact with our other packages. For example, the support/db package has the support/db/dbtest package 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.

Coding conventions

  • Always document exported package elements: vars, consts, funcs, types, etc.
  • Tests are better than no tests.