carolynvs

#!/usr/bin/env bash

# Just source this file or copy/paste this function in your ~/.bashrc or ~/.bash_profile
function gof {
    if (( $# == 0 )); then
        echo "usage: $gof <dir>"
        echo "jumps to $GOPATH/src directory matching <dir>"
        return
    fi
    GOPATH=${GOPATH:-~/go}

carolynvs

• brew install git
• brew tap johanhaleby/kubetail && brew install kubetail or brew install --HEAD kubetail
• brew install findutils gives me gfind, which supports all the args
• brew install bash-completion gives me autocomplete for stuff like kubectl and minikube
• Upgrade Bash so that I have access to more commands, flags and to get bash completion working for kubectl

  brew install bash
  sudo bash -c 'echo /usr/local/bin/bash >> /etc/shells'
  chsh -s /usr/local/bin/bash
  

sdboyer

When the manifest file of my project/the root project, call it A, contains a dep/constraint statement for another project, say X, that doesn't appear in A's import statements, there are three modes in which tools can interpret that:

1. X must be present in the result (A's lock+vendor), and it must meet the version constraint.
   • (There's a variant where it works like this when it’s the root manifest giving the dep on X, but if it’s a non-root manifest, things work like 2)
2. X needn't be present in the result, and even if it is, it needn't meet the constraint. (Basically, the constraint is cruft and we ignore it)
3. X needn't necessarily be present in the result, but if it is (because some other dep actually does import X), then it must meet A's stated constraint.
   • (Again, there's a variant where it works like this for the root manifest, but like 2 for a non-root manifest.)

The first mode's biggest benefit is up-front intuitiveness for users. As we've discussed, it corresponds nicely to a get or add-