Go: cmd / go: assume GOPATH = $ HOME / go se não estiver definido

/ cc @adg @broady @campoy @ianlancetaylor @griesemer @robpike @rsc

Eu gosto, mas temos alguma preferência específica por "gocode" e não algo como "gopata"?

Quantas pessoas já usam GOPATH = $ HOME / gocode? Parece-me que não são muitos. Isso sugere que é o padrão errado.

"gocode" terá um mecanismo de pesquisa e outras confusões com a popular ferramenta github.com/nsf/gocode.

Temos alguma informação sobre o que a maioria das pessoas faz?

Eu mesmo uso GOPATH = $ HOME / gopath.

Perfeito aqui se você usa atualmente GOPATH = $ HOME

Perfeito aqui se você atualmente usa GOPATH = $ HOME / gopath

Perfeito aqui se você usa atualmente GOPATH = $ HOME / gocode

Devo fazer uma enquete no Twitter em @golang?

@campoy , parece bom. Provavelmente melhor do que convidar todos para esse bug.

Que tal $ HOME / go (que é o que eu uso).

Veja também: http://go-talks.appspot.com/github.com/freeformz/talks/20160712_gophercon/talk.slide#7

$ HOME: 8,9%
$ HOME / go: 50,6%
Outros: 40,5%

Eu realmente gostaria de ter dividido mais opções para este.

Votação iniciada: https://twitter.com/golang/status/781189567437164544

Na quarta-feira, 28 de setembro de 2016, 10:51 Edward Muller [email protected]
escreveu:

Que tal $ HOME / go (que é o que eu uso).

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -250244110 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ACIkDJ83L5fXByqw-NEQ11JxKPGv_iQkks5quqkXgaJpZM4KI0I2
.

Consulte também a coluna I aqui: https://docs.google.com/spreadsheets/d/1peTY_lq8rRW2zsKjwhd8iwiFZP5AZSrCvbCc07mPOWA/edit#gid = 1525640201

@freeformz ,

