การมีซอร์สโค้ดสำหรับโครงการ Go นอก GOPATH เป็นความคิดที่ไม่ดี

32

ฉันกำลังทำงานในโครงการใหม่โดยใช้ Go และเราทุกคนยังใหม่กับ Go เรากำลังติดตามโครงสร้างไดเรคทอรี go มาตรฐานและมีโค้ดทั้งหมดอยู่ด้านล่าง

$ GOPATH / src / github.com / CompanyName / projectname

ซึ่งก็เป็นรากของพื้นที่เก็บข้อมูลคอมไพล์

รูปแบบเส้นทางที่แนะนำมาตรฐานดูเหมือนแปลกโดยเฉพาะอย่างยิ่งถ้าเรากำลังทำงานในโครงการหลายภาษาเช่นส่วนที่เหลือตาม Go / http backend และ html / javascript front-end ในกรณีนี้ฉันอาจต้องการให้โครงสร้างโครงการของฉันเป็นดังนี้:

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

แต่จริง ๆ แล้วจำเป็นต้องวางรหัสไว้ใน GOPATH หรือไม่

ในความพยายามฉันได้สร้างโปรแกรมขนาดเล็กที่ซอร์สโค้ดอยู่นอก GOPATH ฉันได้อย่างง่ายดายสามารถแยกโครงการออกเป็นแพคเกจเพื่อให้mainแพคเกจสามารถอ้างอิงfooแพคเกจในโฟลเดอร์โดยใช้foo/import "./foo"

เท่าที่ฉันเห็นมีสองสิ่งที่ไม่เชื่อฟังฉัน:

รหัสอื่นไม่สามารถนำเข้ารหัสนี้ได้ นี่ไม่ใช่ปัญหาเนื่องจากเราสร้างบริการเฉพาะสำหรับ บริษัท
ฉันไม่สามารถใช้go installเพื่อติดตั้งได้ ไม่มีปัญหาเช่นกัน ไปป์ไลน์การติดตั้งเครื่องมือ

อย่างไรก็ตามอนุญาตให้เซิร์ฟเวอร์การสร้างไม่มีพื้นที่ทำงานอยู่ภายใน GOPATH

วิธีการดังกล่าวท้อใจหรือไม่ ถ้าเป็นเช่นนั้นทำไมถึงเป็นเช่นนั้น?

มีผลข้างเคียงเชิงลบอื่น ๆ นอกเหนือจากที่ฉันระบุ

โปรดจำไว้ว่านี่เป็นโครงการส่วนตัวสำหรับ บริษัท ไม่ใช่รหัสโอเพ่นซอร์สสาธารณะ

การแยกโครงการจริงออกจาก GOPATH นั้นน่าดึงดูด แต่ก็ควรระวังในการทำลายกฎเมื่อคุณอยู่บนเวทีชู

go

— พีท
แหล่งที่มา

12

คุณไม่จำเป็นต้องใช้ GOPATH แต่คุณพลาดเครื่องมือที่ดีทั้งหมดที่คุณได้รับจากgoคำสั่ง พวกเขาทุกคนคาดหวังว่ารหัสจะอยู่ในลำดับชั้น GOPATH มาตรฐาน

คุณพูดถึงgo installแต่ยังgo test(และgo test -coverเครื่องมือการครอบคลุมที่ดี) จะไม่ทำงานgo getซึ่งช่วยให้คุณดาวน์โหลดรหัสระยะไกลจะเขียนทุกอย่างไปยัง GOPATH ดังนั้นคุณจะต้องคัดลอกสิ่งต่าง ๆ

แน่นอนว่าคุณสามารถแทนที่ได้ทั้งหมดด้วยการทำ / scons / cmake / อะไรก็ตามและทำสิ่งต่าง ๆ ให้เสร็จและมันอาจจะใช้ได้กับสภาพแวดล้อมของคุณ แต่งานพิเศษที่สามารถทำได้โดยใช้goเครื่องมือ

— iccananea
แหล่งที่มา

9

(ข้อจำกัดความรับผิดชอบ: ฉันชอบการออกแบบสิ่งนี้ แต่ฉันใหม่สำหรับ Go ฉันไม่ได้ลองในทางปฏิบัติ)

แนวคิด: ทำไมไม่ใช่ทั้งสองอย่าง

มีตัวเลือกขั้วโลกให้เลือกสองแบบถ้าคุณคำนึงถึงการเชื่อมโยงเข้าด้วยกัน:

(A) รหัสใน src เชื่อมโยงกับพื้นที่ทำงาน

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

(B) รหัสในเวิร์กสเปซ symlinked กับ src

/
  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" เพราะ:

แหล่งข้อมูลทั้งหมดของคุณอาศัยอยู่ใกล้กัน
projectname สามารถมี repo ของตนเองหรือคุณสามารถมี repo หนึ่งอันสำหรับโครงการทั้งหมดของคุณ
คุณสามารถเก็บgo_workspaceunversioned ทั้งหมดและเริ่มต้นได้ผ่านขั้นตอนการทำ (ใช้godepแล้ว symlinking โครงการ)

— คอส
แหล่งที่มา

1

จะต้องเป็น "A" เนื่องจากด้วย "B" go จะบ่น "go install: ไม่มีตำแหน่งการติดตั้งสำหรับไดเรกทอรี {dir} นอก GOPATH"

— OJFord

2

อัพเดต 2019

คุณไม่จำเป็นต้องจัดเก็บโครงการของคุณGOPATHอีกต่อไป

GOPATHเพียงแค่ใส่มันนอกไดเรกทอรีใด ๆ จากนั้นพิมพ์:

go mod init github.com/youruser/yourproject

คุณจะดีไป

— Inanc Gumus
แหล่งที่มา