Hi, On Mon, 23 Sep 2019, at 11:04 AM, sdd.dav...@gmail.com wrote: > > If I have a reasonably large and complex (pet) project with local packages in > it. I like to split my project in to small units with 'namespaces' to keep it > manageable. These are NOT reusable components until I decide they qualify and > publish on Github.
> * Why MUST I import them as if they are from github and then 'replace' them, > and if I don’t 'MUST' then you have failed to explain this feature to me! Can you provide an example of what you are doing or a link to the documentation that is telling you to do this? Every module in Go has a name and when you have modules in different locations, even just peer directories on your local machine, you need to write the mapping in go.mod between the name of the module and its location. For example, I have a non-public library that is used by another module on my machine. I have this in my go.mod to link the two together without needing to publish the library: replace ian.local/tools => ../tools > * My local packages are part of my application. They are, I agree still > 'dependencies' but they are not 'DEPENDENCIES' that I need (or even want) to > import from a repository. They are part of my project. That's fine. Packages that are in subdirectories are usually simply part of the parent module. However you still need to name them so you can import them in your code. The pattern is that each package name is appended to the module name like a path, so in my example above a subpackage of tools would be referred to as ian.local/tools/subpackage > * What if I do not want to host my project on a GIT repo (Shock horror!). The go tool also supports Bazaar, Fossil, Mercurial and Subversion. See https://golang.org/cmd/go/#hdr-Remote_import_paths > * Why do all imports start with github.com. Is that a requirement, what is > the rational for this. It is not a requirement. You are simply seeing the consequences of 90% of packages being hosted there. You may also commonly see packages hosted at golang.org, gopkg.in, bitbucket.org and many others. There are no restrictions and you can host on your own domain. > * How does a 'import' resolve its 'reference'. The go tool uses go.mod to find out how to resolve a package name. Usually it simply maps directly to a remote repository (in which case go.mod will also contain some version information) but it could also map to another compatible package or to a location on your local machine. > * Should I add the go.mod and go.sum files to my repository or should the > developer who cloned my project have to do a go mod init (bummer!). > You should do it. Give your module a name so people know what to use when importing it. As far as I know the only restriction is that the name must have a dot in it. By convention people name their modules with the repository name but that is not required. If you don't plan to share your code then you can make up a name like I did above: example.local works for instance. > *Can someone please explain, properly!* I feel your pain! Modules are conceptually simple (a collection of related packages) but the interactions with code repositories, tools, build systems and user expectations are phenomenally complicated. The documentation is comprehensive and extensive but still misses some important "getting started" information. If you have specific requirements or problems with it then raising an issue for the Go team to track would be useful. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/66c4b89f-d0bd-43d7-b46f-77c9be680092%40www.fastmail.com.