$ HOME / go está em conflito com o código-fonte do caminho go (go.googlesource.com/go) é frequentemente verificado. É ruim que a comunidade tenha abençoado este local como um padrão para GOPATH :( Eu me preocupo se alguém esquecer de definir seu GOPATH e executar a ferramenta go, isso bagunçará seu diretório de desenvolvimento atual.

@rakyll para cada um deles, só queria indicar o que eu e muitos outros usamos. go.googlesource.com/go é verificado em /usr/local/go.git em meu sistema.

Quantas pessoas já usam GOPATH = $ HOME / gocode? Parece-me que não são muitos. Isso sugere que é o padrão errado.

Para registro, uso GOPATH=$HOME , mas achei que isso seria muito controverso e prejudicaria o objetivo desta proposta, que é melhorar a experiência do novo usuário.

@freeformz , acho que não precisamos nos preocupar com os caminhos canônicos existentes que estão fora de $ HOME. O padrão para GOPATH vai estar em $ HOME em algum lugar e o requisito mínimo deve ser que ele não entre em conflito com nenhum caminho crítico existente.

$ HOME / gocode parece estranho para mim, mas pode ser uma escolha muito boa.

A questão é que importa menos qual seja o padrão, apenas que haja um.

Não importa qual seja o padrão, porque defini-lo basicamente tornará o trabalho de todos os novos em Go daqui a alguns anos.

O comando go faz de tudo para não ficar confuso quando GOPATH = $ GOROOT explicitamente; Tenho certeza de que a mesma lógica pode ser aplicada a uma configuração implícita também. Portanto, não estou muito preocupado em destruir $ HOME / go acidentalmente.

Ainda me pergunto se, em vez de um padrão fixo, deveríamos farejar automaticamente os pais do diretório atual para descobrir onde está GOPATH. Isso é o que muitas ferramentas de código-fonte fazem atualmente (por exemplo, todo sistema de controle de versão), então é um conceito que as pessoas entenderiam. E não os força a usar um nome de diretório ou ter apenas um espaço de trabalho GOPATH. Mas podemos muito bem ter essa discussão sobre a questão original.

@rsc Eu adoraria que o padrão fosse GOPATH=$HOME porque isso significa que $GOPATH/bin estará em seu caminho (pelo menos na maioria das distribuições de Linux, não tenho certeza sobre darwin).

$GOPATH=$HOME/go também é uma boa escolha e aqueles que têm o código-fonte do compilador verificado lá já configuraram GOPATH=something else então não há chance de conflito.

Para ser claro, eu não estava tentando ser irreverente quando disse

A questão é que importa menos qual seja o padrão, apenas que haja um.

Em vez disso, tentar enfatizar o objetivo desta proposta é fazer com que a ferramenta go use um valor padrão de $GOPATH quando não for fornecido, pois isso é uma fonte contínua de confusão e frustração para tantos novatos no idioma.

Estou 👎 na detecção automática porque falha em um caso de uso importante, que é:

1. Eu instalei o Go, na verdade não li os documentos de instalação do Go, apenas segui o que dizia no README do repositório que dizia brew install go
2. Corri go get github.com/thething/theproject
3. Agora recebo um erro sobre não definir $ GOPATH. O que é aquilo? Eu só queria executar este programa sobre o qual alguém tuitou!

Um valor padrão de GOPATH=$HOME/go SGTM, assumindo que decidimos por um padrão e não por uma abordagem de auto-farejamento.

O comando go faz de tudo para não ficar confuso quando GOPATH = $ GOROOT explicitamente; Tenho certeza de que a mesma lógica pode ser aplicada a uma configuração implícita também.

Parece bom.

não tenho certeza sobre darwin

Não em Darwin.

Se for para iniciantes, eu desaconselho GOPATH=$HOME pois isso criaria três diretórios em seu diretório inicial em vez de apenas um. Não gosto muito de softwares que poluem meu diretório doméstico além do necessário.

@mvdan Eu entendo e sua reação foi porque eu não GOPATH=$HOME .

Se _I_ pessoalmente quiser definir meu GOPATH como $HOME , essa opção permanecerá disponível para mim e eu não teria que fazer nenhuma alteração caso esta proposta fosse aceita para Go 1.8.

@davecheney

padrão para um valor de GOPATH = $ HOME / gocode

Não há variável HOME padrão no Windows. O que você propõe fazer no Windows?

Adoraria que o padrão fosse GOPATH = $ HOME porque isso significa que $ GOPATH / bin estará em seu caminho

Estou sempre preocupado em ter $ GOPATH / bin em meu PATH. go get instala programas de outras pessoas lá. Queremos mesmo que um novo usuário Go instale programas aleatórios da Internet em algum lugar em seu PATH?

Alex

Não sou um usuário experiente do Windows, mas presumo que haja alguma noção de um caminho básico onde os documentos e as configurações são armazenados. Para o propósito desta discussão, suponha que estou falando sobre esse caminho no contexto dos usuários do Windows.

Se esse caminho não existir, assuma C: / gocode.

Em relação ao meu comentário sobre GOPATH = $ HOME, embora esta seja e continue a ser minha preferência pessoal, reconheço que esta é uma opção controversa para um valor padrão e, como tal, não o sugeri como o valor proposto.

A detecção automática é perigosa. Comecei a fazer o protótipo disso um tempo atrás, mas acrescentou uma complexidade significativa tanto para a ferramenta go quanto para a experiência do usuário.

Não estou por dentro do que está acontecendo com o grupo de trabalho de gerenciamento de pacotes, mas posso imaginar um futuro não muito distante em que GOPATH seja totalmente eliminado.

Dito isso, mesmo que GOPATH desapareça em algum momento no futuro próximo, ainda pode haver valor em definir um padrão. Se acharmos que GOPATH provavelmente desaparecerá, não importa muito como o definimos.

Pelo que li acima, há algum consenso de que:

1. Por padrão, GOPATH=$HOME é muito invasivo.
2. O padrão deve incluir a string go algum lugar (provavelmente como um prefixo).

Não estou preocupado com o fato de GOPATH ser um clone do go repo principal (ou seja, GOPATH == GOROOT). Pessoas que verificam o repositório go provavelmente têm um conjunto GOPATH. A ferramenta go detectaria o conflito de qualquer maneira, como faz hoje.

Com isso em mente, o default mais sucinto seria $HOME/go , o que eu acho bastante razoável.

Presumo que haja alguma noção de um caminho básico onde os documentos e as configurações são armazenados.

Eu não sei de tal coisa. Talvez outros usuários do Windows comentem aqui.

Se esse caminho não existir, assuma C: / gocode.

Em vez disso, você deseja C: gocode.
Colocar coisas na raiz de C: \ não parece certo para mim. Você recomendaria que GOPATH fosse definido como / gocode no Linux?
Mas, dado que o instalador do Windows já instala Go em C: go, C: gocode para GOPATH é pelo menos consistente.

Alex

Mas, dado que o instalador do Windows já instala Go em C: go, C: gocode para GOPATH é pelo menos consistente.

GOPATH não deve ser fornecido para cada usuário? Para ser igual ao UNIX, %USERPROFILE%\gocode , eu acho.

Enquete Go + em https://goo.gl/xAsgEj

depois de usar por muito tempo algo como $ HOME / go-programs, troquei GOPATH para $ HOME. então, agora eu tenho a seguinte estrutura:

$ HOME / bin
$ HOME / pkg
$ HOME / src /
$ HOME / src / github.com / user / some_github_project
$ HOME / src / some_project

esta estrutura é mais genérica e também pode ser usada para usar com outras linguagens ou projetos e com o github. por exemplo, eu tenho $ HOME / src / talks (leia home / sources / talks para arquivos markdown) ou outros projetos em alguns idiomas (como $ HOME / src / github.com / user / html) mas também sources e eu tenho um lugar para fontes de muitos projetos com ou sem correspondência do github.

bin ou pkg pode ser considerado bagunçado, mas eu acho que não é tão chato. é mais confuso ter muitas pastas de origem para pessoas que usam vários idiomas.

então, do meu ponto de vista, o melhor lugar do GOPATH é $ HOME.

Estou usando $ HOME / gocode como meu GOPATH.
Sou contra $ HOME / go, pois às vezes você não tem privilégios de root e precisa instalar o Go em seu diretório inicial. Nesse caso, acho que $ HOME / go seria o melhor para GOROOT.
Portanto, devemos usar algo diferente de $ HOME / go como GOPATH.

@hnakamur Quando instalei o Go manualmente (agora usando Ubuntu Make), coloquei-o em $ HOME / bin / go - $ {go_version} (com um link simbólico de $ HOME / bin / vá para $ HOME / bin / go- $ {version} / bin / go, então não tive que editar meu $ PATH)

@tbroyer É um nicho. Eu acho que a maioria dos usuários não quer configurações ou ajustes extras. Na minha opinião, ~ / bin é usado para colocar scripts próprios ou binários (como eu). E eu acho que ~ / bin (~ / src, ~ / pkg) torna difícil remover os binários go.

Eu uso $ HOME para meu GOPATH.
Por que configurar GOPATH automaticamente, por que não alertar com boas informações sobre como configurá-lo se GOPATH não existir?

Por que configurar GOPATH automaticamente, por que não alertar com boas informações sobre como configurá-lo se GOPATH não existir?

O problema não é que as pessoas não saibam como definir uma variável de ambiente (na maioria das vezes), é que, mesmo se você fizer isso, será uma sensação ruim ter que passar por vários obstáculos para começar a usar Go. Ser capaz de usar o Go out of the box com padrões sãos assim que instalado torna a experiência o mais perfeita possível e significa que mais pessoas provavelmente tentarão o Go depois de baixá-lo, em vez de se deparar com um obstáculo, perdendo o ímpeto e decidir que não vale a pena mexer.

Tendo a concordar com Chris e Andrew: se houver um GOPATH padrão, deve ser apenas $ HOME / go, não gopath ou gocode. _A maioria dos usuários não tem uma distribuição Go verificada (e todos que têm hoje já configuram o GOPATH, então isso não vai incomodá-los). O padrão precisa fazer sentido para novos usuários, não para usuários avançados, e para a maioria dos usuários $ HOME / go faz muito sentido.

Jaana levantou uma preocupação sobre o comando go ficar confuso se $ HOME / go for uma distribuição Go, mas o comando go já verifica se há GOPATH = $ GOROOT acidental. É fácil verificar se isso é verdade quando GOPATH também está definido implicitamente. Na verdade, também seria fácil aumentar a verificação para procurar, digamos, $ HOME / go / src / cmd / go / alldocs.go, para evitar confusão mesmo quando GOROOT! = $ HOME / go, mas $ HOME / go sim contém uma distribuição Go.

$ HOME / go não é uma boa opção para GOPATH. vamos fazer um simples exercício de comportamento ... novos usuários podem facilmente considerar o padrão como uma prática recomendada. Digamos que eu seja um novo usuário, por que devo considerar os padrões uma coisa ruim? mais do que isso, o método mais fácil (e o melhor?) para instalar o golang é descompactar em $ HOME porque com este método o compilador está sempre na última versão e não precisa de direitos de root, então você pode supor facilmente que muitos usuários terão o compilador em $ HOME / go. por que devo mover o compilador em / usr / local quando simplesmente não o fiz?
mais do que isso, eles podem fazer projetos e podem clonar projetos nesta pasta. então, eles terão uma pasta bagunçada e, com um pouco de descuido, poderão excluir facilmente a pasta do projeto com uma nova reinstalação golang.
além disso, os usuários do Windows têm c: go por padrão.

Eu gosto de $ HOME / gopath. Diz o que é.
O primeiro resultado no Google para "gopata" é a página certa.

Se um padrão for adotado, uma função func GOPATH() string poderia ser adicionada a runtime ? No momento, pode-se usar os.Getenv() , mas com um padrão não será tão simples.

@btracey , GOPATH é uma lista, não um único valor. Use filepath.SplitList . Além disso, GOPATH não é uma função do tempo de execução. Diz respeito apenas a cmd/go .

Para compatibilidade com versões anteriores, provavelmente precisaríamos definir GOPATH no processo '
ambiente se nenhum estiver definido.

Em 30 de setembro de 2016 às 08:10, Brendan Tracey [email protected]
escreveu:

Se um padrão for adotado, uma função de string func GOPATH () poderia ser adicionada
para o tempo de execução? No momento, pode-se usar os.Getenv (), mas com um padrão
não será tão simples.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -250605418 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AIDilc6cjWl0r3-V-6FWruHIiYA_X4nJks5qvDc5gaJpZM4KI0I2
.

Você está certo @bradfitz. A solução proposta por @adg atenderia a todos os meus usos.

Esta é uma ruga interessante. Eu posso ver isso falhando atualmente, quando não
GOPATH é definido, mas também quando GOPATH contém vários valores, e então
há o caso em que o aplicativo é construído em uma máquina e implantado em
outro.

Eu não quero descartar esse uso de GOPATH, eu entendo a dor de
ser capaz de localizar arquivos de suporte para seu aplicativo, mas eu gostaria
para entender o quão difundido é esse uso, e como o atual
implementações lidam com os problemas que destaquei acima.

Na sexta-feira, 30 de setembro de 2016, 08:35 Brendan Tracey [email protected] escreveu:

Você está certo @bradfitz https://github.com/bradfitz. A solução
proposto por @adg https://github.com/adg atenderia a todos os meus usos.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -250611813 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAAcA_e53SwZ7Zf_rWCcbZTyPEmXXhUTks5qvD1JgaJpZM4KI0I2
.

Meu uso não é o normal. Eu faço pesquisas científicas e descobri que é muito eficaz não ter apenas gopath/src e gopath/bin , mas também gopath/data e gopath/results . Isso torna mais fácil copiar os arquivos de origem para um novo sistema sem ter que copiar os (gigabytes de) arquivos de resultado. O novo sistema (digamos um cluster) gera novos arquivos de resultados e posso copiar esses resultados para um local central. É realmente fácil dizer gopath = os.Getenv("GOPATH") e salvar um arquivo em algo como filepath.Join(gopath, "results", "projectname", result.json) .

Obrigada. Para ser claro, não quis dizer que seu uso estava incorreto ou
errado, eu só queria entender esse uso do GOPATH em relação ao
restrições que destaquei.

Na sexta-feira, 30 de setembro de 2016, 09:09, Brendan Tracey [email protected] escreveu:

Meu uso não é o normal. Eu faço pesquisas científicas e descobri
é muito eficaz não apenas ter gopath / src e gopath / bin, mas também
gopath / data e gopath / results. Isso torna mais fácil copiar o código-fonte
arquivos para um novo sistema sem também ter que copiar os (gigabytes de)
arquivos de resultado. O novo sistema (digamos um cluster) gera novos arquivos de resultados,
e posso copiar esses resultados para um local central. É realmente fácil de
em seguida, diga gopath = os.Getenv ("GOPATH") e salve um arquivo em algo como filepath.Join (gopath,
"resultados", "nome do projeto", resultado.json).

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -250617618 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAAcA_CKox90AQMMAxOs9wEL2ffY0S0zks5qvEUPgaJpZM4KI0I2
.

Perfeito aqui se você usa atualmente GOPATH=$HOME/.go

@davecheney sem ofensa, apenas queria fornecer contexto suficiente para ser útil.

Vamos deixar o uso do GOPATH para encontrar arquivos de suporte fora desta discussão.

(GOPATH foi criado para ser uma configuração de tempo de compilação, não de tempo de execução. Eu sei que as pessoas confundem isso às vezes e usam GOPATH para encontrar arquivos associados em tempo de execução, mas não acho que devemos encorajar isso ou fazer é mais fácil de fazer. Precisamos de uma história melhor para os arquivos de suporte em geral, mas isso deve ser um problema separado.)

Relacionado à localização de arquivos associados em tempo de execução: # 12773

Desculpe poluir a discussão mais uma vez @rsc , mas @ randall77 , # 12773 é mais difícil de usar do que resolver esse problema diretamente. O código específico que precisa de um arquivo (ou para salvar um arquivo) pode se mover muito, e eu quero um lugar fixo para as entradas / saídas viverem independentemente (e separadas da) refatoração.

Este problema é sobre um possível valor padrão de GOPATH. _Não_ é sobre usos alternativos de GOPATH.

Se os usuários-alvo para esta mudança forem apenas aqueles que apenas desejam
instalar um novo programa escrito em Go, e não aqueles que realmente querem
escreva Go, então que tal fazermos ir e clonar em um diretório por usuário em
$ TMPDIR e deixe o binário em $ PWD se $ GOPATH não estiver definido? (Obviamente
isso só faz sentido para go get import.path / for / a / command, se não for um
comando go get deve falhar sem $ GOPATH ser definido)

Para quem está de fora, isso faz muito sentido, assim como wget um arquivo.

Uma vez que o usuário deseja começar a escrever o código Go, ele deve aprender como definir
GOPATH corretamente.

Sou contra $ HOME / go, pois às vezes você não tem privilégios de root e precisa instalar o Go em seu diretório inicial. Nesse caso, acho que $ HOME / go seria o melhor para GOROOT.

Se você estiver em um sistema Linux, eu diria que o melhor lugar para $ GOROOT pode ser $ HOME / .local / opt / go, não $ HOME / go, dependendo de como você interpreta o propósito de $ HOME / .local , já que apenas $ HOME / .local / share (aparecendo em mirror / usr / local / share) é definido nas especificações do diretório Base XDG: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest. html.

Também se pode argumentar que o melhor padrão para GOPATH / GOBIN (no Linux) deve ser:
GOPATH = $ XDG_DATA_HOME / go, ou $ HOME / .local / share / go
GOBIN = $ HOME / .local / bin

No entanto, isso provavelmente não é o mais fácil de entender para novos usuários? E também não deixaria claro qual é a melhor abordagem no Windows. $ HOME / go e $ USERPROFILE / go parecem pragmáticos.

Por favor, _por favor_ não vamos deixar este tópico se transformar em uma discussão sobre nomes de caminhos e locais de armazenamento canônicos do Linux. Não é produtivo, e acho que essa discussão já se afastou muito da postagem original de Dave Cheney.

Também não tenho certeza se a localização absoluta real importa muito, acho que toda essa discussão realmente precisa decidir é "queremos um Gopata padrão?" (soa como um sim mais ou menos opressor) e "deve ser compartilhado em todo o sistema ou local para o usuário" (até agora, a maior parte da discussão tem sido sobre local). Depois disso, quem quer que implemente pode escolher $HOME/gocode ou $HOME/go ou /usr/share/go/ ou o que quiser que pareça razoável para quem analisa o PR, e as coisas provavelmente continuarão muito bem.

Acho que um GOPATH em todo o sistema não é inicial devido a problemas de permissões.

O caminho amplo do sistema é, para melhor ou para pior, GOROOT, que distribui
como o debian estão usando para instalar pacotes para "todo o sistema", para melhor ou para
pior.

Um GOPATH de todo o sistema está fora do escopo desta proposta, esta proposta
recomenda um caminho derivado do valor do usuário conectado.

Na terça, 4 de outubro de 2016, 08:52, Andrew Gerrand [email protected] escreveu:

Acho que um GOPATH em todo o sistema não é inicial devido a problemas de permissões.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -251238251 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAAcA2kwyq0Iuidk0ygsGzqVKGLkKBR9ks5qwXkDgaJpZM4KI0I2
.

Por favor, não vamos deixar este tópico se transformar em uma discussão sobre nomes de caminhos e locais de armazenamento canônicos do Linux. Não é produtivo

Tudo bem, não vamos. Meu ponto principal foi realmente apontar outro motivo pelo qual $ HOME / go provavelmente não é problemático como um padrão GOPATH, já que provavelmente não é o caminho mais "idiomático do Linux" para instalações de usuários locais de Go (também conhecido como GOROOT).

Além disso, creio que foi discutido antes de usar XDG_CACHE_HOME para um GOPATH padrão, que foi o motivo pelo qual mencionei XDG_DATA_HOME - embora eu não saiba a qual função os autores do documento vinculado servem, ou quão "oficial" ela é .

$ HOME / trabalho .......

@adg @quentinmit @rsc quais são as próximas etapas para esta proposta?

Adoraria ver algo acontecer aqui. é um ponto problemático frequente nas minhas aulas. Qualquer padrão (mesmo $ home / go do qual eu discordo :)) é melhor do que nenhum.

