ฉันจะนำเข้าแพ็คเกจเวอร์ชันเฉพาะโดยใช้ go get ได้อย่างไร

มาจากNodeสภาพแวดล้อมที่ฉันเคยติดตั้งเวอร์ชันเฉพาะของผู้จำหน่าย lib ลงในโฟลเดอร์โครงการ ( node_modules) โดยบอกnpmให้ติดตั้ง lib เวอร์ชันนั้นจากpackage.jsonหรือแม้แต่โดยตรงจากคอนโซลเช่น:

$ npm install express@4.0.0

จากนั้นฉันเคยนำเข้าเวอร์ชันของแพ็คเกจนั้นในโครงการของฉันด้วย:

var express = require('express');

goตอนนี้ผมต้องการที่จะทำสิ่งเดียวกันกับ ฉันจะทำเช่นนั้นได้อย่างไร? เป็นไปได้ไหมที่จะติดตั้งแพ็คเกจเวอร์ชันเฉพาะ ถ้าใช้แบบรวมศูนย์$GOPATHฉันจะนำเข้าเวอร์ชันหนึ่งแทนที่จะเป็นเวอร์ชันอื่นได้อย่างไร

ฉันจะทำสิ่งนี้:

$ go get github.com/wilk/uuid@0.0.1
$ go get github.com/wilk/uuid@0.0.2

แต่แล้วฉันจะสร้างความแตกต่างระหว่างการนำเข้าได้อย่างไร

Go 1.11 จะมีคุณสมบัติที่เรียกว่า go module และคุณสามารถเพิ่มการพึ่งพาด้วยเวอร์ชันได้ ทำตามขั้นตอนเหล่านี้:

