<commit_before><h2>Philosophy</h2>

<p>
	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>. This is clean and clear solution, but there are two problems with this approach.
</p>
<p>
	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 remove some API, they should use a different repository.
</p>
<p>
	Second, in practice many developers 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> and <a href="http://go.pkgdoc.org/-/index">GoPkgDoc</a> are dead). Yes, it's a social problem, but we still should deal with it.
</p>
<p>
	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 bundle third-party packages with their application and take pain of updating them only when needed. But what should package developers do if they want to use other packages?..
</p>
<p>
	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 and <a href="https://npmjs.org/">NPM</a> for Node.js should solve 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>). <a href="https://github.com/AlekSi/nut">Nut client tool</a> was designed to work along with Go conventions: nuts are installed into workspace specified by <code>GOPATH</code> environment variable, and imported as <code>"gonuts.io/test_nut1/0.0.1"</code>.
</p>
<p>
	So – let's <a href="https://github.com/AlekSi/nut/blob/develop/CONTRIBUTING.md">work together</a> for a better Go ecosystem!
</p><commit_msg>Mention Packagist.<commit_after><h2>Philosophy</h2>

<p>
	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>. This is clean and clear solution, but there are two problems with this approach.
</p>
<p>
	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 remove some API, they should use a different repository.
</p>
<p>
	Second, in practice many developers 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> and <a href="http://go.pkgdoc.org/-/index">GoPkgDoc</a> are dead). Yes, it's a social problem, but we still should deal with it.
</p>
<p>
	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 bundle third-party packages with their application and take pain of updating them only when needed. But what should package developers do if they want to use other packages?..
</p>
<p>
	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 should solve 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>). <a href="https://github.com/AlekSi/nut">Nut client tool</a> was designed to work along with Go conventions: nuts are installed into workspace specified by <code>GOPATH</code> environment variable, and imported as <code>"gonuts.io/test_nut1/0.0.1"</code>.
</p>
<p>
	So – let's <a href="https://github.com/AlekSi/nut/blob/develop/CONTRIBUTING.md">work together</a> for a better Go ecosystem!
</p>
{'fraction_non_alphanumeric': 0.12865388195866692, 'fraction_numerical': 0.002606590951405697, 'mean_word_length': 4.776344086021505, 'pattern_counts': {'":': 0, '<': 129, '<?xml version=': 0, '>': 129, 'https://': 5, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6258941', 'n_tokens_mistral': 1606, 'n_tokens_neox': 1526, 'n_words': 656}