Go package paths commonly include a domain so that tools such as 'go get' are able to automatically find and download the source code. Currently all of Decred's Go projects use package paths beginning with github.com/decred/. This means that when performing an operation such as go get github.com/decred/dcrd (ignoring for now this is not the correct way to build dcrd), go will query github.com directly for the source code.
Go has a feature to use custom package paths with any domain while maintaining the source code repository elsewhere. This would allow us to modify all package paths to begin with decred.org while still using Github for the issue tracker, pull requests, and hosting the git repository.
The decred.org web server has already been updated to support this feature. For example:
PS C:\Users\jrick> go get -v decred.org/dcrd
Fetching https://decred.org/dcrd?go-get=1
Parsing meta tags from https://decred.org/dcrd?go-get=1 (status code 200)
get "decred.org/dcrd": found meta tag get.metaImport{Prefix:"decred.org/dcrd", VCS:"git", RepoRoot:"https://github.com/decred/dcrd.git"} at https://decred.org/dcrd?go-get=1
decred.org/dcrd (download)
decred.org/dcrd
# decred.org/dcrd
go\src\decred.org\dcrd\rpcserver.go:3182:18: chain.LocateHeaders undefined (type *blockchain.BlockChain has no field or method LocateHeaders)
go\src\decred.org\dcrd\server.go:348:14: addrManager.SetServices undefined (type *addrmgr.AddrManager has no field or method SetServices)
go\src\decred.org\dcrd\server.go:734:19: chain.LocateBlocks undefined (type *blockchain.BlockChain has no field or method LocateBlocks)
go\src\decred.org\dcrd\server.go:775:18: chain.LocateHeaders undefined (type *blockchain.BlockChain has no field or method LocateHeaders)
go\src\decred.org\dcrd\server.go:1647:13: cannot use sp.OnVersion (type func(*peer.Peer, *wire.MsgVersion) *wire.MsgReject) as type func(*peer.Peer, *wire.MsgVersion) in field value
The project does not compile using this command because this is not the correct way to build dcrd, but it will be in the future as vgo is integrated into the official toolchain. What is important is that decred.org was queried for the source code location and redirected to github.com for the actual location of the git repo to use.
The primary advantage of this change would be the ability to move away from Github or any other code hosting provider in the future without the churn of renaming all packages again, while still using Github in the short (or long) term if there was no reason to switch. This is our exit strategy so to speak, in case we needed to move away from Github at a moment's notice without disrupting the project too significantly.
If packages are renamed, we should also consider annotating all package statements with the canonical package path. This prevents the same code from being referenced by two different names, which are in fact two distinct and incompatible packages according to the Go toolchain.
Go package paths commonly include a domain so that tools such as 'go get' are able to automatically find and download the source code. Currently all of Decred's Go projects use package paths beginning with
github.com/decred/. This means that when performing an operation such asgo get github.com/decred/dcrd(ignoring for now this is not the correct way to build dcrd),gowill query github.com directly for the source code.Go has a feature to use custom package paths with any domain while maintaining the source code repository elsewhere. This would allow us to modify all package paths to begin with decred.org while still using Github for the issue tracker, pull requests, and hosting the git repository.
The decred.org web server has already been updated to support this feature. For example:
The project does not compile using this command because this is not the correct way to build dcrd, but it will be in the future as
vgois integrated into the official toolchain. What is important is that decred.org was queried for the source code location and redirected to github.com for the actual location of the git repo to use.The primary advantage of this change would be the ability to move away from Github or any other code hosting provider in the future without the churn of renaming all packages again, while still using Github in the short (or long) term if there was no reason to switch. This is our exit strategy so to speak, in case we needed to move away from Github at a moment's notice without disrupting the project too significantly.
If packages are renamed, we should also consider annotating all
packagestatements with the canonical package path. This prevents the same code from being referenced by two different names, which are in fact two distinct and incompatible packages according to the Go toolchain.