From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: Our package names should not include "github-com" Date: Fri, 13 Oct 2017 16:24:25 -0400 Message-ID: <20171013202425.GA22896@jasmine.lan> References: <20171013014334.17601.30718@vcs0.savannah.gnu.org> <20171013014344.D813E20338@vcs0.savannah.gnu.org> <87lgkfhszj.fsf_-_@netris.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e36VV-0001zc-L5 for guix-devel@gnu.org; Fri, 13 Oct 2017 16:24:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e36VS-0004ZB-FC for guix-devel@gnu.org; Fri, 13 Oct 2017 16:24:33 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:33915) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e36VS-0004VK-8I for guix-devel@gnu.org; Fri, 13 Oct 2017 16:24:30 -0400 Content-Disposition: inline In-Reply-To: <87lgkfhszj.fsf_-_@netris.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mark H Weaver Cc: guix-devel@gnu.org --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 13, 2017 at 01:12:32PM -0400, Mark H Weaver wrote: > leo@famulari.name (Leo Famulari) writes: > > gnu: Add go-github-com-templexxx-reedsolomon. >=20 > 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 is used for this. --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlnhIPYACgkQJkb6MLrK fwjcsA/+IDv5j+TgeS3CMfxeFINXqLrApEg/S4ancTFzbdEo+ixVjRIv/BDKBaFz vYUtQ1XDpdTQ+D6OvZdglC19m+0KVuyaaCbUQVTeW6NxU0HMamIv03Am5jiDTqwg N286kCGcrMt9XhoM6aY1ob46zoYlCX4YxJluSqI4hrCjvxWZX/x2W1oMW/DZ60L1 47wX/kRRd+Gv7RxWRdgOzlfeR3rdrsnEyT5oB+h//tTIbyMhvHnRz1zRyrxGu4xJ aB0QVNtqYRSrvdcWxqWAYqDcrdHMdmjBAiQUkPNWoReAQD+Ixc+DsieMWqQuNR7B vW6M1vrE5bBetL6qrL33DbS5z2+rr0PL3K+eoc5JeeGz5KsBPBXu+/SL7Nkf38+2 UmwLOUA8VPkD7fa5VY4PnFHGjH8+hT+Af3IcvNbIwy+K6Zo0zpw02FJCBKqM2sBR O0pcNr/NS9bIbd16I4Y2pcBN9cUvmCl7wDD+B56ur1chuzc2lc+7ST+NFhQASQyJ NBgT5ufvhgU+p4o3OrNGUPy+jMaJzgsk/8BUpM15vBRlrfxYXsX8A/KT2ZlzKn3b vNImvbOQbCgs+mFXqsZKRvroByfQAKPbM7mseSDtXbHo9SKIH3t/6J2y4O/rUVt6 Fpk8+g4cT/RVb0s8M2sNh+Qii829fGmd20WLJ0hfJG9+hMjXUiY= =RPAZ -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7--