bash - variable - ubuntu gopath

Definición automática de GOPATH por proyecto.

Question

Para cada proyecto que creo, tengo que export GOPATH={path_to_project} cada vez que cd en el directorio del proyecto. Tiene que haber una manera más fácil. ¿No hay alguna manera de que pueda crear un archivo .bashrc o .bash_profile para un directorio determinado para definir el GOPATH para ese proyecto?

Por ejemplo, tengo dos proyectos, A y B. Si tengo un GOPATH singular que no se redefine cuando me muevo entre proyectos, los archivos binarios de ambos proyectos se almacenarán en el mismo lugar. Más importante aún, los binarios para bibliotecas de terceros se almacenarán en el mismo lugar, por lo que no tengo forma de mantener múltiples versiones de la misma biblioteca por proyecto.

Sin embargo, si puedo definir GOPATH por proyecto, todos los binarios y bibliotecas de terceros dependen de un proyecto. Esta parece ser la forma común de gestionar la gestión de paquetes en la mayoría de los entornos de otros lenguajes (ruby rbenv, python vertiualenv, etc.)

Answer 1

(P2 2018: Tenga en cuenta que con el proyecto vgo (ahora "módulo") , GOPATH podría terminar en desuso en favor de un flujo de trabajo basado en proyectos. Eso evitaría el GOPATH que estaba proponiendo a continuación, hace dos años)

Con Go 1.11 (agosto de 2018), GOPATH puede ser opcional, con módulos .

Herbert Fischer ( hgfischer ) tiene una idea similar expresada en Gestionar múltiples direcciones hgfischer para un entorno Linux / Unix ( hgfischer en la pregunta ya mencionada en los comentarios anteriores):

Simplemente incluya el siguiente fragmento de source ~/.bashrc en su ~/.bashrc (o ~/.bash_profile ) y vuelva a cargar su entorno de shell con la source ~/.bashrc .
Este fragmento creará una función de shell que anulará el comando incorporado cd con uno personalizado que escanea el directorio ingresado, y todos los demás anteriores, para un archivo llamado .gopath .

cd () {
builtin cd "$@"
cdir=$PWD
while [ "$cdir" != "/" ]; do
if [ -e "$cdir/.gopath" ]; then
export GOPATH=$cdir
break
fi
cdir=$(dirname "$cdir")
done
}

Ahora solo necesita crear un archivo .gopath en cada directorio que desee como su GOPATH y cada vez que ingrese a este directorio, la función de cd redefinida establecerá el GOPATH de su entorno actual en este directorio.

Actualización 2017: si no desea modificar su entorno, aún puede usar un GOPATH por proyecto, abriendo la carpeta src de ese proyecto en Visual Studio Code ( vscode , que es un IDE multiplataforma), combinado con el extensión " Go for Visual Studio Code ".

En ese IDE, puedes:

• mantenga su GOPATH único global en un entorno llamado go.toolsGopath .
• infiere tu GOPATH actual con una configuración llamada go.inferGopath

De esa manera, VSCode instalará una colección de herramientas en su GOPATH global (para que usted también lo use fuera de VSCode).
Consulte " Ir a las herramientas de las que depende la extensión Go ": godep , golint , guru , godoc , ...

Y, sin embargo, su GOPATH para su proyecto será la carpeta principal de src:

Eso funciona cuando compilas / instalas tu proyecto desde el IDE.
Si desea hacerlo desde la línea de comandos, la respuesta original anterior aún se aplicaría.

Answer 2

Me gustan las agallas de la respuesta de gopath () anterior , pero no me gusta (a) tener el GOPATH configurado solo para el comando go (lo uso en los plugins de vim, etc.), ni me gusta (b) tener que Recuerda escribir gopath lugar de go :)

Esto es lo que finalmente agregué a mi ~/.bash_profile :

export GOPATH="... a default path ..."
function cd() {
builtin cd $@ &&
export GOPATH="$(
( while [[ $PWD != / && $(basename $PWD) != go ]]; do
cd ..
done
if [[ $PWD == / ]]; then
echo $GOPATH
else
echo $PWD
fi
))"
}

(También escribí lo anterior con una pequeña discusión adicional sobre los requisitos en esta publicación del blog )

Answer 3