$ HOME / vai ser. Não há uma única resposta melhor, mas esta é curta e agradável, e só pode ser um problema escolher esse nome se $ HOME / go já existir, o que só agradará os especialistas que já instalaram o go e entenderão o GOPATH.

Quem quer fazer o trabalho?

Eu definitivamente ficaria feliz em trabalhar nisso.

@campoy , você pode fazer isso <= nesta sexta-feira?

Eu diria que sim @bradfitz . Não parece uma grande quantidade de código a ser feito.
Eu posso começar amanhã.

update: Eu dei uma olhada rápida nisso e já escrevi alguns códigos, irei adicionar alguns testes e enviar uma mudança mais tarde hoje

Isso é ótimo pessoal! 👍

@robpike você também considerou minha proposta alternativa em # 17271? Eu gostaria de entender por que esta proposta foi considerada melhor

Não será uma boa ideia ter nomes de diretório de instalação Go e diretório de espaço de trabalho iguais, ou seja, go porque:

1) É muito fácil para um usuário ingênuo corromper / poluir o espaço de trabalho se o usuário fizer tar -xzf go$VERSION.$OS-$ARCH.tar.gz no diretório inicial

2) A experiência padrão de um novo usuário ao não instalar em /usr/local (não deseja instalar como root) não será tranquila, pois este será o fluxo:
Faça o download em $ VERSION. $ OS- $ ARCH.tar.gz
tar -xzf go$VERSION.$OS-$ARCH.tar.gz -> instalações em $ HOME / go
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
go get something -> lança cannot download, $GOPATH must not be set to $GOROOT. For more details see: go help gopath

