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: Maxim Cournoyer
Subject: Re: Our package names should not include "github-com"
Date: Sun, 15 Oct 2017 20:41:45 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Hello!

Mark H Weaver <address@hidden> writes:

> Hi Leo,
>
> Leo Famulari <address@hidden> writes:
>
>> 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

I just read that link, and while it's true that they recommend using the
source repository domain as the base path of the library, it is by no
mean an obligation, as noted:

    In practice you can choose any arbitrary path name, as long as it is
    unique to the standard library and greater Go ecosystem.

I personally fail to see how using github.com gives much more uniqueness
to a library name (especially since I expect that most go stuff would be
hosted there) and find it equally disturbing. How hard would it be to go
against this de facto standard? Maybe we could have a procedure that
would strip any domain name from the libraries import paths?

Maxim



reply via email to

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