Mi impresión es que la herramienta go desalienta activamente el "mantenimiento de múltiples versiones de la misma biblioteca por proyecto" por la razón precisa en que la experiencia ha demostrado que esa estrategia no funciona en grandes bases de código (como la de Google). Ha habido mucha discusión acerca de la versión del paquete en golang-nuts: ( busque en la lista ), y parece que la discusión aún está abierta, como lo indicó Ian Lance Taylor en esta entrevista del 6 de junio de 2013 (busque la palabra "versionado").

El sistema go Packaging está diseñado para permitir que cada proyecto tenga su propia estructura de directorios; la única restricción es que todos deben ser hijos de (algunos) directorios en GOPATH . Esto tiene la ventaja de que interactúa bien con los sistemas de control de versiones, siempre y cuando el maestro VCS siempre compile. En la entrevista de blog mencionada anteriormente, ILT sugiere:

Lo que hacemos internamente es tomar una instantánea del código importado y actualizar esa instantánea de vez en cuando. De esa manera, nuestra base de código no se romperá inesperadamente si la API cambia.

Sustituir "mis otras bibliotecas" por "el código importado", parece una posibilidad; Podrías tener dos directorios, producción y desarrollo; para el desarrollo, podría poner el directorio de desarrollo primero en la ruta para que los binarios y las bibliotecas de desarrollo no contaminen los directorios de producción. No sé si eso es suficiente.

Si realmente desea tener un GOPATH separado para cada proyecto, sugeriría lo siguiente:

1) Haga que cada GOPATH del proyecto finalice en un directorio llamado go (o algo GOPATH )

2) GOPATH el GOPATH utilizando algo como la siguiente función de shell (casi totalmente sin probar):

gopath() {
GOPATH="$(
( while [[ $PWD != / && $(basename $PWD) != go ]]; do
cd ..
done
if [[ $PWD == / ]]; then
echo $GOPATH
else
echo $PWD
fi
))" go "$@"
}

Luego puede usar gopath lugar de go siempre que su directorio de trabajo actual se encuentre en algún lugar dentro del repositorio del proyecto. (Posibilidades más sofisticadas podrían incluir el uso de la ruta del proyecto provista explícitamente, si existe, para deducir GOPATH ).

Answer 4

No puedo comentar, pero para desarrollar la respuesta de @joshlf :::

alias go antes de GOPATH : mi método no requiere que trate / cree un archivo adicional:

alias go=''GOPATH=$(echo $(pwd)) go''

aclamaciones

Answer 5

Puedes usar una herramienta como autoenv para configurar un script que se ejecuta automáticamente cuando cd en un directorio en particular.

Para sus propósitos, un ejemplo de archivo /happy/go/path/yay/.env podría ser:

export GOPATH="/happy/go/path/yay"
export PATH="$GOPATH/bin:$PATH"

Answer 6

Sé que esto no es muy inteligente, pero me parece que si simplemente voy al directorio base del proyecto de Go donde tengo las carpetas src, pkg y bin, simplemente puedo escribir:

'' exportar GOPATH = $ (pwd) ''

y eso es todo bien!

Answer 7

Soy un Golang newb, pero la mejor forma de hacerlo sería crear un script de shell en cada uno de sus proyectos, crear / ejecutar su proyecto y colocar este script en la raíz de su proyecto :)

#!/usr/bin/env bash
// get absolute path to the directory which contains this script
PROJECT_DIR=$(cd $(dirname $0) && pwd)
// set GOPATH as you wish, then run go build
GOPATH=${GOPATH}:${PROJECT_DIR} && cd ${PROJECT_DIR} && go build

Este script debería funcionar, incluso si lo ejecuta desde un directorio que no es la raíz del proyecto.

Answer 8

Yo escribiría un script que pueda inferir el GOPATH apropiado del directorio actual, y luego alias el comando go para llamar primero a este script. Por ejemplo, una implementación muy simple:

#!/bin/bash
# infer-gopath.sh
pwd

Y luego, en .bash_aliases (o donde sea que mantengas tus alias):

alias go=''GOPATH=$(infer-gopath.sh) go''

Esto establece GOPATH en cualquier salida infer-gopath.sh solo para la invocación del comando go , por lo que no tendrá ningún efecto duradero en tu shell.