Barebones dependency manager for Go.

Johnny Deps Build Status

Johnny Deps is a small tool from VividCortex that provides minimalistic dependency versioning for Go repositories using Git. Its primary purpose is to help create reproducible builds when many import paths in various repositories are required to build an application. It's based on a Perl script that provides subcommands for retrieving or building a project, or updating a dependencies file (called Godeps), listing first-level imports for a project.

Getting started

Install Johnny Deps by cloning the project's Github repository and running the provided scripts, like this:

git clone https://github.com/VividCortex/johnny-deps.git
cd johnny-deps
./configure --prefix=/your/path
make install

The --prefix option to configure is not mandatory; it defaults to /usr/local if not provided (but you'd have to install as root in that case). The binary will end up at the bin subdirectory, under the prefix you choose; make sure you have that location specified in your PATH.

Note that Perl is required, although that's probably provided by your system already. Also Go, Git and (if you're using makefiles) Make.

Dependencies

Johnny Deps is all about project dependencies. Each project should have a file called Godeps at its root, listing the full set of first-level dependencies; i.e., all repositories with Go packages imported directly by this project. The file may be omitted when empty and looks like this:

github.com/VividCortex/godaemon 2fdf3f9fa715a998e834f09e07a8070d9046bcfd
github.com/VividCortex/log 1ffbbe58b5cf1bcfd7a80059dd339764cc1e3bff
github.com/VividCortex/mysql f82b14f1073afd7cb41fc8eb52673d78f481922e

The first column identifies the dependency. The second is the commit identifier for the exact revision the current project depends upon. You can use any identifier Git would accept to checkout, including abbreviated commits, tags and branches. Note, however, that the use of branches is discouraged, cause it leads to non-reproducible builds as the tip of the branch moves forward.

Introducing the tool

jd is Johnny Deps' main binary. It's a command line tool to retrieve projects from Github, check dependencies, reposition local working copies according to each project's settings, building and updating. It accepts subcommands much like go or git do:

jd [global-options] [command] [options] [project]

Global options apply to all commands. Some allow you to change the external tools that are used (go, git and make) in case you don't have them in your path, or otherwise want to use a different version. There's also a -v option to increase verbosity, that you can provide twice for extra effect. (Note that the tool runs silently by default, only displaying errors, if any.)

It's worth noting that all parameters are optional. If you don't specify a command, it will default to build (see "Building" below). If you don't specify a project, jd will try to infer the project based on your current working path, and your setting for GOPATH. If you're in a subdirectory of any of the GOPATH components, and you're also in a Git working tree, jd would be happy to fill up the project for you.

When in doubt, check jd help.

Retrieving projects

Retrieving a Go application with Johnny Deps is just as easy as retrieving a single base project. Run jd get and the full application, with all transitive dependencies, will be set up in your environment. Here's what we'd type for one of our applications:

jd get github.com/VividCortex/api-hosts

Johnny Deps will look for all required projects in your GOPATH, and download those missing to the first component of GOPATH. It will even create the directory stated in your GOPATH if it doesn't yet exist. As jd traverses the graph of dependencies, it checks whether version conflicts exist. If it happens to detect one, it will abort with a message like this:

Version mismatch detected for github.com/VividCortex/core
  561c9e9798307b875b8f90b89b7888eae4a983ce referenced by:
    github.com/VividCortex/api-hosts
    github.com/VividCortex/config
    github.com/VividCortex/nap
  but dfe3ff5362d778214272b56e2afcca0d96651911 referenced by github.com/VividCortex/shard

Here, the tool is telling you that two different versions of core are being included. The first is the commit identifier at the top, that is shared as a dependency for the three projects that follow. But shard, on the other hand, is including a different commit for core, shown at the last line. If no version mismatch is found, you'll end up with all projects required to build the application you were interested in (api-hosts in the example above).

Besides retrieving required projects, jd get will reposition local copies (whether they existed already or were just cloned) to the version stated in Godeps files. Furthermore, if you're aiming at a specific commit (as recommended), jd does an extra effort trying to checkout a branch whose tip matches that commit, as opposed to leaving you in a detached HEAD state. That's most probably what you want, cause it's probably a work in progress and you'll be adding commits to that branch. (If you prefer a detached HEAD instead, provide the -d flag to get.)

