Re: Our package names should not include "github-com"

[Leo Famulari]

On Fri, Oct 13, 2017 at 01:12:32PM -0400, Mark H Weaver wrote:
> address@hidden (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.

If the software changes its source URL, all users of the software must
change how they refer to it, at least if they want to use versions of
the software after the URL change. This means they must go through their
code and change the module imports from 'github.com/leo/foo' to
'newsite.com/leo/foo'. They will also need to change the filesystem
hierarchy in which they store their dependencies, to reflect the change.

I'm trying to explain that, in Go, domain names of library sources are
very important, and not just an implementation detail. [1]

So, in fact, we will not be able to just change the source URL of a Go
package if it moves to a new domain name.

Based on these properties of Go, the Guix packages are named based on
the import paths, plus a 'go-' prefix, in accordance with our practice
of adding language names to library packages.

> What do you think?

There are many Go libraries with the same "base name" (foo in my
previous example). So, we'll need to at least include some of the import
path in order to distinguish them.

Will we always need to use the entire import path, including the
domain-name component? I think so, but having only packaged one Go
application, I don't have an example of a cross-domain package name
collision. However, I have seen Go libraries use domain redirections to
signal API changes [2].

Does an import path always include some unique string besides the domain
name and the base name? I don't know.

Ultimately, I think we need a way to refer to Go libraries uniquely. I
think it will be confusing to have two different unique naming schemes
(Go import paths and whatever we'd come up with).

Does anyone have an idea for another way to uniquely refer to Go
libraries?

Finally, I don't think that including the string 'github-com' in package
names is unethical. It's too bad that there is a hosting monoculture.
But simply mentioning it, which is how I see the package names, is not
unethical, IMO.

[0] https://golang.org/doc/code.html#ImportPaths
[1] If you did a double-take, thinking "That's crazy!", then you
probably understood correctly.
[2] The site <https://gopkg.in/> is used for this.

signature.asc
Description: PGP signature