Hi, if i understood correctly this solves the location of the repository path but the repo path will still point to the old repo. It would be nice if the repo location could be anywhere and the import path anything e.g. hosted on any machine with the root package name be something different (location agnostic). The mod file or the project could have simple module name e.g. module patron and in the project that imports it: require patron v0.7.4 github.com/mantzas/patron.
When you `go get` a project for import you provide the location and `go get` could read the module name from the mod file and import it. This way you could solve the fork problem by just `go get` from another location. forking would work. On Thu, Dec 13, 2018 at 12:31 AM Ian Lance Taylor <i...@golang.org> wrote: > On Wed, Dec 12, 2018 at 8:08 AM Robert Engels <reng...@ix.netcom.com> > wrote: > > > > I am pretty sure that the correct solution is to decouple the package > from its location. And a global Go registry can tell Go get where that > package can currently be found. > > You don't need a global registry. Or, rather, the global registry can > be DNS. You can set up your own trivial redirector, using a meta tag, > as discussed at https://golang.org/cmd/go/#hdr-Remote_import_paths . > Or you can use an existing general purpose redirector such as > gopkg.in. Either way you can enforce this with an import comment as > discussed at https://golang.org/cmd/go/#hdr-Import_path_checking . > > Ian > -- Regards, S. Mantziaris -- 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. For more options, visit https://groups.google.com/d/optout.
