guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mark H Weaver
Subject: Re: Our package names should not include "github-com"
Date: Fri, 13 Oct 2017 21:05:31 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Hi Leo,

Leo Famulari <address@hidden> writes:

> 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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]