Hi Leo, Leo Famulari <l...@famulari.name> writes:
> On Fri, Oct 13, 2017 at 01:12:32PM -0400, Mark H Weaver wrote: >> l...@famulari.name (Leo Famulari) writes: >> > gnu: Add go-github-com-templexxx-reedsolomon. >> >> On this, and a great many other packages, you've included "github-com-" >> in the package names. I think this is a very bad idea. For one thing, >> we should not advertise, promote, or enhance the lock-in of GitHub, and >> this policy does all three. > > Please don't suggest that I made a policy to promote or enhance GitHub > "lock-in". Please keep reading for more information on why the packages > are named this way. > >> Sometimes a maintainer decides to change their hosting arrangements. >> When they do so, we should simply be able to update some URLs in one >> package definition. We should not have to do a global find/replace on >> the package name and alert our users to update their profiles and OS >> definitions. That contributes to lock-in. > > These packages are libraries written in the Go programming language. Go > libraries are referred to by their "import path" [0], which is a string > intended to uniquely identify a particular software implementation. > > As I wrote in the commentary on the go-build-system (part of the commit > series being discussed), import paths are based on the URL of the > software. A package hosted at https://github.com/leo/foo has an import > path of 'github.com/leo/foo'. In Go, this is the library's name. > > These import paths are the sole mechanism by which Go software is > uniquely referred to by humans and the Go compiler. It is even baked > in to how dependencies are organized on disk. Thanks for the explanation. I find this very disturbing, but I acknowledge that this lock-in is caused by Go itself, and that there's probably not much that we can do about it. Oh well. I withdraw my objection to these package names. Regards, Mark > [0] https://golang.org/doc/code.html#ImportPaths