@krishnasrinivas é meu entendimento que se GOROOT=$HOME/go , este padrão não ocorrerá ou causará go erro, uma vez que GOROOT e GOPATH não podem ser iguais. Nesses casos, como dito antes, espera-se que o usuário seja capaz de definir seus próprios GOPATH .

@mvdan correto, para novos usuários que não querem usar privilégios de root para instalação (e, portanto, alta chance de instalar Go em ~ / go), não estamos tornando mais fácil colocar as coisas em funcionamento, pois eles terão que fazê-lo explicitamente defina GOPATH para outra coisa. Isso pode ser facilmente corrigido se o GOPATH padrão for ~ / gopath ou ~ / gocode

Para instalação não-root, se novos usuários tiverem que aproveitar as vantagens do padrão GOPATH = ~ / go, a documentação de instalação deve ser um pouco mais complicada, pedindo explicitamente aos usuários que usem a opção tar -C para não instalá-la em ~/go

@rasky considero # 17271 e esta proposta como ortogonais. A resolução desta proposta é uma vitória fácil que não nos empurra em nenhuma direção particular. Vou elaborar mais sobre essa questão.

Eu concordo com @krishnasrinivas. Eu não tinha permissões de root, então descompactei Go to $ HOME / go. Eu também configurei meu $ GOPATH = $ HOME / gowork.

@krishnasrinivas @joegrasse Não existe uma solução perfeita. É fácil definir GOPATH sozinho, e espero que seja isso o que a maioria das pessoas fará. A questão aqui é o que devemos fazer pelas pessoas que são os mais novos a ir. Em geral, não são pessoas que estão instalando sua própria distribuição Go em locais personalizados. Pessoas que conseguem descobrir como instalar o Go em um local personalizado podem descobrir como definir GOPATH .

Pense em uma classe de novos programadores que estão usando distribuições Go pré-instaladas. Queremos que eles sejam capazes de começar a escrever código Go. Não queremos que a primeira etapa seja "isso é o que é uma variável de ambiente. É assim que você define uma. Agora defina GOPATH para isso." Essas etapas não têm nada a ver com Go como tal.

Novamente, não existe uma solução perfeita, mas parece sensato escolher algo.

@ianlancetaylor Concordo totalmente que algo deve ser escolhido. Só acredito que ir descompactar para ./go, padronizando para $ HOME / go, pode não ser a melhor escolha.

@ianlancetaylor GOPATH = $ HOME / gopath é um padrão melhor do que GOPATH = $ HOME / go devido aos motivos mencionados acima.

Não acho que o nome atual seja um problema - se você sabe como definir PATH para um local go / bin personalizado em seu homedir, você sabe como definir GOPATH.

@joegrasse @krishnasrinivas Dê uma olhada em " Instalando em um local customizado ".

Se você estiver descompactando para qualquer lugar diferente de /usr/local/go - por razões de permissões ou outros - torna-se necessário definir o GOROOT também, ou compilar a partir do código-fonte.

Enquanto for esse o caso, não há benefício em usar $ HOME / gopath, etc. em relação ao $ HOME / go proposto.

Você assume que os novos usuários preferem instalar a partir do tar.gz. Posso citar não
números, mas acredito que sua resposta é baseada em instalações Linux, que
são o terceiro destino de instalação mais popular para go.

Na terça, 25 de outubro de 2016, 20:28 Krishna Srinivas [email protected]
escreveu:

@mvdan https://github.com/mvdan correto, para usuários que não querem
usar privilégios de root para instalação (e, portanto, alta chance de instalar
Go in ~ / go) não estamos tornando mais fácil colocar as coisas em funcionamento, pois
eles terão que definir explicitamente GOPATH para outra coisa. Isso pode ser
facilmente corrigido se GOPATH for ~ / gopath ou ~ / gocode

Para instalação não raiz, se os novos usuários tiverem que tirar vantagem do padrão
GOPATH = ~ / go então a documentação deve ser um pouco mais complicada
pedindo explicitamente aos usuários que usem a opção tar -C para não instalá-la em
~ / go

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -255984498 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAAcAxqiBgwlXv4fk8CPk0gsd5h81yYmks5q3cvBgaJpZM4KI0I2
.

