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: Ludovic Courtès
Subject: Re: Our package names should not include "github-com"
Date: Mon, 16 Oct 2017 15:05:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Hi Mark,

Mark H Weaver <address@hidden> skribis:

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

I agree this naming scheme isn’t great, but indeed, that’s what Go gives us.

Besides, Leo gave us 3 weeks to comment on
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28586>.  Thus, I believe
your message should have been framed as a suggestion for improvement
rather than “please fix this mistake”.

Thanks,
Ludo’.



reply via email to

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