Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Packages & Modules - GopherCon Poland 2019

Packages & Modules - GopherCon Poland 2019

Oleg Kovalov

June 27, 2019
Tweet

More Decks by Oleg Kovalov

Other Decks in Programming

Transcript

  1. Packages &
    Modules
    GopherCon Poland, Gdansk, June 27 2019
    Oleg Kovalov
    Allegro
    https://olegk.dev

    View Slide

  2. Agenda
    Packages & Modules

    View Slide

  3. 3
    - About me
    - Packages
    - Modules
    - Summary
    - Q&A

    View Slide

  4. 4
    - About me
    - Packages
    - Modules
    - Summary
    - Q&A Interfaces

    View Slide

  5. About me
    Packages & Modules

    View Slide

  6. 6

    View Slide

  7. - Gopher for ~4 years
    7

    View Slide

  8. 8
    - Gopher for ~4 years
    - Open-source contributor
    - Go-critic - static analysis tool
    - Go-advice - list of Go tips @ GoGoConf 2018

    View Slide

  9. 9
    - Gopher for ~4 years
    - Open-source contributor
    - Go-critic - static analysis tool
    - Go-advice - list of Go tips @ GoGoConf 2018
    - Engineer at allegro.pl core team

    View Slide

  10. - Gopher for ~4 years
    - Open-source contributor
    - Go-critic - static analysis tool
    - Go-advice - list of Go tips @ GoGoConf 2018
    - Engineer at allegro.pl core team
    Website: https://olegk.dev
    Twitter: @oleg_kovalov
    Github: @cristaloleg
    10
    Twitter & slides

    View Slide

  11. Packages
    Packages & Modules

    View Slide

  12. 12

    View Slide

  13. - Short and clear
    13

    View Slide

  14. - Short and clear
    - May be abbreviated when the abbreviation is familiar
    14

    View Slide

  15. - Short and clear
    - May be abbreviated when the abbreviation is familiar
    - Abbrv name is easy to understand
    15

    View Slide

  16. - Short and clear
    - May be abbreviated when the abbreviation is familiar
    - Abbrv name is easy to understand
    See standard packages for good examples
    - io (input and output)
    16

    View Slide

  17. - Short and clear
    - May be abbreviated when the abbreviation is familiar
    - Abbrv name is easy to understand
    See standard packages for good examples
    - io (input and output)
    - strconv (string conversion)
    17

    View Slide

  18. - Short and clear
    - May be abbreviated when the abbreviation is familiar
    - Abbrv name is easy to understand
    See standard packages for good examples
    - io (input and output)
    - strconv (string conversion)
    - syscall (system call)
    18

    View Slide

  19. 19

    View Slide

  20. - If abbreviating is unclear
    20

    View Slide

  21. - If abbreviating is unclear
    - If name is ambiguous
    21

    View Slide

  22. - If abbreviating is unclear
    - If name is ambiguous
    - snake_case or camelCase
    22

    View Slide

  23. - If abbreviating is unclear
    - If name is ambiguous
    - snake_case or camelCase
    - psdb (Postgres? Parallel search?)
    23

    View Slide

  24. - If abbreviating is unclear
    - If name is ambiguous
    - snake_case or camelCase
    - psdb (Postgres? Parallel search?)
    - srv (service? server? surviving?)
    24

    View Slide

  25. - If abbreviating is unclear
    - If name is ambiguous
    - snake_case or camelCase
    - psdb (Postgres? Parallel search?)
    - srv (service? server? surviving?)
    - buf (buffer? buffer what? WoW buff?)
    25

    View Slide

  26. - Avoid giving a package a name that is commonly used in client code
    26

    View Slide

  27. - Avoid giving a package a name that is commonly used in client code
    - buf is a good variable name for a buffer
    - the buffered I/O package is called bufio (buffer + io)
    27

    View Slide

  28. - Avoid giving a package a name that is commonly used in client code
    - buf is a good variable name for a buffer
    - the buffered I/O package is called bufio (buffer + io)
    - client is a good name for...client
    - but not a package name
    28

    View Slide

  29. - Avoid giving a package a name that is commonly used in client code
    - buf is a good variable name for a buffer
    - the buffered I/O package is called bufio (buffer + io)
    - client is a good name for...client
    - but not a package name
    - imagine a replacement for it
    29
    c ? clnt ? cli ?
    clientHTTP ?

    View Slide

  30. 30

    View Slide

  31. These std packages are a good names thiefs:
    - path
    - path/filepath
    - net/url
    And you cannot use your variable url easily, oh :(
    31

    View Slide

  32. 32
    These std packages are a good names thiefs:
    - path
    - path/filepath
    - net/url
    And you cannot use your variable url easily, oh :(
    But there are good examples:
    - strings
    - bytes
    - net/urls instead of net/url looks good enough

    View Slide

  33. Most of the projects in Go are flat and this is fine
    33

    View Slide

  34. Most of the projects in Go are flat and this is fine
    - Try to keep it clean
    github.com/foo/bar/pl/goava/src/main/code/go/validation
    34

    View Slide

  35. Most of the projects in Go are flat and this is fine
    - Try to keep it clean
    github.com/foo/bar/pl/goava/src/main/code/go/validation
    - Avoid do src/ or pkg/ (in most cases)
    gitlab.com/foo/bar/pkg/process
    35

    View Slide

  36. Write shy code - modules that don’t reveal anything unnecessary to other
    modules and that don’t rely on other modules' implementations.
    --- Dave Thomas (with Andy Hunt, he co-authored The Pragmatic Programmer)
    36

    View Slide

  37. Write shy code - modules that don’t reveal anything unnecessary to other
    modules and that don’t rely on other modules' implementations.
    --- Dave Thomas (with Andy Hunt, he co-authored The Pragmatic Programmer)
    And shy also means: 1 package = 1 thing
    37

    View Slide

  38. 38

    View Slide

  39. 39

    View Slide

  40. 40

    View Slide

  41. 41

    View Slide

  42. 42

    View Slide

  43. 43

    View Slide

  44. 44

    View Slide

  45. - Organize by functional responsibility
    45

    View Slide

  46. - Organize by functional responsibility
    - Don’t put all the type into models package
    46

    View Slide

  47. 47
    - Organize by functional responsibility
    - Don’t put all the type into models package
    - Keeping them in one gives nothing

    View Slide

  48. 48
    - Organize by functional responsibility
    - Don’t put all the type into models package
    - Keeping them in one gives nothing
    - In the end this will be a spaghetti code

    View Slide

  49. 49
    - Organize by functional responsibility
    - Don’t put all the type into models package
    - Keeping them in one gives nothing
    - In the end this will be a spaghetti code
    - (The same applies to the interfaces, implementations and so on)

    View Slide

  50. 50
    .
    ├── app
    ├── cmd
    │ └──
    ├── blog
    ├── comment
    ├── mock
    ├── pkg
    │ ├── superpay
    │ └── validation
    ├── store
    │ └── postgres
    ├── user
    └── .go

    View Slide

  51. 51
    .
    ├── app
    ├── cmd
    │ └──
    ├── blog
    ├── comment
    ├── mock
    ├── pkg
    │ ├── superpay
    │ └── validation
    ├── store
    │ └── postgres
    ├── user
    └── .go

    View Slide

  52. 52
    .
    ├── app
    ├── cmd
    │ └──
    ├── blog
    ├── comment
    ├── mock
    ├── pkg
    │ ├── superpay
    │ └── validation
    ├── store
    │ └── postgres
    ├── user
    └── .go

    View Slide

  53. 53
    mock.NewBlog(...)
    .
    ├── app
    ├── cmd
    │ └──
    ├── blog
    ├── comment
    ├── mock
    ├── pkg
    │ ├── superpay
    │ └── validation
    ├── store
    │ └── postgres
    ├── user
    └── .go

    View Slide

  54. 54
    .
    ├── app
    ├── cmd
    │ └──
    ├── blog
    ├── comment
    ├── mock
    ├── pkg
    │ ├── superpay
    │ └── validation
    ├── store
    │ └── postgres
    ├── user
    └── .go

    View Slide

  55. 55
    .
    ├── app
    ├── cmd
    │ └──
    ├── blog
    ├── comment
    ├── mock
    ├── pkg
    │ ├── superpay
    │ └── validation
    ├── store
    │ └── postgres
    ├── user
    └── .go

    View Slide

  56. 56
    .
    ├── app
    ├── cmd
    │ └──
    ├── blog
    ├── comment
    ├── mock
    ├── pkg
    │ ├── superpay
    │ └── validation
    ├── store
    │ └── postgres
    ├── user
    └── .go

    View Slide

  57. pkg, internal,
    misc or util
    Whatever works for
    your team and you
    57
    .
    ├── app
    ├── cmd
    │ └──
    ├── blog
    ├── comment
    ├── mock
    ├── pkg
    │ ├── superpay
    │ └── validation
    ├── store
    │ └── postgres
    ├── user
    └── .go

    View Slide

  58. 58
    .
    ├── app
    ├── cmd
    │ └──
    ├── blog
    ├── comment
    ├── mock
    ├── pkg
    │ ├── superpay
    │ └── validation
    ├── store
    │ └── postgres
    ├── user
    └── .go

    View Slide

  59. 59

    View Slide

  60. - util.URLError
    60

    View Slide

  61. - util.URLError
    - common.SanitizeMessage
    61

    View Slide

  62. - util.URLError
    - common.SanitizeMessage
    - base.EnsureAbsolutePath
    62

    View Slide

  63. - util.URLError
    - common.SanitizeMessage
    - base.EnsureAbsolutePath
    - helpers.IsEmail
    63

    View Slide

  64. - util.URLError
    - common.SanitizeMessage
    - base.EnsureAbsolutePath
    - helpers.IsEmail
    64
    These packages say nothing!

    View Slide

  65. 65
    - util.URLError
    - common.SanitizeMessage
    - base.EnsureAbsolutePath
    - helpers.IsEmail
    type URLError = app.URLError
    These packages say nothing!

    View Slide

  66. 66
    - util.URLError
    - common.SanitizeMessage
    - base.EnsureAbsolutePath
    - helpers.IsEmail
    type URLError = app.URLError
    var isEmail = validation.IsEmail
    These packages say nothing!

    View Slide

  67. - Use multiple files
    - Do not separate structs and their methods (not a C/C++)
    - It’s okay to store few structs in one file (it’s not Java after all)
    - And keep test files next to code
    store
    ├── postgres
    │ ├── postgres.go
    │ ├── user.go
    │ └── user_test.go
    └── redis
    ├── redis.go
    └── comments.go
    67

    View Slide

  68. - Use multiple files
    - Do not separate structs and their methods (not a C/C++)
    - It’s okay to store few structs in one file (it’s not Java after all)
    - And keep test files next to code
    store
    ├── postgres
    │ ├── postgres.go
    │ ├── user.go
    │ └── user_test.go
    └── redis
    ├── redis.go
    └── comments.go // type Comment and Comment.HasImage method
    68

    View Slide

  69. - Use multiple files
    - Do not separate structs and their methods (not a C/C++)
    - It’s okay to store few structs in one file (it’s not Java after all)
    - And keep test files next to code
    store
    ├── postgres
    │ ├── postgres.go
    │ ├── user.go // type User and type Credentials
    │ └── user_test.go
    └── redis
    ├── redis.go
    └── comments.go
    69

    View Slide

  70. - Use multiple files
    - Do not separate structs and their methods (not a C/C++)
    - It’s okay to store few structs in one file (it’s not Java after all)
    - And keep test files next to code
    store
    ├── postgres
    │ ├── postgres.go
    │ ├── user.go
    │ └── user_test.go
    └── redis
    ├── redis.go
    └── comments.go
    70

    View Slide

  71. 71
    postgres
    ├── postgres.go
    ├── user.go
    ├── stats.go
    └── user_test.go
    redis
    ├── redis.go
    ├── cache.go
    └── comments.go

    View Slide

  72. 72
    postgres
    ├── postgres.go
    ├── user.go
    ├── stats.go
    └── user_test.go
    redis
    ├── redis.go
    ├── cache.go
    └── comments.go
    cache
    ├── redis
    │ └── redis.go
    store
    ├── postgres
    │ ├── postgres.go
    │ ├── user.go
    │ └── user_test.go
    └── redis
    ├── redis.go
    └── comments.go

    View Slide

  73. 73

    View Slide

  74. - Main packages are not importable
    74

    View Slide

  75. - Main packages are not importable
    - Don’t export from main, it’s useless
    75

    View Slide

  76. - Main packages are not importable
    - Don’t export from main, it’s useless
    - main package is hard to test (see above)
    76

    View Slide

  77. 77
    package main
    func init() {
    config.Load()
    }

    View Slide

  78. 78
    package main
    func init() {
    config.Load()
    }
    func main() {
    os.Exit(realMain())
    }
    func realMain() int {
    log.SetOutput(ioutil.Discard)
    // ...
    }

    View Slide

  79. package main
    func main() {
    log.Fatal(app.Run())
    }
    79

    View Slide

  80. 80

    View Slide

  81. - 1 init() per package (pretty please)
    81

    View Slide

  82. - 1 init() per package (pretty please)
    - Do not depend on init’s call order
    82

    View Slide

  83. - 1 init() per package (pretty please)
    - Do not depend on init’s call order
    - No heavy tasks
    83

    View Slide

  84. - 1 init() per package (pretty please)
    - Do not depend on init’s call order
    - No heavy tasks
    - Preferably no I/O, especially blocking
    84

    View Slide

  85. - 1 init() per package (pretty please)
    - Do not depend on init’s call order
    - No heavy tasks
    - Preferably no I/O, especially blocking
    - Better to not have it at all
    85

    View Slide

  86. # Python is quite flexible
    #
    try:
    import foo
    except:
    print(‘good try lol’)
    86

    View Slide

  87. # Python is quite flexible
    #
    try:
    import foo
    except:
    print(‘good try lol’)
    // Go isn’t so…
    //
    package foo
    func init() {
    iCanPanicAndYouCanDoNothing()
    }
    87

    View Slide

  88. // but wait, it can be flexible...
    package foo
    func Init() {
    iCanPanicButOoooohhYouCanCatchMe()
    }
    88

    View Slide

  89. // but wait, it can be flexible...
    package foo
    func Init() {
    iCanPanicButOoooohhYouCanCatchMe()
    }
    -----------
    package bar
    func ... {
    defer func() {
    if r := recover(); r != nil {
    // process a panic
    }
    }()
    foo.Init()
    } 89

    View Slide

  90. package foo
    func (s *Service) Process() {
    // let’s start a sweet goroutine
    go func() {
    iCanPanicAndYouCanDoNothing()
    }()
    }
    90

    View Slide

  91. package foo
    func (s *Service) Process() {
    // let’s start a sweet goroutine
    go func() {
    iCanPanicAndYouCanDoNothing()
    }()
    }
    -----------
    package bar
    func ... {
    // but internal goroutine
    // isn’t accessible here :(
    s.Process()
    }
    91

    View Slide

  92. package foo
    func (s *Service) Process() {
    go func() {
    defer func() {
    // recovery process
    }()
    iCanPanicAndAuthorWillRecover()
    }()
    }
    92

    View Slide

  93. package foo
    func (s *Service) Process() {
    iCanPanicButItDoesntMatter()
    }
    93

    View Slide

  94. package foo
    func (s *Service) Process() {
    iCanPanicButItDoesntMatter()
    }
    -----------
    package bar
    func ... {
    go func() {
    defer func() {
    // user defined recovery process
    }()
    s.Process()
    }()
    }
    94

    View Slide

  95. 95

    View Slide

  96. - Exported package variable is mutable by everyone
    96

    View Slide

  97. - Exported package variable is mutable by everyone
    - You have no power to control other packages
    97

    View Slide

  98. - Exported package variable is mutable by everyone
    - You have no power to control other packages
    - Tight coupling makes code less flexible
    98

    View Slide

  99. - Exported package variable is mutable by everyone
    - You have no power to control other packages
    - Tight coupling makes code less flexible
    - You cannot mock a package!
    99

    View Slide

  100. - Exported package variable is mutable by everyone
    - You have no power to control other packages
    - Tight coupling makes code less flexible
    - You cannot mock a package!
    - Logger, metrics? - mmmmaybe
    100

    View Slide

  101. - Exported package variable is mutable by everyone
    - You have no power to control other packages
    - Tight coupling makes code less flexible
    - You cannot mock a package!
    - Logger, metrics? - mmmmaybe
    - Config, flags? - better no
    101

    View Slide

  102. - Exported package variable is mutable by everyone
    - You have no power to control other packages
    - Tight coupling makes code less flexible
    - You cannot mock a package!
    - Logger, metrics? - mmmmaybe
    - Config, flags? - better no
    - DB driver? - NONONO
    102

    View Slide

  103. - Exported package variable is mutable by everyone
    - You have no power to control other packages
    - Tight coupling makes code less flexible
    - You cannot mock a package!
    - Logger, metrics? - mmmmaybe
    - Config, flags? - better no
    - DB driver? - NONONO
    103
    by the way unexported variables
    are also bad :(

    View Slide

  104. 104

    View Slide

  105. - Should be simply a container for consts, types, funcs
    105

    View Slide

  106. - Should be simply a container for consts, types, funcs
    - Zero variables is brilliant (both exported and unexported)
    106

    View Slide

  107. - Should be simply a container for consts, types, funcs
    - Zero variables is brilliant (both exported and unexported)
    - Documentation and tests :)
    107

    View Slide

  108. 108

    View Slide

  109. - log.Printf
    A safe action, might be noisy, but harmless
    109

    View Slide

  110. - log.Printf
    A safe action, might be noisy, but harmless
    - log.Panicf
    Not idiomatic, but in an edge case might be fine
    110

    View Slide

  111. 111
    - log.Printf
    A safe action, might be noisy, but harmless
    - log.Panicf
    Not idiomatic, but in an edge case might be fine
    - log.Fatalf
    Evil has no boundaries, omit it, no one can survive os.Exit(1) (even defer)

    View Slide

  112. 112

    View Slide

  113. - doc.go is a README of your package
    113

    View Slide

  114. - doc.go is a README of your package
    - Run godoc locally to see how it looks
    114

    View Slide

  115. 115
    - doc.go is a README of your package
    - Run godoc locally to see how it looks
    - Also add package documentation
    // Package bytes implements functions for the manipulation of byte slices.
    // It is analogous to the facilities of the strings package.
    package bytes

    View Slide

  116. Interfaces
    Packages & Modules

    View Slide

  117. 117

    View Slide

  118. Be conservative in what you send, be liberal in what you accept
    (с) Postel’s Law, Wikipedia
    118

    View Slide

  119. Be conservative in what you send, be liberal in what you accept
    (с) Postel’s Law, Wikipedia
    TCP architecture:
    119

    View Slide

  120. Be conservative in what you send, be liberal in what you accept
    (с) Postel’s Law, Wikipedia
    TCP architecture:
    - We don’t care about how packets go through network
    120

    View Slide

  121. Be conservative in what you send, be liberal in what you accept
    (с) Postel’s Law, Wikipedia
    TCP architecture:
    - We don’t care about how packets go through network
    - but we expect them in a well defined order to process
    121

    View Slide

  122. func FetchUsers(db Store) ([]*User, error) { ... }
    122

    View Slide

  123. func FetchUsers(db Store) ([]*User, error) { ... }
    - We don’t care what is inside: Postgres, Redis, plain file or a mock
    123

    View Slide

  124. func FetchUsers(db Store) ([]*User, error) { ... }
    - We don’t care what is inside: Postgres, Redis, plain file or a mock
    - Until it has desired API for us
    124

    View Slide

  125. func FetchUsers(db Store) ([]*User, error) { ... }
    - We don’t care what is inside: Postgres, Redis, plain file or a mock
    - Until it has desired API for us
    - But we know for sure that we need a specific struct User
    125

    View Slide

  126. func FetchUsers(db Store) ([]*User, error) { ... }
    - We don’t care what is inside: Postgres, Redis, plain file or a mock
    - Until it has desired API for us
    - But we know for sure that we need a specific struct User
    Tip: return error as interface, not as a struct
    126

    View Slide

  127. 127

    View Slide

  128. - There is the “Java-style” interface declaration
    128

    View Slide

  129. - There is the “Java-style” interface declaration
    - Define an interface
    129

    View Slide

  130. - There is the “Java-style” interface declaration
    - Define an interface
    - Create a type that implements it
    130

    View Slide

  131. 131
    - There is the “Java-style” interface declaration
    - Define an interface
    - Create a type that implements it
    - Often you have one interface and one implementation

    View Slide

  132. - There is the “Java-style” interface declaration
    - Define an interface
    - Create a type that implements it
    - Often you have one interface and one implementation
    That’s not a “Go style”
    ʕ◔ϖ◔ʔ
    132

    View Slide

  133. 133

    View Slide

  134. - Go interfaces are in the package that uses it
    134

    View Slide

  135. - Go interfaces are in the package that uses it
    - And this makes Go code easy to extend
    135

    View Slide

  136. Modules
    Packages & Modules

    View Slide

  137. 137
    time
    Image credit: ©Istockphoto/JamesBrey

    View Slide

  138. 138

    View Slide

  139. - GOPATH
    139

    View Slide

  140. - GOPATH
    - godep
    140

    View Slide

  141. - GOPATH
    - godep
    - gopkg.in
    141

    View Slide

  142. - GOPATH
    - godep
    - gopkg.in
    - glide
    142

    View Slide

  143. - GOPATH
    - godep
    - gopkg.in
    - glide
    - vendor dir
    143

    View Slide

  144. - GOPATH
    - godep
    - gopkg.in
    - glide
    - vendor dir
    - dep
    144

    View Slide

  145. 145

    View Slide

  146. 146
    - Modules
    - Semantic versioning
    - Import compatibility rule
    - go.mod

    View Slide

  147. - A module is a collection of Go packages that are versioned as a single unit
    147

    View Slide

  148. - A module is a collection of Go packages that are versioned as a single unit
    - A module is a tree/directory of Go source files with a go.mod file in the root
    ├── cmd
    │ └── main.go
    ├── consum
    │ ├── consum.go
    │ └── handlers.go
    ├── produce
    │ ├── handlers.go
    │ ├── handlers_test.go
    │ └── processing.go
    ├── go.mod
    └── go.sum
    148

    View Slide

  149. - A module is a collection of Go packages that are versioned as a single unit
    - A module is a tree/directory of Go source files with a go.mod file in the root
    ├── cmd
    │ └── main.go
    ├── consum
    │ ├── consum.go
    │ └── handlers.go
    ├── produce
    │ ├── handlers.go
    │ ├── handlers_test.go
    │ └── processing.go
    ├── go.mod
    └── go.sum
    149
    Can leave
    outside of
    GOPATH

    View Slide

  150. 150

    View Slide

  151. 151
    - If an old and a new package have the same import path
    - the new package must be backwards-compatible with the old package

    View Slide

  152. 152
    - If an old and a new package have the same import path
    - the new package must be backwards-compatible with the old package
    import (
    "github.com/golang/hello/hey" // v0 or v1
    "github.com/golang/hello/v2/hey"
    )

    View Slide

  153. 153
    - auto(default)
    - on
    - off
    $ export GO111MODULE=on
    $ go build ./...

    View Slide

  154. 154
    Usage:
    go mod [arguments]
    The commands are:
    download download modules to local cache
    edit edit go.mod from tools or scripts
    graph print module requirement graph
    init initialize new module in current directory
    tidy add missing and remove unused modules
    vendor make vendored copy of dependencies
    verify verify dependencies have expected content
    why explain why packages or modules are needed

    View Slide

  155. $ mkdir /mygo/hello
    $ cd /mygo/hello
    155

    View Slide

  156. $ mkdir /mygo/hello
    $ cd /mygo/hello
    $ go mod init github.com/golang/hello
    go: creating new go.mod: module github.com/golang/hello
    $ ls
    go.mod
    156

    View Slide

  157. 157
    $ mkdir /mygo/hello
    $ cd /mygo/hello
    $ go mod init github.com/golang/hello
    go: creating new go.mod: module github.com/golang/hello
    $ ls
    go.mod
    $ cat go.mod
    module github.com/golang/hello

    View Slide

  158. $ git clone https://github.com/go-gitea/gitea
    Cloning into gitea...
    $ cd gitea
    158

    View Slide

  159. $ git clone https://github.com/go-gitea/gitea
    Cloning into gitea...
    $ cd gitea
    $ go mod init
    go: creating new go.mod: module github.com/go-gitea/gitea
    go: copying requirements from Gopkg.lock
    159

    View Slide

  160. 160
    $ git clone https://github.com/go-gitea/gitea
    Cloning into gitea...
    $ cd gitea
    $ go mod init
    go: creating new go.mod: module github.com/go-gitea/gitea
    go: copying requirements from Gopkg.lock
    $ go mod tidy
    go: extracting github.com/PuerkitoBio/goquery v1.5.0
    go: extracting github.com/blevesearch/bleve v0.7.0
    go: finding github.com/google/pprof v0.0.0-20181206194817-3ea8567a2e57
    go: finding golang.org/x/lint v0.0.0-20190227174305-5b3e6a55c961
    go: finding golang.org/x/time v0.0.0-20181108054448-85acf8d2951c
    go: downloading github.com/facebookgo/grace
    v0.0.0-20180706040059-75cf19382434
    ...

    View Slide

  161. module github.com/hashicorp/consul
    go 1.12
    ...
    161

    View Slide

  162. module github.com/hashicorp/consul
    go 1.12
    require (
    github.com/NYTimes/gziphandler v1.0.1
    <...>/datadog-go v0.0.0-20160329135253-cc2f4770f4d6 // indirect
    github.com/go-redis/redis v6.15.2+incompatible
    ...
    )
    162

    View Slide

  163. module github.com/hashicorp/consul
    go 1.12
    require (
    github.com/NYTimes/gziphandler v1.0.1
    <...>/datadog-go v0.0.0-20160329135253-cc2f4770f4d6 // indirect
    github.com/go-redis/redis v6.15.2+incompatible
    ...
    )
    163

    View Slide

  164. 164
    module github.com/hashicorp/consul
    go 1.12
    require (
    github.com/NYTimes/gziphandler v1.0.1
    <...>/datadog-go v0.0.0-20160329135253-cc2f4770f4d6 // indirect
    github.com/go-redis/redis v6.15.2+incompatible
    ...
    )
    replace github.com/hashicorp/consul/api => ./api // can be fork or branch

    View Slide

  165. 165
    module github.com/hashicorp/consul
    go 1.12
    require (
    github.com/NYTimes/gziphandler v1.0.1
    <...>/datadog-go v0.0.0-20160329135253-cc2f4770f4d6 // indirect
    github.com/go-redis/redis v6.15.2+incompatible
    ...
    )
    replace github.com/hashicorp/consul/api => ./api // can be fork or branch
    exclude github.com/not-a-hacker/supergeil v1270.0.1

    View Slide

  166. 166

    View Slide

  167. 167

    View Slide

  168. 168
    cloud.google.com/go v0.26.0 h1:e0WKqKTd5BnrG8aKH3J3h+QvEIQtSUcf2n5UZ5ZgLtQ=
    cloud.google.com/go v0.26.0/go.mod
    h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw=
    github.com/Azure/azure-sdk-for-go v16.0.0+incompatible
    h1:gr1qKY/Ll72VjFTZmaBwRK1yQHAxCnV25ekOKroc9ws=
    github.com/Azure/azure-sdk-for-go v16.0.0+incompatible/go.mod
    h1:9XXNKU+eRnpl9moKnB4QOLf1HestfXbmab5FXxiDBjc=
    // you might want to use go mod verify

    View Slide

  169. 169

    View Slide

  170. # same (@latest is default for 'go get')
    $ go get github.com/gorilla/mux@latest
    170

    View Slide

  171. # same (@latest is default for 'go get')
    $ go get github.com/gorilla/mux@latest
    # records v1.6.2
    $ go get github.com/gorilla/[email protected]
    $ go get github.com/gorilla/mux@e3702bed2
    171

    View Slide

  172. # same (@latest is default for 'go get')
    $ go get github.com/gorilla/mux@latest
    # records v1.6.2
    $ go get github.com/gorilla/[email protected]
    $ go get github.com/gorilla/mux@e3702bed2
    # records v0.0.0-20180517173623-c85619274f5d
    $ go get github.com/gorilla/mux@c856192
    172

    View Slide

  173. 173
    # same (@latest is default for 'go get')
    $ go get github.com/gorilla/mux@latest
    # records v1.6.2
    $ go get github.com/gorilla/[email protected]
    $ go get github.com/gorilla/mux@e3702bed2
    # records v0.0.0-20180517173623-c85619274f5d
    $ go get github.com/gorilla/mux@c856192
    # records current meaning of master
    $ go get github.com/gorilla/mux@master

    View Slide

  174. # go and get a repo
    $ go get github.com/go-gitea/gitea
    $ cd ~/go/src/github.com/go-gitea/gitea
    174

    View Slide

  175. # go and get a repo
    $ go get github.com/go-gitea/gitea
    $ cd ~/go/src/github.com/go-gitea/gitea
    # set a env var and check why do we use this dependency
    $ export GO111MODULE=on
    $ go mod why github.com/RoaringBitmap/roaring
    175

    View Slide

  176. 176
    # go and get a repo
    $ go get github.com/go-gitea/gitea
    $ cd ~/go/src/github.com/go-gitea/gitea
    # set a env var and check why do we use this dependency
    $ export GO111MODULE=on
    $ go mod why github.com/RoaringBitmap/roaring
    # github.com/RoaringBitmap/roaring
    code.gitea.io/gitea/modules/indexer
    github.com/blevesearch/bleve
    github.com/blevesearch/bleve/index/scorch
    github.com/RoaringBitmap/roaring

    View Slide

  177. # install
    $ go get github.com/rogpeppe/gohack
    177

    View Slide

  178. # install
    $ go get github.com/rogpeppe/gohack
    $ gohack get example.com/foo/bar
    # will clone repo into $HOME/gohack/example.com/foo/bar
    # will add replace statement
    $ cat go.mod
    replace example.com/foo/bar => /home/rog/gohack/example.com/foo/bar
    178

    View Slide

  179. 179
    # install
    $ go get github.com/rogpeppe/gohack
    $ gohack get example.com/foo/bar
    # will clone repo into $HOME/gohack/example.com/foo/bar
    # will add replace statement
    $ cat go.mod
    replace example.com/foo/bar => /home/rog/gohack/example.com/foo/bar
    # to remove specific replace:
    $ gohack undo example.com/foo/bar
    # to remove all replaces:
    $ gohack undo

    View Slide

  180. 180

    View Slide

  181. 181
    - https://proxy.golang.org
    - https://github.com/gomods/athens
    - https://github.com/goproxy/goproxy
    - export GOPROXY=my.proxy.com
    - go get github.com/foo/bar

    View Slide

  182. 182

    View Slide

  183. *Remark
    Packages & Modules

    View Slide

  184. 184

    View Slide

  185. - Usability ~ Reusability
    185

    View Slide

  186. - Usability ~ Reusability
    - Make application team-friendly
    186

    View Slide

  187. - Usability ~ Reusability
    - Make application team-friendly
    - Keep library easy to use
    187

    View Slide

  188. - Usability ~ Reusability
    - Make application team-friendly
    - Keep library easy to use
    Animated-emoji-colorful output in app - cool, whatever
    188

    View Slide

  189. - Usability ~ Reusability
    - Make application team-friendly
    - Keep library easy to use
    Animated-emoji-colorful output in app - cool, whatever
    Math library with zero allocation HTTP router - thanks, but no
    189

    View Slide

  190. Summary
    Packages & Modules

    View Slide

  191. 191

    View Slide

  192. - Simple and shy packages
    192

    View Slide

  193. - Simple and shy packages
    - Clear naming is important
    193

    View Slide

  194. - Simple and shy packages
    - Clear naming is important
    - No global state at all
    194

    View Slide

  195. - Simple and shy packages
    - Clear naming is important
    - No global state at all
    - Interfaces are for abstraction
    195

    View Slide

  196. 196
    - Simple and shy packages
    - Clear naming is important
    - No global state at all
    - Interfaces are for abstraction
    - Modules == Go ecosystem 2.0

    View Slide

  197. 197
    - Simple and shy packages
    - Clear naming is important
    - No global state at all
    - Interfaces are for abstraction
    - Modules == Go ecosystem 2.0
    - App != Lib

    View Slide

  198. Thank you
    Packages & Modules

    View Slide

  199. - Ben Johnson @benbjohnson
    - Dave Cheney @davecheney
    - Jaana B. Dogan @rakyll
    - Go team ʕ◔ϖ◔ʔ
    - all the friends \o/
    199

    View Slide