Todos os documentos precisam ser atualizados também. Essa é provavelmente a maior parte do trabalho.

Em 25 de outubro de 2016 às 10:14, Francesc Campoy [email protected]
escreveu:

Eu diria que sim. Não parece uma grande quantidade de código a ser feito.
Eu posso começar amanhã.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -255892314 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AIDilZGt_8O1bMsOu5Q-m1_tGDjxKQLkks5q3TvfgaJpZM4KI0I2
.

Eu diria que sim. Não parece uma grande quantidade de código a ser feito.
Eu posso começar amanhã.

Na segunda-feira, 24 de outubro de 2016 às 16h05 Brad Fitzpatrick [email protected]
escreveu:

@campoy https://github.com/campoy , você pode fazer isso antes <= nesta sexta-feira?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -255890668 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ACIkDKayusiOZWeOn6LrA49tlUsujwthks5q3TmqgaJpZM4KI0I2
.

Posso ajudar com os documentos, se necessário. O único problema é que o material atual depende exclusivamente do GOPATH como ponto de referência. Por exemplo,

"Ou, como você adicionou $GOPATH/bin ao seu PATH , basta digitar o nome binário:"

ou

"Criar pacote em GOPATH, mkdir -p $ GOPATH / src / github.com / user / hello"

Sem se envolver com o GOPATH e aprender o que ele é, é quase impossível fazer qualquer coisa no Go além de obter pacotes de terceiros. Se pudermos relatar o caminho padrão por meio de go env , seria fácil consultá-lo nos documentos.

Talvez $ HOME / go / ... pudesse ser substituído (ou o equivalente no Windows)?

Como você adicionou $HOME/go/bin ao seu PATH (ou $GOPATH/bin se GOPATH estiver definido) ...

Talvez em algum ponto a documentação possa esperar que os indivíduos não apenas definam a variável de ambiente PATH, mas também definam GOPATH como $ HOME / go. Mesmo sendo redundante, ele prepara o usuário para referências posteriores ao GOPATH.

A documentação inicial pode assumir o padrão e não mencionar as variáveis ​​de ambiente.

Você assume que os novos usuários preferem instalar a partir do tar.gz. Posso citar não
números, mas acredito que sua resposta é baseada em instalações Linux, que
são o terceiro destino de instalação mais popular para go.

Você está certo, minha opinião é tendenciosa para instalações Linux. Eu posso ver que para novos usuários que instalam go em / usr / local, ~ / go pode ser um nome de diretório mais reconhecível do que ~ / gopath

A documentação inicial pode assumir o padrão e não mencionar
variáveis ​​de ambiente em tudo?

Sim, espero que todo o debate perturbador sobre a configuração do GOPATH possa ser movido
a um apêndice da documentação de instalação, como fazemos para GOROOT
Atualmente.

Na quarta-feira, 26 de outubro de 2016, 06:01 Nathan Youngman [email protected] escreveu:

Talvez $ HOME / go / ... possa ser substituído (ou o equivalente em
Janelas)?

Como você adicionou $ HOME / go / bin ao seu PATH (ou $ GOPATH / bin se GOPATH for
definir)...

Talvez em algum ponto a documentação possa esperar que os indivíduos não
defina apenas a variável de ambiente PATH, mas também defina GOPATH como $ HOME / go.
Embora redundante, torna a documentação posterior clara.

A documentação inicial pode assumir o padrão e não mencionar o ambiente
variáveis ​​em tudo?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -256142424 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

A documentação inicial pode assumir o padrão e não mencionar as variáveis ​​de ambiente.

SGTM

Existem dois tipos de usuários Go:

• Usuários que simplesmente obtêm pacotes existentes
• Usuários que são desenvolvedores Go

O GOPATH padrão está corrigindo o caso do primeiro grupo. Ainda podemos manter as instruções relacionadas ao GOPATH para os documentos voltados para desenvolvedores. A instalação não deveria mais mencionar a configuração de GOPATH ou podemos ter um apêndice como @davecheney menciona.

Como alguém que teve que renomear ~ / bin / go por causa do Go, eu gosto de sugerir que qualquer que seja o padrão, se ele já existir, ele deve ter um .dotfile nele para indicar que é realmente Go's ~ / go. Quando ~ / go não existe, go pode criá-lo, fazer o .dotfile e execuções futuras podem encontrá-lo. Se eu definir GOPATH explicitamente como ~ / go, nenhum .dotfile será necessário, pois nenhum valor padrão está sendo usado.

O dotfile existe. É o diretório src / dentro de $ HOME / go.

Na quarta-feira, 26 de outubro de 2016, 07:59 RalphCorderoy [email protected] escreveu:

Como alguém que teve que renomear ~ / bin / go por causa do Go, gosto de sugerir
que seja qual for o padrão, se já existe, então tem que ter um
.dotfile nele para indicar que é realmente Go's ~ / go. Quando ~ / go não existe,
go pode criá-lo, fazer o .dotfile e execuções futuras podem encontrá-lo. Se eu
definir explicitamente GOPATH para ~ / go, então nenhum arquivo .dot será necessário, pois não
o valor padrão está sendo usado.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -256173981 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAAcA4Vud3wlDe_npYNgKcGEWty6c3oYks5q3m2ngaJpZM4KI0I2
.

CL https://golang.org/cl/32019 menciona esse problema.

Mesmo que alguns programadores não estejam cientes das variáveis ​​de ambiente, eles
deve pelo menos estar familiarizado com _variables_. Acho que vamos precisar
usar algo para descrever a localização de um espaço de trabalho nos documentos e
a string $GOPATH pode ser isso.

Em 26 de outubro de 2016 às 06:24, Jaana Burcu Dogan [email protected]
escreveu:

A documentação inicial pode assumir o padrão e não mencionar o ambiente
variáveis ​​em tudo.

SGTM

Existem dois tipos de usuários Go:

• Usuários que simplesmente obtêm pacotes existentes
• Usuários que são desenvolvedores Go

O GOPATH padrão está corrigindo o caso do primeiro grupo. Ainda podemos manter
Instruções relacionadas ao GOPATH para os documentos voltados para desenvolvedores. o
a instalação não deveria ter que mencionar a configuração do GOPATH ou nós
pode ter um apêndice como @davecheney https://github.com/davecheney
menções.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -256149104 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AIDilZoQV3Ye3BOMS9uIMglI9GeDQeq7ks5q3ld3gaJpZM4KI0I2
.

Obrigado é a intenção, consulte a proposta original.

Na verdade, agora podemos dizer "vá buscar irá baixar o código-fonte para uma pasta
chamado, vá / src / github.com / Foo / Bar dentro do seu diretório inicial "

Na quarta-feira, 26 de outubro de 2016, 06:01 Nathan Youngman [email protected] escreveu:

Talvez $ HOME / go / ... possa ser substituído (ou o equivalente em
Janelas)?

Como você adicionou $ HOME / go / bin ao seu PATH (ou $ GOPATH / bin se GOPATH for
definir)...

