GOPATH dışındaki bir Go projesi için kaynak kodu olması kötü bir fikir mi?

Go kullanarak yeni bir proje üzerinde çalışıyorum ve hepimiz Go için yeniyiz. Standart go dizini yapısını takip ediyoruz ve tüm kodlar altında

GOPATH / src / github.com / companyname / projectname, $

aynı zamanda bir git deposunun köküdür

Standart önerilen yol düzeni biraz garip görünüyor, özellikle Go tabanlı bir dinlenme / http arka ucu ve bir html / javascript ön ucu gibi çok dilli bir proje üzerinde çalışıyorsak. Bu durumda, proje yapımın şöyle görünmesini isterdim:

/
  doc/
  src/
    server/
      main.go
      module1/
        module.go
    client/
      index.html
  Makefile

Ancak kodun GOPATH içine yerleştirilmesi gerekli midir?

Bir girişim olarak kaynak kodun GOPATH'ın dışında olduğu küçük bir program oluşturdum. Projeyi kolaylıkla paketlere bölebilirim, böylece paket bir klasördeki mainbir foopakete foo/başvurabilirdi import "./foo".

Görebildiğim kadarıyla, bu bana izin vermeyen iki şey var:

• Diğer kod bu kodu alamaz. Şirket için özel olarak hizmet sunduğumuz için bu bir sorun değil.
• go installYüklemek için kullanamıyorum . Bu da bir sorun değil. Yapı boru hattı aracı yükler.

Ancak, derleme sunucusunun çalışma alanının GOPATH içinde bulunmamasını sağlar

Böyle bir yaklaşım tavsiye edilmez mi? Öyleyse, neden öyleyse?

Listelediğimden başka olumsuz yan etkileri var mı?

Bunun kamuya açık kaynak koduna değil, bir şirkete özel bir proje olduğunu unutmayın.

Asıl projeyi GOPATH'tan ayırmak cazip geliyor, ancak Shu sahnesindeyken kuralları çiğnemeye dikkat etmek gerekiyor.

GOPATH kullanmanız gerekmiyor, ancak komuttan aldığınız tüm güzel takımları kaçırıyorsunuz go. Hepsi kodun standart GOPATH hiyerarşisinde olmasını bekliyorlar.

Bahsettiniz go install, ancak ayrıca go test(ve hoş go test -coverkapsama aracı) çalışmaz go get, bu da uzaktan kod indirmenize izin veren her şeyi GOPATH'a yazar, bu yüzden bir şeyler kopyalamanız gerekir.

Elbette, hepsini make / scons / cmake / ile değiştirebilir ve her şeyi halledebilirsiniz ve muhtemelen ortamınız için işe yarayacaktır, ancak bunun goaraç tarafından yapılabilecek ekstra işi olabilir .

(feragatname: Böyle şeyler tasarlamaktan hoşlanırım ama Gitmeye yeniyim, pratikte denemedim)

Fikir: Neden ikisi de değil?

Eğer dikkate almayı dikkate alırsanız, iki kutup seçeneği vardır:

(A) src kodunda, çalışma alanına bağlanmış

/
  doc/
  src/
    server/
      projectname/
    client/
      index.html
  go_workspace/
    src/
      companyname/
        projectname -> ../../../src/server/projectname
      github.com/
        someone/
          library/
    bin/
    pkg/
  Makefile

(B) Çalışma alanındaki kod, src ile eşleştirilmiş

/
  doc/
  src/
    server/
      projectname -> ../../go_workspace/src/companyname/projectname
    client/
      index.html
  go_workspace/
    src/
      companyname/
        projectname/
      github.com/
        someone/
          somelib/
    bin/
    pkg/
  Makefile

"A" ya doğru eğildim çünkü:

• tüm kaynaklarınız fiziksel olarak birbirine yakın yaşıyor
• projectname kolayca kendi deponuzu alabilir veya tüm projeniz için bir reponuzu alabilir,
• bütünüyle değişmeden kalabilir ve go_workspacebunu bir basamaklama adımında godepbaşlatabilirsiniz ( sonra projeyi işaretleyerek)

2019 Güncellemesi

Projenizi GOPATHartık saklamanıza gerek yok.

Sadece dışındaki herhangi bir dizine koyun GOPATH. Sonra şunu yazın:

go mod init github.com/youruser/yourproject

Gitmek için iyi olacaksın.