<commit_before># Go Skeleton Project

This is a skeleton of a [Go](http://golang.org/) project which sets up
a Go workspace and places the project into that workspace. It comes
with a Makefile to make life easier for you, but it sets up a "go
remote" compatible project (and you should keep this compatibility!).
The Makefile exists to set up a Go workspace and to make life easier
for common cases of using that workspace (such as building the project
in the workspace).

The idea behind this skeleton is to NOT require anything aside from Go
to be set up, and that the skeleton will make a "Go Workspace" for
you, for your project. When you build the project it will create a
workspace, symlink the project into the right place in the workspace,
and fetch dependencies into the workspace for you (via <code>go
get</code>).

The workspace will be in the <code>WORKSPACE</code> directory of the
checkout. This is probably controversial within the Go community, but
it makes life much easier in my opinion. It is set up this way so that
projects using thisg skeleton remain compatible with <code>go
remote</code> expectations, but not require setting up any global
GOPATH or workspace, or having to deal with checking things out to the
right place in your workspace. Automation, such as make, is supposed
to solve this for us, so let us let it do that.

# Don't Panic

## I don't know Go, I just want to build this project!

If you just want to build this project, not develop it, run make:

    $ make
    
Output will be in the <code>WORKSPACE/bin</code> directory.

## I *am* a Go programmer, Makefiles are the devil!

It's okat, the Makefile just automates workspace setup, and common
tasks (like building the primary output of the project). You don't
need to use it.

## Some Useful Targets

* <code>make</code> The default target is "build", which will build
  your project.
* <code>make clean</code> Will remove all compiled stuff from the
  workspace, specifically WORKSPACE/pkg and WORKSPACE/bin
* <code>make clean-workspace</code> Will complrtely wipe out the
  WORKSPACE.

There are also <code>workspace</code> and <code>deps</code> targets,
which set up the basic workspace, and run <code>go get</code>
respectively.

## "Normal" Go Development

The canonical way of working with your project would be to export your
GOPATH and then cd down to the code you are working on, and work on it
there. This works fine. If you want to avoid using make for typical
build and test, this is a good thing. If you don't want to cd down and
muck about, you can just work in the project checkout *outside* the
GOPATH. Folks in #go-nuts will think you are weird, but it's okay.
You'll want to make sure to use <code>make</code> to build things
though, so it can keep the GOPATH sane for you.

If you run the <code>activate.sh</code> bash script, it will start a
child bash process designed to work in your WORKSPACE:

    $ ./activate.sh
    
This will export the correct GOPATH, will prefix PATH with
WORKSPACE/bin, will export a <code>$project</code> environment
variable which is the path to the current project in the GOPATH, a
<code>$root</code> environment variable pointing at the checkout root,
and a <code>WORKING_ON</code> environment variable with the package
name currently being worked on (useful for inclusion in PS1).

Additionally, if there is a <code>.bash\_local</code> file in the
project directory, it will source that after everything else is set
up. Personally, my <code>.bash\_local</code> prepends $WORKING_ON to
my PS1, and cd's into the project within the GOPATH:

    export PS1="[$WORKING_ON] $PS1"
    cd $project
    
So that I know what workspace I am in.

# Customizing the Skeleton

Folks using this skeleton will almost certainlyneed to customize it.
Beyond making it fancier, the two things to look out for:

## The PACKAGE Makefile Variable 

The first customization will be to make sure the PACKAGE variable is
sane, right now the Makefile assumes it is at the root of a git repo,
and does some munging to guess. If it guesses correctly for you, rock
on. If it guesses incorrectly for you, just set the PACKAGE variable
to the right thing.

## The build Makefile Target

Running

    $ make
    
by itself will run the <code>build</code> target. As exactly what you
want to build will vary by project, you will probably need to
customize this target to build the right thing. Right now it builds a
binary called <code>hello</code>. You'll never guess what it does!
<commit_msg>speling<commit_after># Go Skeleton Project

This is a skeleton of a [Go](http://golang.org/) project which sets up
a Go workspace and places the project into that workspace. It comes
with a Makefile to make life easier for you, but it sets up a "go
remote" compatible project (and you should keep this compatibility!).
The Makefile exists to set up a Go workspace and to make life easier
for common cases of using that workspace (such as building the project
in the workspace).

The idea behind this skeleton is to NOT require anything aside from Go
to be set up, and that the skeleton will make a "Go Workspace" for
you, for your project. When you build the project it will create a
workspace, symlink the project into the right place in the workspace,
and fetch dependencies into the workspace for you (via <code>go
get</code>).

The workspace will be in the <code>WORKSPACE</code> directory of the
checkout. This is probably controversial within the Go community, but
it makes life much easier in my opinion. It is set up this way so that
projects using thisg skeleton remain compatible with <code>go
remote</code> expectations, but not require setting up any global
GOPATH or workspace, or having to deal with checking things out to the
right place in your workspace. Automation, such as make, is supposed
to solve this for us, so let us let it do that.

# Don't Panic

## I don't know Go, I just want to build this project!

If you just want to build this project, not develop it, run make:

    $ make
    
Output will be in the <code>WORKSPACE/bin</code> directory.

## I *am* a Go programmer, Makefiles are the devil!

It's okay, the Makefile just automates workspace setup, and common
tasks (like building the primary output of the project). You don't
need to use it.

## Some Useful Targets

* <code>make</code> The default target is "build", which will build
  your project.
* <code>make clean</code> Will remove all compiled stuff from the
  workspace, specifically WORKSPACE/pkg and WORKSPACE/bin
* <code>make clean-workspace</code> Will complrtely wipe out the
  WORKSPACE.

There are also <code>workspace</code> and <code>deps</code> targets,
which set up the basic workspace, and run <code>go get</code>
respectively.

## "Normal" Go Development

The canonical way of working with your project would be to export your
GOPATH and then cd down to the code you are working on, and work on it
there. This works fine. If you want to avoid using make for typical
build and test, this is a good thing. If you don't want to cd down and
muck about, you can just work in the project checkout *outside* the
GOPATH. Folks in #go-nuts will think you are weird, but it's okay.
You'll want to make sure to use <code>make</code> to build things
though, so it can keep the GOPATH sane for you.

If you run the <code>activate.sh</code> bash script, it will start a
child bash process designed to work in your WORKSPACE:

    $ ./activate.sh
    
This will export the correct GOPATH, will prefix PATH with
WORKSPACE/bin, will export a <code>$project</code> environment
variable which is the path to the current project in the GOPATH, a
<code>$root</code> environment variable pointing at the checkout root,
and a <code>WORKING_ON</code> environment variable with the package
name currently being worked on (useful for inclusion in PS1).

Additionally, if there is a <code>.bash\_local</code> file in the
project directory, it will source that after everything else is set
up. Personally, my <code>.bash\_local</code> prepends $WORKING_ON to
my PS1, and cd's into the project within the GOPATH:

    export PS1="[$WORKING_ON] $PS1"
    cd $project
    
So that I know what workspace I am in.

# Customizing the Skeleton

Folks using this skeleton will almost certainlyneed to customize it.
Beyond making it fancier, the two things to look out for:

## The PACKAGE Makefile Variable 

The first customization will be to make sure the PACKAGE variable is
sane, right now the Makefile assumes it is at the root of a git repo,
and does some munging to guess. If it guesses correctly for you, rock
on. If it guesses incorrectly for you, just set the PACKAGE variable
to the right thing.

## The build Makefile Target

Running

    $ make
    
by itself will run the <code>build</code> target. As exactly what you
want to build will vary by project, you will probably need to
customize this target to build the right thing. Right now it builds a
binary called <code>hello</code>. You'll never guess what it does!

{'fraction_non_alphanumeric': 0.05881047492232579, 'fraction_numerical': 0.000887705281846427, 'mean_word_length': 4.147344374643061, 'pattern_counts': {'":': 0, '<': 79, '<?xml version=': 0, '>': 79, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6730605', 'n_tokens_mistral': 2501, 'n_tokens_neox': 2404, 'n_words': 1442}