Talvez em algum ponto a documentação possa esperar que os indivíduos não
defina apenas a variável de ambiente PATH, mas também defina GOPATH como $ HOME / go.
Embora redundante, torna a documentação posterior clara.

A documentação inicial pode assumir o padrão e não mencionar o ambiente
variáveis ​​em tudo?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -256142424 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

Este seria um grande problema para a última semana do Hacktoberfest

O dotfile existe. É o diretório src / dentro de $ HOME / go

"src" é uma maneira comum de ser um dotfile "foi criado como um GOPATH padrão pelo Go".

O que você está tentando prevenir?

Na quarta-feira, 26 de outubro de 2016 às 9h20, RalphCorderoy [email protected]
escreveu:

O dotfile existe. É o diretório src / dentro de $ HOME / go

"src" é uma maneira comum de ser um "isso foi criado como GOPATH padrão por
Vá "dotfile.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -256194536 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAAcA057US0NKkEj669vwpatED2ECxA9ks5q3oChgaJpZM4KI0I2
.

$ HOME / vai ser.

O que será para usuários do Windows?

Alex

Os usuários do Windows usarão %USERPROFILE%\go , assim como o Docker faz aqui .

@davecheney , estou tentando evitar o que disse há duas horas: https://github.com/golang/go/issues/17262#issuecomment -256173981

Go é uma palavra comum. Eu tive um ~ / bin / go. As pessoas jogam Go e têm o código-fonte relacionado ao play go. Nabbing ~ / go por padrão quando já existe apenas porque contém src é rude. Se ~ / go não existir, então Go pode pegar o nome, criar o diretório, carimbá-lo como golang's com um dotfile significativo, por exemplo, baseado no nome de domínio golang.org.

Esse é o problema, e uma solução possível, de qualquer maneira. Mesmo que a solução não seja a certa, isso não significa que o problema não exista.

Eu voto em $ HOME / grupo

Obrigado.

Podemos usar o padrão GOPATH como ~/.gosrc ?

Podemos usar o padrão GOPATH como ~/.gosrc ?

Isso ficará oculto por padrão no Linux e OS X e visível no Windows. Qual seria a motivação para esconder o GOPATH?

A discussão sobre o valor da inadimplência ocorreu há um mês. A decisão sobre $HOME/go foi feita e já está sendo implementada. Voltar a esse tópico apenas tornará o tópico insuportavelmente longo.

As pessoas jogam Go e têm o código-fonte relacionado ao play go.

Eu realmente não estou te seguindo, mas dado que você configurou GOPATH para
outra coisa, não haverá impacto para você.

Na quarta-feira, 26 de outubro de 2016 às 9h43, RalphCorderoy [email protected]
escreveu:

@davecheney https://github.com/davecheney , estou tentando evitar o que eu
disse há duas horas: # 17262 (comentário)
https://github.com/golang/go/issues/17262#issuecomment -256173981

Go é uma palavra comum. Eu tive um ~ / bin / go. As pessoas jogam Go e têm o código-fonte
a ver com jogar go. Nabbing ~ / go por padrão quando já existe apenas
porque contém src é rude. Se ~ / go não existir, então Go
pode pegar o nome, criar o diretório, carimbá-lo como golang com um
dotfile significativo, por exemplo, baseado no nome de domínio golang.org.

Esse é o problema, e uma solução possível, de qualquer maneira. Mesmo se a solução
não é o certo, isso não significa que o problema não exista.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -256199766 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAAcA-KTyB6tBYDEVVjHo9Aeb5szXVGbks5q3oYXgaJpZM4KI0I2
.

Olá @davecheney , Este problema começou com você propondo ~ / gocode. Com o tempo, tornou-se ~ / go. @robpike disse acima "só pode ser um problema escolher esse nome se $ HOME / go já existir, o que só agradará os especialistas que já têm o go instalado e entenderão o GOPATH". Acho que por estar envolvido em golang por tanto tempo, você coletivamente está esquecendo o quão comum é uma palavra "ir" e como ela tem outros significados, como o jogo de tabuleiro.

Essa mudança é destinada a recém-chegados ao Go e alguns deles já podem ter ~ / go para um uso não Go. Estou sugerindo que se go vier, encontrar GOPATH não configurado e não existir ~ / go, então ele pode criá-lo, pegando o nome. Mas se ~ / go existir, ele só deve usá-lo se puder dizer que o criou em uma chamada anterior sem GOPATH. Eu sugeri um dotfile ser criado como este sinalizador. Você disse que ~ / go / src servirá como esse sinalizador. Minha objeção é que o próprio src não é incomum entre os programadores, ou seja, aqueles que podem instalar o Go. Um arquivo de ponto incomum, por exemplo, ~ / go / .default-gopath evita esse conflito potencial.

Se eles criaram manualmente ~ / go para Go e execute go sem GOPATH, então ele não usará ~ / go porque o dotfile está faltando. Acho que está tudo bem, pois ao começar a configurar uma instalação Go, eles devem continuar, configurando GOPATH. Eles não são o caso simples de "instalar pacote, execute go (1)" que está sendo direcionado.

Se nada disso for considerado um problema, tudo bem. Mas, enquanto você reclamar que não entende meu ponto, estou condenado a continuar tentando explicá-lo.

É por isso que originalmente sugeri um caminho diferente, com a sugestão de Rob que agora está oficialmente fora de minhas mãos.

Com isso dito, estou feliz que _um_ caminho tenha sido escolhido, pois vejo isso como o objetivo do exercício.

Para responder às suas preocupações, recomendo que você siga https://go-review.googlesource.com/#/c/32019/ onde exatamente o problema que o preocupa está sendo discutido.

@RalphCorderoy , sua preocupação é que os programadores de jogos de tabuleiro tenham um diretório ~ / go para hackear jogos de tabuleiro?

Rob e Russ são muito anti-dotfiles. É melhor declarar o problema do que a resposta se a resposta envolver dotfiles (ou links simbólicos).

@bradfitz , sim, ~ / go já existe para jogadores de gogame, e mais ~ / go / src existe porque eles são jogadores programadores de gogame, do contrário não estariam brincando com Go. (Eu tenho ~ / chess / src conforme acontece.)

A lógica de resumo do adg https://go-review.googlesource.com/c/32019/#message -09c4c4bbe1d840f07e0172ca9c7c3896a6c12f5c parece boa e sou a favor da criação de ~ / go se não existir, mas test -d ~/go/src é um teste instável para usar ~ / go se não houver GOPATH.

Se não fosse ~ / go, mas algo mais incomum, como a sugestão original de Dave, então não faria diferença. Acho que as pesquisas sobre o que é usado atualmente e que mostraram que ~ / go era muito popular não são muito úteis quando os eleitores são programadores Go suficientemente ansiosos para acompanhar as questões e as redes sociais.

@RalphCorderoy Acho que a quantidade de cuidado e cuecas duplas sendo projetadas no CL 32019 é mais do que suficiente para o potencial inconveniente para o pequeno conjunto de programadores de jogos que _não_ usaram Go antes da versão 1.8 e _não_ configuraram GOPATH _and_ também estão começando a aprender Go, o idioma.

