# Go Package Management For 2014

DevFeed: [Go Package Management For 2014](<https://devfeed.tech/articles/go-package-management-for-2014-22093.md>)

Original publisher: [Read original article](<https://www.ardanlabs.com/blog/2014/01/go-package-management-for-2014.html>)

Published: 2014-01-16T00:00:00Z

Content type: opinion

Language: en

Sources: [William Kennedy](<https://devfeed.tech/sources/william-kennedy.md>)

Topics: [Go Language](<https://devfeed.tech/topics/go-language.md>), [Package Management](<https://devfeed.tech/topics/package-management.md>), [Package manager](<https://devfeed.tech/topics/package-manager.md>)

Tags: [ardan-labs](<https://devfeed.tech/tags/ardan-labs.md>), [blog](<https://devfeed.tech/tags/blog.md>), [build-tools](<https://devfeed.tech/tags/build-tools.md>), [compatibility](<https://devfeed.tech/tags/compatibility.md>), [developers](<https://devfeed.tech/tags/developers.md>), [go](<https://devfeed.tech/tags/go.md>), [go-programming](<https://devfeed.tech/tags/go-programming.md>), [golang](<https://devfeed.tech/tags/golang.md>), [package-management](<https://devfeed.tech/tags/package-management.md>), [programming](<https://devfeed.tech/tags/programming.md>), [versioning](<https://devfeed.tech/tags/versioning.md>), [workflows](<https://devfeed.tech/tags/workflows.md>)

## AI overview

The article reviews progress toward package management for Go, including community coordination, a goals document, tool classification, user stories, test packages, and bug fixes. It argues that multiple tools may be needed and outlines compatibility, versioning, and portability guidelines for tool developers.

## Source excerpt

Introduction In October 2013 I sent out a call to action to the Go community. I wanted to form a group of Gophers that would come together and help write a specification and build a working implementation of a package management tool. We are not there yet, but the group did accomplish a few things: We started a mailing list called Go package management [go-pm] where people could discuss ideas and get feedback on existing and new tools. We wrote a goals document that outlined what we wanted to accomplish along with guidelines and help for package management tool authors. We identified and categorized the existing set of tools that are available for use. We developed a set of user stories that describe the different scenarios people were facing. We started a list of packages that tool developers can use to test their tools against. We helped some of the tool developers find and fix bugs. Overall I think the last 3 months have been productive and I am pleased with the results. Building Tools I have come to appreciate that there isn't going to be a silver bullet or a one tool fits all solution. I believe a majority of the use-cases that have been defined in the goals document can be solved and building tools to handle these use-cases is worth the time and effort. If you're thinking about building a tool, please consider these guidelines which are outlined in the goals document: Work with the Go language as defined in the Go 1 spec of March 28, 2012. Don't implement solutions that require feature changes or build tools that change the way Go works. Provide backwards compatibility with go get and the convention of using VCS repositories in the import paths. The existing set of programs, build processes and workflows can't break. You must respect the existing environments and allow them to continue to function. Prevent version skewing. Don't build into the solution the potential for version skewing to occur. Such as requiring semantic versioning in the import path urls. Im