[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