A ferramenta go não vai deletar ou corromper nenhum código não go que encontrar, você apenas receberá uma mensagem um pouco confusa em _poucas_ situações. Para explicar isso, a ferramenta go não criará o código-fonte Go no início de $GOPATH/src porque esse código não está dentro de um pacote importável. Além disso, o outro objetivo dessa mudança é tornar mais fácil go get algum código, fornecendo um local padrão para o download do código-fonte, de forma que _se_ houvesse o código-fonte do jogo em ~/go/src , as chances de entrar em conflito com um subdiretório derivado de um repositório go gettable são muito remotas e, mesmo que isso acontecesse, a ferramenta go ou git desapareceria antes que qualquer dado fosse alterado.

Acho que a situação com a qual você está preocupado é muito improvável e ainda mais atenuada pela explicação acima.

(Apenas um provável argumento válido contra GOPATH=$HOME ): O desempenho de goimports resolvido? Lembro-me de algo sobre um arquivo .goimport_ignore . Caso contrário, o desempenho para editores populares pode ser prejudicado.

Portanto, GOPATH!=$HOME é provavelmente uma opção livre de colisão / não poluída e deve ter um bom desempenho.

@davecheney Depois de go get eu teria lixo para limpar de ~ / go / {bin, src, pkg} e não seria uma boa introdução a Go tendo colado a linha que encontrei na Internet.

@RalphCorderoy, por favor, entenda que o objetivo desta mudança é tornar mais fácil para novos usuários Go - este não é você - você já tem $ GOPATH definido, porque você _terá_ com cada versão do Go a partir da 1.1. A sobreposição entre usuários do jogo e usuários _potenciais da linguagem de programação é muito pequena. Não acho que haverá um problema.

@RalphCorderoy A situação que você está descrevendo é rara, e qualquer pessoa que execute comandos shell de um site aleatório não deve ter expectativas de que seus discos não serão apagados, muito menos alguns arquivos baixados e embaralhados em um diretório de mesmo nome. (Editar: considere o Wine auto-criar e modificar .wine no diretório inicial do usuário. E se o usuário tiver algo mais lá? Afinal, "vinho" é um termo que usamos para uma bebida específica.)

A colisão de nomes entre "Vá" a linguagem e "Vá" o jogo de tabuleiro é certamente compreendida e bem conhecida. O sistema de arquivos é um recurso compartilhado, as colisões acontecem e são inevitáveis.

@davecheney , pare de me dizer que essa mudança não tem o objetivo de me ajudar porque não sou um novo usuário de Go. Sempre estive ciente disso, mesmo antes de você começar a apontar. Eu também entendo que sua posição é len (intersect (existing- ~ / go, GOPATH-less)) é muito pequena para causar preocupação.

Depois de limpar o vômito go-get em ~ / go porque ele sabia o que normalmente não estava lá, ele teria que pesquisar para ver o que mais o (s) comando (s) podem ter feito em $ HOME caso haja mais a limpeza era necessária.

Cancelar subscrição

Lamento se lhe causei qualquer ofensa. Eu não desejo mais corresponder
com você sobre este assunto. Obrigada.

Na sexta-feira, 28 de outubro de 2016 às 03h28, RalphCorderoy [email protected]
escreveu:

@davecheney https://github.com/davecheney , pare de me dizer isso
A mudança não tem como objetivo me ajudar porque não sou um novo usuário Go. eu tenho
sempre esteve ciente disso, mesmo antes de começar a apontá-lo. eu também
entenda que sua posição é len (intersect (existing- ~ / go, GOPATH-less)) é
muito pequeno para ser motivo de preocupação.

Depois de limpar o vômito go-get em ~ / go porque ele sabe o que
normalmente não estava lá, ele então teria que pesquisar para ver o que mais
o (s) comando (s) pode (m) ter sido executado (s) em $ HOME no caso de ser necessária mais limpeza.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/golang/go/issues/17262#issuecomment -256697043 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAAcAyE8xRIcxvwgRfalJoqZa3TBU9Z3ks5q4NEcgaJpZM4KI0I2
.

davecheney, Não, não é ofensa. Simplesmente não adianta continuar cobrindo o mesmo terreno.

Apenas me perguntando - qual é o comportamento esperado se $HOME não estiver definido?

Embora eu nunca tenha trabalhado em um sistema onde esse fosse o caso, parece possível que alguém tenha modificado seus env vars padrão por algum motivo, e este caso extremo deve ser tratado de forma consistente.

Acho que atualmente avalia $GOPATH='' ; isso significa que vai usar o diretório de trabalho atual?

use o diretório de trabalho atual

Ocorreu-me que isso pode ser o mais útil para um novo usuário Go que não configurou GOPATH. Um go get seria semelhante a um wget, etc., preenchendo o diretório atual. Eles não estão interessados ​​no aspecto do caminho do GOPATH neste ponto e, muito possivelmente, desejam que todos os seus empreendimentos em brincar com diferentes coisas online sejam distintos, como um novo diretório temporário de sua própria criação os proporcionaria. Eles podem obter, executar e excluir facilmente os diferentes repositórios que veem referenciados.

• se GOPATH não estiver definido:
  
  
  
  • se apenas um ou dois, mas não todos, de ~ / {bin, pkg, src} existirem:
  
  
  • eles têm que definir GOPATH, pkg é o incomum
  
  
  • senão existe tudo ou nada:
  
  
  • garantir que todos eles existam
  
  
  • GOPATH = $ (pwd)
  
  

Tenho dúvidas sobre isso, mas meu sentimento predominante (como alguém que definiu $GOPATH ) é que o comportamento de go get deve ser "determinístico" e sempre instalar coisas sob $GOPATH - um destino consistente e bem documentado.

Mesmo que eu não seja afetado por esta mudança, parece estranho que go get baixará coisas para locais diferentes dependendo de qual diretório de trabalho está quando o comando é emitido. Estou ciente de que isso é o que wget , npm install e outras ferramentas fazem, mas parece um desvio da ideia de um $GOPATH consistente (que é como eu interpretou o espírito desta mudança).

Se isso estiver além do escopo deste problema, eu proporia simplesmente sair e gerar um erro se $HOME estiver definido.

Eu ensinei 5 novos programadores que vieram do mundo Java em um país do terceiro mundo. Todos eles estavam confusos com certeza sobre o GOPATH. Caramba, eu também estava quando comecei a voltar antes do Go 1 ser lançado. Eu pessoalmente uso "$ HOME / gopath", mas sugiro que o comando "go get" os direcione para um blog go que é CLARO sobre como criar um caminho go para seu sistema operacional. É tudo de que precisamos. Alguma orientação do comando "go get" que não é uma especificação .. Mas um post de blog muito simples !!

Obviamente, quero dizer quando nenhum GOPATH foi definido. Basta atualizar a mensagem de erro exibida atualmente. A taxa de adoção já está lá .. Só preciso de um pouco de ajuda em vez do método google it up atual que os novatos estão fazendo.