When choosing a branch to checkout for a given commit identifier, jd will first search among all locals. If there's none whose tip matches the commit, jd will try remote tracking branches instead. Among those matching, jd selects one with a local branch by the same name, having the remote as an upstream branch. If there's one available, that remote branch is merged into the local, and the latter is checked out for use. Otherwise, jd keeps one of the matching remotes with no local branch by the same name, and checks out a new local branch with that remote set as upstream. (If local branches existed for all candidate remotes, but none of them had the remote by the same name set as upstream, then jd would abort with an appropriate message. In that case you should either review your local branches, cause there's possibly an upstream setting missing, or otherwise use -d to checkout in detached HEAD mode.) In any case, if there's more than one choice and you're running with double -v, you'd get a message displaying the other options as well.

It's worth noting that jd favors local operations as much as possible, to avoid long round-trips to remote repositories. Hence, remotes won't be fetched if the required revision is found locally. (That's particularly relevant when including a branch name at the Godeps file cause, if found locally, the branch will not be updated with remote changes.) Note also that, unless it actually needs to move to a different release, jd will not insist in that your working copy is clean. This is good from a developer's point of view, cause it allows you to play with the application, trying modifications or fixes in the whole code base, without jd complaining.

If the project you're interested in is not present in GOPATH, jd get will clone it from the remote repository and checkout the master branch. But once you have a local copy, jd will never checkout a different revision. (It will change revisions for dependencies, but not for the main project you provide to jd get.) You may reposition the working copy to your liking using Git commands; jd will be happy to adjust dependencies accordingly. However, if you want to force your main project into a specific revision, even before you have a local copy, you can use the -r parameter to jd get, like so:

jd get github.com/VividCortex/api-hosts -r my-release

where the argument to -r can be anything you can checkout from Git: a commit identifier (abbreviated or not), a branch or a tag.

After working copies for all projects in the application are set, jd get runs a check on first level dependencies for the main project (i.e., the one either you specified on the command line, or jd inferred from your current directory). The check is run against the result of go list. jd will complain if the sets don't match exactly, displaying both missing and not required projects. If that's the case, you need to fix your Godeps file (see "Updating" below).

Building

Since building is what you'll be doing most of the time, jd conveniently defaults to build if no command is provided. Furthermore, jd may be able to retrieve the project out of your current working directory (see "Introducing the tool" above). Hence, you'd typically be able to compile by typing only jd at the command prompt. Not even your location within the project tree matters; the tool works equally fine if run from deep inside the hierarchy.

Before the actual building process, jd runs the equivalent of a jd get command. That's how it makes sure that you're actually using the correct versions of all dependencies. (Keep in mind, though, that if your local copies were already set to the correct revisions, it's okay to have local changes; even in Godeps files.) The implicit get run by build, and the choice of build as the default command, make the tool particularly easy to use to build projects you don't even have. The following command retrieves the full dependencies for the application and builds:

jd github.com/VividCortex/api-hosts

Furthermore, since the -r option to build is actually passed along to the implicit get, you can readily set up a specific version by appending the appropriate -r to the command above. (The same behavior goes to the -d option to build.)

Johnny Deps calls go build at the project's root to build. But, in order to accommodate special needs, jd checks for custom instructions first, resorting to go build only if there are none. The highest priority goes to the Make utility. If there's a file called Makefile or makefile at the project root, then make is run. If an executable file called build is found, then that will be invoked instead. Otherwise the tool resorts to go build ./....

There's no need for a script if you need to go install ./... instead. Johnny Deps will use the later if you ask it to install rather than build. However, keep in mind that this has to be explicitly asked for; jd defaults to build if no command is provided. The rest of the process works exactly like it does for build, including the attempts at make and the build script. Even though jd makes no difference between build and install when custom scripts are used, the command name is made available in case different actions are required in scripts themselves. This is published as the JD_ACTION environment variable.

Updating dependencies

Johnny Deps can't decide which releases to use from the project's you import. But it can help writing the Godeps file. By running jd update, jd will disregard the current dependencies in the Godeps file, overwriting it with the latest master release for each project you depend upon, after pulling. Of course, that may or may not work. Using the latest release for each dependency could potentially lead to inconsistencies (version mismatches), that would make jd complain. The dependencies file would have been changed anyway. It's your responsibility to decide which projects to upgrade or withhold.

It's worth noting that jd update does not rely on the Godeps file to check current dependencies; it takes them from go list instead. A nice consequence is that new imports are automatically detected from the code and added to Godeps with no manual intervention required. (And no longer needed imports will be removed as well.) Note also that, although the old dependencies file is overwritten, the new copy is not committed or even staged for commit in Git. (Rationale: you should test that everything still works properly!) You can do that with the rest of your changes, without leaving traces in history if you run the update multiple times before you're done.

Return codes

These are the return codes for jd:

  • 0 - Success
  • 1 - Error with parameters
  • 2 - Bad dependencies or unable to read them
  • 3 - Version mismatch detected
  • 4 - External command failed
  • 5 - Unable to checkout requested revision

Workflows

Johnny Deps is intentionally agnostic about the specific workflow used. In practice, people seem to fall into one of two camps that reflect how they think about dependency management, and their differing goals.

The first category, roughly speaking, is those who would like to build from the tip of their source control repositories all the time, but have a need for pinning some things to a specific version. Those users may use branch names in Godeps as opposed to commit identifiers, and change to a specific commit when they need to pin a version. (Nevertheless, jd will not automatically fetch the latest changes. See "Retrieving projects".)

The second school of thought holds that the Godeps file should contain external dependencies and their exact versions, so that checking out a particular revision of an application's repository and running jd will result in exactly the same versions of all of the code used to build the application, every time.

At VividCortex, we want to be able to reproduce a binary for debugging or other purposes. All of our builds have a command-line flag called --build-version that, when present, will result in the binary printing out the Git revision from which it was built. We can thus easily reproduce any version by calling jd build with that revision as the -r parameter. To embed the revision in the binary, we use a specific shell script called build (see "Building" above) that runs something like:

go build -ldflags "-X main.Godeps '$(git rev-parse HEAD)'"

At the application we set things up so that --build-version displays the contents of the main.Godeps variable set by the compiler.

Contributing

We welcome issue reports, suggestions, and especially pull requests:

  1. Fork the project
  2. Write your code in a feature branch
  3. Add tests (if applicable)
  4. Run tests (always!)
  5. Commit, push and send Pull Request

Because this is a VividCortex internal tool that we're sharing publicly, we may not want to implement some features or fixes.

TODO

Add tests. Those we previously had are not appropriate for the new tool.

Optionally add support for other repositories, like Mercurial. This tool is now targeted at Git on github.com, that is what we use at VividCortex.

License

Copyright (c) 2013 VividCortex. Released under the MIT License. Read the LICENSE file for details.

Contributors

Johnny Deps is the combination of several different thought processes from multiple authors, with inspiration from tools such as Ruby's Bundler and dep gem, Python's pip, and others. Give credit to @xaprb and @gkristic.

Johnny Deps

Comments
  • Add a Godeps helper

    Add a Godeps helper

    We have an internal tool that determines the dependencies and versions of all non-core imported packages a binary uses, and builds a Godeps file with them. I'd like to integrate this with Johnny Deps so that we can centralize it and keep it here instead of in internal build scripts.

  • Package install runs parallel

    Package install runs parallel

    Since we have bash on our side we can speed up the package installation.

    And yes... it's because of this https://github.com/bundler/bundler/pull/2481 :bowtie:

  • Pain-points using jd

    Pain-points using jd

    Preface: These are my own impressions and part of the reason I'm having difficult may be because I'm using jd incorrectly. In that case maybe this will help others who are making the same mistakes.

    • The best way to do a godeps upgrade is to start with the updates near the root and move towards the leaves.
    • The problem comes when, even though you've started at the root, you only find out in the leaves that there is an inconsistency in a repo that you didn't think was important. In this case you have to upgrade that repo and the start from there and move toward the leaves again.
      • Example: ordered my repos in this order {apple,banana,coconut,durian,eggplant,fig}. I upgraded from left to right. It was only when I hit eggplant that I found a difference in tomato, which I hadn't even considered. I updated banana to the correct tomato, change the banana Godeps line in all repos, and started again from there. (Note that I couldn't just do jd update because I'm trying to pin to certain versions and I know of no way to do that).
    • There also confusion if you are trying to upgrade "this" repo and you don't know if the inconsistency you have is because the "other" repo is pointing to the wrong thing or if "this" repo is pointing to the wrong "other" repo. For example:
            $cd this_repo
            $jd build
            Version mismatch detected for github.com/VividCortex/something_repo
              aaaaaf3fef071fb53cd7b7de2e9d503111ee5f97 referenced by:
                github.com/VividCortex/this_repo
              but fffff69f06306d9f7e534a1579652c736f637e56 referenced by github.com/VividCortex/other_repo
    
    • Is this because other_repo is pointing to fffff of something_repo? Or
    • Is this because this_repo is pointing to an incorrect version of other_repo which is pointing to fffff. (If this_repo was pointing to the correct version of other_repo, then this message wouldn't be displayed.)
    • Perhaps neither of these is correct. Is it actually because this_repo is pointing to the wrong version of something_repo? I can't know without looking up repo hashes. Perhaps if a repo is pointing to the HEAD of a branch we can make it say so. (Though I bet that's hard.)
      • Circular dependencies aren't detected. It might be because in the circular dependency I found (banana and coconut) coconut actually depended upon coconut/milk.
      • It would be nice to have a third column in Godeps so that you could specify "pin" there and then still use jd update to update everything except for pinned repos. My attempt to specify branch names didn't seem to work well with jenkins for some reason.
  • Use go get to install sub-dependencies by default

    Use go get to install sub-dependencies by default

    Look at #55

    The problem which must be solved:

    Dependencies, from a referenced package in Godeps which are not using jd to manage theirs. Here is a "simple" implementation to be able to install anything with jd, however it's probably not the most clever.

  • receive my h̶a̶t̶e̶ love!

    receive my h̶a̶t̶e̶ love!

    few additional comments:

    • you have a bash shebang in /configure and a sh shebang in /bin/johnny-deps it would be better to use the same in both I think and adjust both script for either of those
      • you don't really need make for this, as long as the script is executable and reachable from $PATH it'll work but I guess you know that already :)
    • be aware of the difference between ${1-"Godeps"} and ${1:-"Godeps"} (I wasn't)
    • I'm assuming $GOPATH is a scalar variable, if it's a list (like any other PATH variable) you won't be able to use it in cd like you're now when there's more than a single element
    • POSIX specifies that a POSIX-compatible shell should exist at /bin/sh (not necessarily a Bourne sh) but I suppose you use /usr/bin/env for the variables
  • Batch file version for Windows.

    Batch file version for Windows.

    This Pull Request adds a batch file for use on Windows platforms.

    If I were you I'd be skeptical of this: I don't write a ton of batch scripts, so this could have some lurking problems. However, it seems to work fine on my machine.

    I also haven't provided any installation solution. We can't rely on makefiles because most WIndows boxes won't ship with make. I could write an installation batch script if you think that's useful, but it might be easier just to ask Windows people to copy the script to the right place.

  • removed repetitions in reading from file and comments redone in unixy style

    removed repetitions in reading from file and comments redone in unixy style

    this is the stuff we've been chatting about @pote - removed double reading from file, simplified comments with actual support for comments at any place.

  • Build errors aren't captured and passed back up through jd.

    Build errors aren't captured and passed back up through jd.

    Hey there!

    Just wanted to say I already find jd way simpler and more straight-forward than other Go dependency managers. I've just found one teensy weensy little nitpick: build errors don't get pushed back up the stack and aren't shown to the user.

    For example, if i build a project that has a build error, I get no error output until I run the build by hand:

    ec2-user:code/houston/houston(master✗) jd -v -v
    Setting up github.com/tobz/houston
      depends on github.com/streadway/amqp at bbc42d384b424cc08732fb935c742fa4fa9e361b
    Setting up github.com/streadway/amqp
      no dependencies found
    Building
      running go build
    
    ec2-user:code/houston/houston(master✗) go build -v
    github.com/streadway/amqp
    github.com/tobz/houston
    github.com/tobz/houston/houston
    # github.com/tobz/houston/houston
    /home/ec2-user/code/go/src/github.com/tobz/houston/houston/main.go:6: imported and not used: "strings"
    /home/ec2-user/code/go/src/github.com/tobz/houston/houston/main.go:40: not enough arguments in call to houston.NewConsumer
    
  • Uninitialized value in eq

    Uninitialized value in eq

    I'm getting errors like this in some cases:

    $ jd build
    Use of uninitialized value in string eq at /usr/local/bin/jd line 548.
    

    The source:

        548 elsif ($gopath[0] eq $ENV{"GOROOT"}) {
        549         show(ERROR, 0, "Refusing to run with GOROOT included in GOPATH; don't do that");
        550         show(ERROR, 0, "With appropriate permissions, you may mess your Go installation");
        551         exit(1);
        552 }
    
  • Missing dependencies are said useless

    Missing dependencies are said useless

    Hello, I've a project with the following packages in my godeps

    github.com/Appsdeck/etcd-discovery
    github.com/Appsdeck/gopassword
    github.com/codegangsta/martini-contrib
    github.com/codegangsta/martini
    

    In this case I obtain

    ../../codegangsta/martini/martini.go:26:2: cannot find package "github.com/codegangsta/inject" in any of:
        /usr/local/go/src/pkg/github.com/codegangsta/inject (from $GOROOT)
        /opt/go/src/github.com/codegangsta/inject (from $GOPATH)
    ../etcd-discovery/service/error.go:4:2: cannot find package "github.com/coreos/go-etcd/etcd" in any of:
        /usr/local/go/src/pkg/github.com/coreos/go-etcd/etcd (from $GOROOT)
        /opt/go/src/github.com/coreos/go-etcd/etcd (from $GOPATH)
    

    Ok, no problem, I add theses packages

    github.com/Appsdeck/coreos/go-etcd
    github.com/codegangsta/inject
    github.com/Appsdeck/etcd-discovery
    github.com/Appsdeck/gopassword
    github.com/codegangsta/martini-contrib
    github.com/codegangsta/martini
    

    Now everything is correctly built, but I get

    Not-required package(s) in Godeps:
      github.com/codegangsta/inject
      github.com/coreos/go-etcd
    

    At the end of the process, resulting with a non-zero return code (2)

  • Improve the Bash!

    Improve the Bash!

    I have some suggestions for improvement.

    Here's the current script:

    #!/usr/bin/env bash
    
    set -e
    
    ## The Godeps file is expected to have lines like so:
    #
    # github.com/VividCortex/robustly v2.6
    #
    ## where the first element is the import path and the second is a tag
    ## in the project.
    
    while read dependency; do
      x=( $dependency )
      package=${x[0]}
      version=${x[1]}
      go get -a -u -v $package/...
      echo "Setting Go Package: $package to version $version"
      cd $GOPATH/src/$package && git checkout $version && echo "Done"
    done < Godeps
    

    Here are my suggestions:

    1. Let it look for Godeps in the current or parent directories, or in $HOME. This is pretty typical behavior for tools like this in my experience. A pretty simple loop with dirname can do it.
    2. Quote all the things. Basically everywhere a variable is used, it should be quoted unless you want it to be interpreted as WORDs. Otherwise, you'll get broken behavior in cases such as: the cwd includes a space or special character (- is a fun one); the variable contains spaces or special characters; the variable isn't as expected for some reason.
    3. Include a copyright statement in the header of the file.
    4. Use /bin/sh instead of bash.
    5. while read dependency can be while read package version, and then $x is obsolete.
    6. Check $package and $version for existence, and give nice error messages about the current line, if they are empty.
  • Consider adding GO15VENDOREXPERIMENT support

    Consider adding GO15VENDOREXPERIMENT support

    In 1.5 the go command will read the environment variable GO15VENDOREXPERIMENT. If enabled, it will use the local "/vendor/" folder for dependencies. This replaces the need to manage GOPATH variables as dependencies can be fetched directly into the vendor folder and resolved there when built. This allows the GOPATH to not be modified. The contents of the vendor folder can be ignored.

    Will you consider supporting this approach?

  • report all conflicts rather than just the first

    report all conflicts rather than just the first

    If a conflict is present, then jd reports only the first it finds. Because of this my workflow is something like this:

    $ jd update A
    conflict in B
    $ cd B; jd update B; git commit -a -m "dep update";git push; cd A
    $ jd update A
    conflict in C
    $ cd C; jd update C; git commit -a -m "dep update";git push; cd A
    $ jd update A
    conflict in D
    $ cd D; jd update D; git commit -a -m "dep update";git push; cd A
    $ jd update A
    conflict in E
    ...
    

    Would it be possible/easy to show all conflicts so I can fix them all at once?

  • non-git support

    non-git support

    Given that it's listed several places that this is for "git" management, this may be one of those rejected ideas, but I thought I would mention it.

    Do you have workflow ideas for non-git hosted stuff? In particular, Gustavo Niemeyer seems particularly fond of bzr on launchpad, which makes his libraries unusable with johnny-deps without creating a git mirror or something (although they work fine with go get).

A simple dependency manager for Go (golang), inspired by Bundler.
A simple dependency manager for Go (golang), inspired by Bundler.

Goop A dependency manager for Go (golang), inspired by Bundler. It is different from other dependency managers in that it does not force you to mess w

Sep 27, 2022
Go Package Manager (gopm) is a package manager and build tool for Go.

?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? In favor of Go Modules Proxy since Go 1.11, this pr

Dec 14, 2022
Go dependency management tool experiment (deprecated)
Go dependency management tool experiment (deprecated)

Dep dep is a dependency management tool for Go. It requires Go 1.9 or newer to compile. NOTE: Dep was an official experiment to implement a package ma

Dec 23, 2022
dependency tool for go

Godep - Archived Please use dep or another tool instead. The rest of this readme is preserved for those that may still need its contents. godep helps

Dec 14, 2022
Spaghetti: a dependency analysis tool for Go packages
Spaghetti: a dependency analysis tool for Go packages

Spaghetti is an interactive web-based tool to help you understand the dependencies of a Go program, and to explore and evaluate various possible efforts to eliminate dependencies.

Dec 15, 2022
Go Dependency Analysis toolkit

Goda is a Go dependency analysis toolkit. It contains tools to figure out what your program is using.

Jan 2, 2023
Go Manager - bundle for go

gom - Go Manager Why The go get command is useful. But we want to fix the problem where package versions are different from the latest update. Are you

Nov 20, 2022
Golang Version Manager

g 注意:master分支可能处于开发之中并非稳定版本,请通过tag下载稳定版本的源代码,或通过release下载已编译的二进制可执行文件。 g是一个Linux、macOS、Windows下的命令行工具,可以提供一个便捷的多版本go环境的管理和切换。 特性 支持列出可供安装的go版本号 支持列出已安

Dec 30, 2022
🦄 Easy, fast and open-source local package manager for Python!

Unikorn ?? Easy, fast and open-source local package manager for Python! Key Features Speed: You can add a package in one second.

Dec 11, 2021
gPac - a linux package manager

gPac is a useless package manager. It is included in the gSuite, which is a suite of tools written in GO. gPac is a KISS - like package manager.

Mar 13, 2022
GoFish is a cross-platform systems package manager, bringing the ease of use of Homebrew to Linux and Windows.

GoFish is a cross-platform systems package manager, bringing the ease of use of Homebrew to Linux and Windows.

Dec 11, 2022
Package manager for future projects

PCKGER is a package manager for my next project but when it will be able to build binaries and move libs it will be used like a normal package manager

Dec 20, 2021
gobin is a package manager for /go/bin

gobin gobin is a package manager for /go/bin Features List installed packages. Check for updates. Install packages (like go install). Uninstall packag

Nov 12, 2022
📦 An independent package manager for compiled binaries.
📦 An independent package manager for compiled binaries.

stew An independent package manager for compiled binaries. Features Easily distribute binaries across teams and private repositories. Get the latest r

Dec 13, 2022
Barebones dependency manager for Go.
Barebones dependency manager for Go.

Johnny Deps Johnny Deps is a small tool from VividCortex that provides minimalistic dependency versioning for Go repositories using Git. Its primary p

Sep 27, 2022
Barebones Go program to issue DDNS updates to Amazon Route 53 service.

Route53 DDNS Very simple DDNS using AWS Route 53 #/bin/bash # AWS_ACCESS_KEY_ID example (fake) export AWS_ACCESS_KEY_ID=KkRbWpoyqLHo69dvoskn # AWS_

May 17, 2021
A barebones URL Shortener implementation in Go using Gin and MySQL. Also features a basic frontend.

URL Shortener in Go This is a barebones URL Shortener implementation in Go using the Gin web framework and MySQL. Also features a basic frontend. Loca

Dec 22, 2021
🏥 Barebones, detailed health check library for Go

go-health ?? Barebones, detailed health check library for Go go-health does away with the kitchen sink mentality of other health check libraries. You

Oct 19, 2021
A barebones Go app, which can easily be deployed to Heroku

go-getting-started A barebones Go app, which can easily be deployed to Heroku. This application supports the Getting Started with Go on Heroku article

Nov 29, 2021
A simple dependency manager for Go (golang), inspired by Bundler.
A simple dependency manager for Go (golang), inspired by Bundler.

Goop A dependency manager for Go (golang), inspired by Bundler. It is different from other dependency managers in that it does not force you to mess w

Sep 27, 2022