go mod init .
go mod edit -require github.com/wilk/uuid@0.0.1` 
go get -v -t ./...   
go build
go install 

ข้อมูลเพิ่มเติมเกี่ยวกับหัวข้อนั้น - https://github.com/golang/go/wiki/Modules

จริงๆไม่มีใครแปลกใจที่ได้กล่าวถึงgopkg.in

gopkg.inเป็นบริการที่มี Wrapper (เปลี่ยนเส้นทาง) ที่ให้คุณแสดงเวอร์ชันเป็น URL ของ repo โดยไม่ต้องสร้าง repos จริงๆ เช่นgopkg.in/yaml.v1เทียบกับgopkg.in/yaml.v2แม้ว่าทั้งคู่จะอาศัยอยู่ที่https://github.com/go-yaml/yaml

• gopkg.in/yaml.v1 เปลี่ยนเส้นทางไปที่https://github.com/go-yaml/yaml/tree/v1
• gopkg.in/yaml.v2 เปลี่ยนเส้นทางไปที่https://github.com/go-yaml/yaml/tree/v2

สิ่งนี้ไม่สมบูรณ์แบบหากผู้เขียนไม่ปฏิบัติตามแนวทางปฏิบัติในการกำหนดเวอร์ชันที่เหมาะสม (โดยการเพิ่มหมายเลขเวอร์ชันเมื่อทำลายความเข้ากันได้แบบย้อนกลับ) แต่ใช้ได้กับสาขาและแท็ก

คุณสามารถใช้git checkoutเพื่อรับเวอร์ชันเฉพาะและสร้างโปรแกรมของคุณโดยใช้เวอร์ชันนี้

ตัวอย่าง:

export GOPATH=~/
go get github.com/whateveruser/whateverrepo
cd ~/src/github.com/whateveruser/whateverrepo
git tag -l
# supose tag v0.0.2 is correct version
git checkout tags/v0.0.2
go run whateverpackage/main.go

Glideเป็นการจัดการแพ็คเกจที่ยอดเยี่ยมสำหรับ Go โดยเฉพาะอย่างยิ่งถ้าคุณมาจาก Node's npm หรือ Rust's cargo

มันทำงานใกล้เคียงกับคุณสมบัติผู้ขายใหม่ของ Godep ใน 1.6 แต่เป็นวิธีที่ง่ายกว่า การอ้างอิงและเวอร์ชันของคุณถูก "ล็อก" ภายในไดเร็กทอรี projectdir / vendor ของคุณโดยไม่ต้องอาศัย GOPATH

ติดตั้งด้วยเบียร์ (OS X)

$ brew install glide

เริ่มต้นไฟล์ glide.yaml (คล้ายกับ package.json) นอกจากนี้ยังจับแพ็คเกจที่นำเข้าที่มีอยู่ในโครงการของคุณจาก GOPATH แล้วคัดลอกไปยังผู้จัดจำหน่าย / ไดเรกทอรีของโครงการ

$ glide init

รับแพ็คเกจใหม่

$ glide get vcs/namespace/package

อัปเดตและล็อกเวอร์ชันของแพ็กเกจ สิ่งนี้จะสร้างไฟล์ glide.lock ในไดเร็กทอรีโปรเจ็กต์ของคุณเพื่อล็อกเวอร์ชัน

$ glide up

ฉันลองร่อนและใช้มันอย่างมีความสุขกับโครงการปัจจุบันของฉัน

อัปเดต 18-11-23 : จาก Go 1.11 mod เป็นการทดลองอย่างเป็นทางการ โปรดดูคำตอบของ @krish
อัปเดต 19-01-01 : จาก Go 1.12 mod ยังคงเป็นการทดลองอย่างเป็นทางการ เริ่มต้นใน Go 1.13 โหมดโมดูลจะเป็นค่าเริ่มต้นสำหรับการพัฒนาทั้งหมด
อัปเดต 19-10-17 : จาก Go 1.13 mod เป็นตัวจัดการแพ็คเกจอย่างเป็นทางการ

https://blog.golang.org/using-go-modules

คำตอบเก่า:

คุณสามารถตั้งค่าโดยรุ่นอย่างเป็นทางการDEP

dep ensure --add github.com/gorilla/websocket@1.2.0

จาก Go 1.5 มี"การทดสอบผู้ขาย"ที่ช่วยคุณจัดการการอ้างอิง ตั้งแต่ Go 1.6 นี่ไม่ใช่การทดลองอีกต่อไป เอาใจใส่ยังบางตัวเลือกอื่น ๆ ในวิกิพีเดียไป .

แก้ไข: ตามที่กล่าวไว้ในคำตอบนี้ gopkg.inเป็นตัวเลือกที่ดีสำหรับการตรึง github-depdencies ก่อน 1.5

depเป็นการทดลองอย่างเป็นทางการสำหรับการจัดการการพึ่งพาสำหรับภาษา Go ต้องใช้ Go 1.8 หรือใหม่กว่าในการคอมไพล์

ในการเริ่มจัดการการอ้างอิงโดยใช้depให้รันคำสั่งต่อไปนี้จากไดเร็กทอรีรูทของโปรเจ็กต์ของคุณ:

dep init

หลังจากเรียกใช้ไฟล์สองไฟล์จะถูกสร้างขึ้น: Gopkg.toml("manifest") Gopkg.lockและแพ็คเกจที่จำเป็นจะถูกดาวน์โหลดลงในvendorไดเร็กทอรี

สมมติว่าคุณมีโครงการที่ใช้github.com/gorilla/websocketแพ็คเกจ depจะสร้างไฟล์ต่อไปนี้:

Gopkg.toml

# Gopkg.toml example
#
# Refer to https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md
# for detailed Gopkg.toml documentation.
#
# required = ["github.com/user/thing/cmd/thing"]
# ignored = ["github.com/user/project/pkgX", "bitbucket.org/user/project/pkgA/pkgY"]
#
# [[constraint]]
#   name = "github.com/user/project"
#   version = "1.0.0"
#
# [[constraint]]
#   name = "github.com/user/project2"
#   branch = "dev"
#   source = "github.com/myfork/project2"
#
# [[override]]
#  name = "github.com/x/y"
#  version = "2.4.0"


[[constraint]]
  name = "github.com/gorilla/websocket"
  version = "1.2.0"

Gopkg.lock

# This file is autogenerated, do not edit; changes may be undone by the next 'dep ensure'.


[[projects]]
  name = "github.com/gorilla/websocket"
  packages = ["."]
  revision = "ea4d1f681babbce9545c9c5f3d5194a789c89f5b"
  version = "v1.2.0"

[solve-meta]
  analyzer-name = "dep"
  analyzer-version = 1
  inputs-digest = "941e8dbe52e16e8a7dff4068b7ba53ae69a5748b29fbf2bcb5df3a063ac52261"
  solver-name = "gps-cdcl"
  solver-version = 1

มีคำสั่งที่ช่วยให้คุณอัปเดต / ลบ / ฯลฯ แพ็คเกจโปรดดูข้อมูลเพิ่มเติมเกี่ยวกับrepo github อย่างเป็นทางการของdep(เครื่องมือจัดการการพึ่งพาสำหรับ Go)

ทุกวันนี้คุณสามารถใช้go getมันได้ คุณสามารถดึงการอ้างอิงของคุณโดยแท็กเวอร์ชันสาขาหรือแม้แต่การคอมมิต

go get github.com/someone/some_module@master
go get github.com/someone/some_module@v1.1.0
go get github.com/someone/some_module@commit_hash

รายละเอียดเพิ่มเติมที่นี่ - จะชี้ Go module dependency ใน go.mod ไปยังคอมมิตล่าสุดใน repo ได้อย่างไร?

Go getจะติดตั้งไบนารีเช่นเดียวกับที่ระบุไว้ในเอกสารประกอบ -

Get downloads the packages named by the import paths, along with their dependencies. It then installs the named packages, like 'go install'.

(จากhttps://golang.org/cmd/go/ )

go get คือ Go package manager มันทำงานในลักษณะที่กระจายอำนาจอย่างสมบูรณ์และการค้นพบแพ็คเกจยังคงเป็นไปได้อย่างไรหากไม่มีที่เก็บแพ็กเกจส่วนกลาง

นอกเหนือจากการค้นหาและดาวน์โหลดแพ็กเกจบทบาทสำคัญอื่น ๆ ของตัวจัดการแพ็กเกจคือการจัดการแพ็กเกจเดียวกันหลายเวอร์ชัน Go ใช้แนวทางที่น้อยที่สุดและเป็นประโยชน์ที่สุดสำหรับผู้จัดการแพ็คเกจใด ๆ ไม่มีสิ่งที่เรียกว่าแพ็กเกจ Go หลายเวอร์ชัน

go getเสมอดึงจาก HEAD ของสาขาเริ่มต้นในที่เก็บ เสมอ. สิ่งนี้มีนัยสำคัญสองประการ:

1. ในฐานะผู้เขียนแพ็คเกจคุณต้องยึดมั่นในปรัชญา HEAD ที่มั่นคง สาขาเริ่มต้นของคุณต้องเป็นแพคเกจเวอร์ชันเสถียรและเปิดตัวเสมอ คุณต้องทำงานในสาขาฟีเจอร์และผสานเมื่อพร้อมเผยแพร่เท่านั้น

2. เวอร์ชันหลักใหม่ของแพ็กเกจของคุณต้องมีที่เก็บของตนเอง กล่าวง่ายๆว่าแต่ละเวอร์ชันหลักของแพ็กเกจของคุณ (ตามการกำหนดเวอร์ชันเชิงความหมาย) จะมีที่เก็บของตัวเองดังนั้นจึงมีเส้นทางการนำเข้าของตัวเอง

   เช่น github.com/jpoehls/gophermail-v1 และ github.com/jpoehls/gophermail-v2

ในฐานะที่มีคนสร้างแอปพลิเคชันใน Go ปรัชญาข้างต้นไม่มีข้อเสีย ทุกเส้นทางการนำเข้าเป็น API ที่เสถียร ไม่มีหมายเลขเวอร์ชันที่ต้องกังวล สุดยอด!

สำหรับรายละเอียดเพิ่มเติม: http://zduck.com/2014/go-and-package-versioning/

วิธีการที่ฉันได้พบที่สามารถทำงานได้เป็นระบบ submodule คอมไพล์ของ การใช้ที่คุณสามารถใช้โมดูลย่อยในโค้ดเวอร์ชันที่กำหนดและการอัปเกรด / ดาวน์เกรดเป็นสิ่งที่ชัดเจนและบันทึกไว้ - อย่าจับจด

โครงสร้างโฟลเดอร์ที่ฉันใช้คือ:

+ myproject
++ src
+++ myproject
+++ github.com
++++ submoduled_project of some kind.

ที่ได้ผลสำหรับฉัน

GO111MODULE=on go get -u github.com/segmentio/aws-okta@v0.22.1

มีคำสั่งgo edit -replaceเพื่อต่อท้ายคอมมิตเฉพาะ (แม้จะมาจากที่เก็บอื่นที่แยกออกจากกัน) ที่ด้านบนของเวอร์ชันปัจจุบันของแพ็กเกจ สิ่งดีๆเกี่ยวกับตัวเลือกนี้เป็นคือการที่คุณไม่จำเป็นต้องรู้แน่นอนรุ่นหลอกก่อนเพียงกระทำ ID

ตัวอย่างเช่นฉันใช้แพ็คเกจเวอร์ชันเสถียร "github.com/onsi/ginkgo v1.8.0"

ตอนนี้ฉันต้องการ - โดยไม่ต้องแก้ไขบรรทัดของแพ็คเกจที่จำเป็นใน go.mod - เพื่อต่อท้ายแพทช์จากส้อมของฉันที่ด้านบนของเวอร์ชันแปะก๊วย:

$ GO111MODULE="on"  go mod edit -replace=github.com/onsi/ginkgo=github.com/manosnoam/ginkgo@d6423c2

หลังจากสร้างหรือทดสอบโมดูลครั้งแรก GO จะพยายามดึงเวอร์ชันใหม่จากนั้นสร้างบรรทัด "แทนที่" ด้วยเวอร์ชันหลอกที่ถูกต้อง ตัวอย่างเช่นในกรณีของฉันมันจะเพิ่มที่ด้านล่างของ go.mod:

แทนที่ github.com/onsi/ginkgo => github.com/manosnoam/ginkgo v0.0.0-20190902135631-1995eead7451

เอกสารสรุปเล็กน้อยเกี่ยวกับแบบสอบถามโมดูล

ในการตรวจสอบเวอร์ชันที่มีอยู่ทั้งหมด: เช่น go list -m -versions github.com/gorilla/mux

1. เวอร์ชันเฉพาะ @ v1.2.8
2. เฉพาะการกระทำ @ c783230
3. เฉพาะการกระทำ @master
4. คำนำหน้าเวอร์ชัน @ v2.0
5. เปรียบเทียบ @> = 2.1.5
6. ล่าสุด @latest

เช่น go get github.com/gorilla/mux@v1.7.4