@einthusan Acho que está muito bem documentado em https://golang.org/doc/code.html#GOPATH , mas não sei quantas pessoas começando com Go realmente lêem esta página.

Desculpe por fazer spam .. Depois de pesquisar no Google .. Acho que "vá buscar" deveria apenas avisar o usuário: "Nenhum GOPATH foi definido ... Você gostaria de usar o diretório de trabalho atual como seu GOPATH temporário?" (Sim não)

@einthusan , não há precedente para cmd / go fazer prompts interativos.

Se o novo GOPATH padrão for $ HOME / go. As pessoas não esperariam que este https://hub.docker.com/_/golang/ adotasse o mesmo comportamento?

@cescoferraro essa é uma questão para os mantenedores dessa imagem. Apesar de ser rotulado como "oficial", esse projeto não é afiliado ao Go.

Respondendo / respondendo à minha própria pergunta sobre não definir $HOME :

Na implementação atual (o CL está vinculado acima), $GOPATH padroniza para "" se $HOME não estiver definido: https://go-review.googlesource.com/#/ c / 32019/11 / src / go / build / build.go Acho que isso é consistente com o comportamento atual.

Acredito que esse caso extremo seja muito improvável, já que $HOME é sempre definido em uma sessão de login normal, o que é provavelmente o caso para a maioria dos programadores de Go. Embora eu pessoalmente _gostasse_ que o comportamento fosse explicitamente esclarecido, parece que não há "efeitos colaterais" (como instalar coisas no diretório de trabalho). Corrija-me se eu estiver errado. :)

Se isso é para tornar mais fácil para as pessoas que começam com Go pela primeira vez, que seja algo como o caminho atual:

GOPATH=$(pwd)

Definir export GOPATH=$(pwd) torna mais fácil alternar entre projetos

Meu comportamento proposto para esta mudança:

Variáveis ​​ambientais

• Se GOPATH estiver definido, as ferramentas se comportam como sempre
• Caso contrário, verificamos a variável de ambiente HOME ( home para plan9, USERPROFILE para windows).
  
  
  
  • Se essa variável env não for definida, então GOPATH também não será definido: isso significa que "go get" irá falhar com cannot download, $GOPATH not set.
  
  

> unset GOPATH
> unset HOME
> go env GOPATH

• Caso contrário, GOPATH será definido como $HOME/go ( $home/go , %USERPROFILE%\go ).

> unset GOPATH
> go env GOPATH
/Users/campoy/go

Criação GOPATH

Atualmente, se $GOPATH não existir, ele é criado quando executamos go get import/path . Isso não vai mudar.

A única mudança é que se $GOPATH não estiver definido no ambiente do usuário (ou seja, echo $ GOPATH não exibe nenhum valor), uma verificação extra é realizada para garantir que o valor padrão seja aceitável:

• se GOPATH não estiver definido e nenhum valor padrão tiver sido criado: o comando irá falhar

> unset GOPATH
> unset HOME
> go get github.com/golang/example/hello
package github.com/golang/example/hello: cannot download, $GOPATH not set. For more details see: 'go help gopath'
👎

• se o $GOPATH padrão não existir, um aviso será exibido explicando que o diretório foi criado, apontando para go help gopath para obter mais informações.

> unset GOPATH
> go get github.com/golang/example/hello
warning: GOPATH is not set, creating directory /Users/campoy/go. See 'go help gopath' for more information
👍

• se o $GOPATH padrão existe:
  
  
  
  • e não é um diretório: o comando irá falhar (como acontecia antes)
  
  

> unset GOPATH
> touch ~/go
> go get github.com/golang/example/hello
package github.com/golang/example/hello: can't use GOPATH at /Users/campoy/go: it is not a directory
👎

• e é um diretório vazio ou um diretório que tem um subdiretório chamado src o comando será bem-sucedido (sem avisos)

> unset GOPATH
> mkdir ~/go
> go get github.com/golang/example/hello
👍

> unset GOPATH
> mkdir -p ~/go/src
> touch ~/go/others
> go get github.com/golang/example/hello
👍

• e é um diretório não vazio sem um subdiretório chamado src o comando irá falhar

> unset GOPATH
> mkdir ~/go
> touch ~/go/others
> go get github.com/golang/example/hello
package github.com/golang/example/hello: can't use GOPATH at /Users/campoy/go: it is not empty, and no 'src' was found
👎

Portanto, apenas um novo aviso é incluído sempre que um diretório é criado usando um GOPATH padrão.

@campoy a proposta de comportamento parece ótima.

Mas, novamente, como um usuário avançado, quero saber quantos de nós usam seriamente $HOME/go como GOPATH diariamente. Eu estava até pensando que talvez devesse haver um comando go para definir o GOPATH semelhante a iniciar um env virtual em um diretório de trabalho python.

Como trabalho em vários projetos, geralmente faço algo assim:

$ cd foo-app
$ export GOPATH=$(pwd)

# switching to another app
$ cd ../foobar-app
$ export GOPATH=$(pwd)

@jinmatt
Esta mudança apenas modifica o comportamento para GOPATH não definido, esse é o escopo da mudança.
A comunidade já chegou a um acordo sobre $ HOME / go.

Se você não gosta de $HOME/go , apenas defina GOPATH com o valor de sua preferência (por exemplo, $ HOME no meu caso).

Obrigado pelo esboço do projeto.

1. Como agora estabelecemos que GOPATH só será criado durante 'go get', vamos imprimir mensagens apenas se o sinalizador -v for fornecido, consistente com o resto do comportamento 'go get -v'.
2. Se o diretório for criado, a mensagem deve ser no máximo

# created GOPATH = / users / campoy / go; veja 'vá ajudar gopata'

Não é um aviso: os avisos são ruins. Por outro lado, se a criação falhar, você pode querer imprimir

go: creating GOPATH=/users/campoy/go: %v

Ambas as mensagens podem ser impressas independentemente de GOPATH ser inferido ou definido explicitamente.

1. As heurísticas sobre o diretório vazio e ter um subdiretório src são muito complexas. Pior, eles estão tratando de problemas hipotéticos, e para os quais é muito difícil projetar hipotéticos. Melhor ter um comportamento mais simples e previsível. Para começar, acho que faz sentido não ter regras, até que haja exemplos concretos de problemas reais. Haverá tempo para que as pessoas relatem problemas durante os betas e candidatos ao lançamento. Vamos apenas definir GOPATH = $ HOME / go (desde que $ HOME esteja definido).

Edit: finja que o markdown do Github não estragou tudo completamente.

@campoy Com relação ao src/ , qual é o comportamento atual de go get quando um GOPATH é definido, mas não existe um diretório src? Existe uma boa razão para não criá-lo também?

Parece mais simples explicar se $ HOME / go / src for criado no primeiro go get (ou $ GOPATH / src se essa variável de ambiente estiver definida)

Hoje, quando GOPATH é definido, os diretórios necessários são criados, incondicionalmente, conforme necessário.

CL https://golang.org/cl/33356 menciona esse problema.

CL https://golang.org/cl/33730 menciona esse problema.