Je prends go1.11rc1 pour un tour et la première chose que j'ai remarquée est que goland ne reconnaît pas les importations.
annonce de la version de goland dit: "support des modules Go prêts à l'emploi (anciennement appelé vgo)"
Quelqu'un sait comment réparer ceci?
Problème:
Étapes à reproduire:
mkdir pjg && cd pjg
go.mod
fichier: go mod init github.com/stevetarver/pjg
go get github.com/urfave/cli
go.mod
le fichier ressemble maintenant à:
module github.com/stevetarver/pjg/v1
require github.com/urfave/cli v1.20.0 // indirect
Créer main.go
:
package main
import (
"fmt"
"log"
"os"
"github.com/urfave/cli"
)
func main() {
app := cli.NewApp()
app.Name = "boom"
app.Usage = "make an explosive entrance"
app.Action = func(c *cli.Context) error {
fmt.Println("boom! I say!")
return nil
}
err := app.Run(os.Args)
if err != nil {
log.Fatal(err)
}
}
Vue main.go
dans goland, et survolez le texte rouge pour voir le problème.
$GOPATH/pkg/mod/
Remarques:
$GOPATH
est défini correctement - go get
place le paquet au bon endroit, GOPATH en env correspond aux préférences de goland./Users/starver/code/go/pkg/mod
n'a pas résolu ce problème.La dernière version de GoLand a implémenté la prise en charge des modules vgo et go, mais elle n'a pas rattrapé les changements de syntaxe go1.11rc1. Juste au cas où cela aiderait quelqu'un dans l'intervalle, je vais documenter les choses que j'ai essayées et leurs problèmes et succès.
TL; DR : Ne placez pas votre projet dans $GOPATH
ET créez votre nouveau projet en tant que type "Go Module (vgo)", OR activez ce paramètre pour les projets existants.
Avec go1.11rc1 installé en tant que votre go
global, il existe trois cas d'utilisation de base pour go mod
projets dans GoLand ...
$GOPATH
:$GOPATH
: $GOPATH/src/github.com/stevetarver/insidegopath
main.go
fichier référençant un package qui n'existe pas dans votre $GOPATH
.En utilisant go get
la manière GoLand via vgo
comme décrit dans le gif ici :
go: go mod -sync is now go mod tidy
En utilisant go get
la voie du terminal embarqué GoLand:
go get
votre importation.ᐅ go get github.com/urfave/cli go get: warning: modules disabled by GO111MODULE=auto in GOPATH/src; ignoring go.mod; see 'go help modules'
Allumons cette variable et réessayons:
GO111MODULE=on
: Ouvrez Préférences -> Apparence et comportement -> Variables de chemin et ajoutez GO111MODULE=on
.env | grep GO111MODULE
dans le terminal ne produit rien.Vous pouvez définir GO111MODULE=on
dans votre script d'initialisation Shell, mais cela casserait tous les projets qui n'utilisent pas encore les modules go.
Vous pouvez également préfixer chaque commande go avec la variable env var: export GO111MODULE=on; go get github.com/urfave/cli
ou créez un go
wrapper de script Shell dans votre répertoire de projet qui le fait pour vous.
Aucune de ces solutions n'est vraiment réalisable, mais une partie des modules point of go est de s'échapper de l'espace de travail go redouté, alors lisez la suite, ça va mieux
$GOPATH
:$GOPATH
go.mod
: le fichier généré contient module "outsidegopath"
, mais nous voulons quelque chose comme module github.com/stevetarver/outsidegopath
. C'est un peu bizarre - GoLand essaiera de réécrire go.mod
et supprimez des parties du chemin. Répétez quelques fois et cela cessera d'essayer.main.go
fichier. Si vous créez ceci via l'ide en tant que fichier go, il contiendra package outsidegopath
. Corrigez cela pour être package main
.go get github.com/urfave/cli
et il est récupéré dans $GOPATH/pkg/mod
comme prévu.go mod
support pour un nouveau projet existant :Cela s'est avéré être très simple - la meilleure façon de travailler avec les modules go dans GoLand:
go.mod
avec go mod init module-name
.La gestion du module devrait être plus facile avec Go 1.13 (août 2019):
Le
GO111MODULE
la variable d'environnement continue par défaut àauto
, mais le paramètreauto
active désormais le mode de détection de module de la commandego
chaque fois que le répertoire de travail actuel contient ou est inférieur à un répertoire contenant, ungo.mod
fichier - même si le répertoire courant se trouve dansGOPATH/src
.Cette modification simplifie la migration du code existant dans
GOPATH/src
et la maintenance continue des packages compatibles avec les modules aux côtés d'importateurs non compatibles avec les modules.
Cela signifie que le "Ne mettez pas votre projet à l'intérieur $GOPATH
"ne sera plus nécessaire.
Tant qu'il y a go.mod
fichier, les modules seront reconnus, depuis la ligne de commande ou depuis un IDE comme Goland .