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