github.com/aleksi/gonuts.io@v0.0.0-20130622121132-3b0f2d1999fb/app/gonuts/templates/base/doc_philosophy.html (about)

     1  <h2>Philosophy</h2>
     2  
     3  <p>
     4  	Go comes with a <a href="http://golang.org/cmd/go/"><code>go</code> tool</a> – the standard way to fetch, build, and install Go packages and commands. It uses code repositories URLs like <a href="http://github.com/AlekSi/nut"><code>github.com/AlekSi/nut</code></a> for import paths. This is clean and clear solution, but there are two problems with this approach.
     5  </p>
     6  <p>
     7  	First, it doesn't support package versioning – <code>go get</code> always installs latest version. If someone wants to install previous one, he/she has to use <code>git</code>/<code>hg</code>/<code>svn</code>/<code>bzr</code> manually. Therefore, package authors are forced to maintain backward compatibility since first commit. If they want to change or remove some existing API, they should use a new import path. In practice, most authors don't really care about it. Change logs are also seldom.
     8  </p>
     9  <p>
    10  	Second, also in practice, many authors are moving their code to other places (for example, from Google Code to GitHub), renaming repositories (<code>web.go</code> become <code>web</code>) or just deleting them (at the time of this writing many links in <a href="http://godashboard.appspot.com/">Go Projects Dashboard</a> are dead). Yes, it's a social problem, but we still should deal with it.
    11  </p>
    12  <p>
    13  	So how can we solve those problems? Big companies typically have special repositories for third-party code. Once imported there, code is never deleted. And they have a budget to fix their world of dependencies. So, <code>go get</code> probably works okay for <code>google/...</code> packages. Smaller companies and individual developers are able to fork all third-party packages or bundle them with their application and take pain of updating them only when needed. But what should package authors do if they want to use other packages?..
    14  </p>
    15  <p>
    16  	Central repository for versioned packages, similar to <a href="http://pypi.python.org/pypi">PyPI</a> for Python, <a href="http://rubygems.org/">RubyGems.org</a> for Ruby, <a href="http://npmjs.org/">NPM</a> for Node.js and <a href="http://packagist.org/">Packagist</a> for PHP solves those problems. Published packages (called "nuts") are never deleted, and <a href="/-/doc/versioning">versioning schema</a> allows to install exact version, or version matching pattern (like <code>2.*.*</code>). Some <a href="/-/doc/spec">metadata</a> like package name and documentation is stored in Go package itself, the rest is in small file called <a href="/-/doc/spec"><code>nut.json</code></a>.
    17  </p>
    18  <p>
    19  	<a href="https://github.com/AlekSi/nut">Nut client tool</a> is similar to was designed to work along with Go conventions: nuts are installed into workspace specified by <code>GOPATH</code> environment variable, and imported as <a href="http://gonuts.io/aleksi/nut"><code>"gonuts.io/aleksi/nut"</code></a>.
    20  </p>
    21  <p>
    22  	So – let's <a href="https://github.com/AlekSi/nut/blob/develop/CONTRIBUTING.md">work together</a> for a better Go ecosystem!
    23  </p>