Our package names should not include "github-com"

Our package names should not include "github-com"

[Mark H Weaver]

Hi Leo,

leo@famulari.name (Leo Famulari) writes:

> lfam pushed a commit to branch master
> in repository guix.
>
> commit 478ebb31a96955fc03fcea55a4432976ddb49319
> Author: Leo Famulari <leo@famulari.name>
> Date:   Wed Oct 11 20:22:32 2017 -0400
>
>     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.  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.

What do you think?

      Mark

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

[ng0]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

Mark H Weaver transcribed 0.9K bytes:
> Hi Leo,
> 
> leo@famulari.name (Leo Famulari) writes:
> 
> > lfam pushed a commit to branch master
> > in repository guix.
> >
> > commit 478ebb31a96955fc03fcea55a4432976ddb49319
> > Author: Leo Famulari <leo@famulari.name>
> > Date:   Wed Oct 11 20:22:32 2017 -0400
> >
> >     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.  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.
> 
> What do you think?
> 
>       Mark

I think Leo just followed the upstream conventions here, where it is
named after the path the go module ends in.
If we decide not to name the package like this, we might break expectations.
So when we break expectations, what are the alternative naming schemes
we could pick for go packages that'll still make sense to people
using Go?
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://dist.ng0.infotropique.org/dist/keys/
https://www.infotropique.org https://ng0.infotropique.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[ng0]

[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]

ng0 transcribed 2.5K bytes:
> Mark H Weaver transcribed 0.9K bytes:
> > Hi Leo,
> > 
> > leo@famulari.name (Leo Famulari) writes:
> > 
> > > lfam pushed a commit to branch master
> > > in repository guix.
> > >
> > > commit 478ebb31a96955fc03fcea55a4432976ddb49319
> > > Author: Leo Famulari <leo@famulari.name>
> > > Date:   Wed Oct 11 20:22:32 2017 -0400
> > >
> > >     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.  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.
> > 
> > What do you think?
> > 
> >       Mark
> 
> I think Leo just followed the upstream conventions here, where it is
> named after the path the go module ends in.
> If we decide not to name the package like this, we might break expectations.
> So when we break expectations, what are the alternative naming schemes
> we could pick for go packages that'll still make sense to people
> using Go?

One idea could be:

    go-templexxx-reedsolomon
    
so just remove the hoster from the package name.
I'm not using Go, so I don't know if this will make any sense
or cause potential namespace issues.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://dist.ng0.infotropique.org/dist/keys/
https://www.infotropique.org https://ng0.infotropique.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 3817 bytes --]

On Fri, Oct 13, 2017 at 01:12:32PM -0400, Mark H Weaver wrote:
> leo@famulari.name (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.

If the software changes its source URL, all users of the software must
change how they refer to it, at least if they want to use versions of
the software after the URL change. This means they must go through their
code and change the module imports from 'github.com/leo/foo' to
'newsite.com/leo/foo'. They will also need to change the filesystem
hierarchy in which they store their dependencies, to reflect the change.

I'm trying to explain that, in Go, domain names of library sources are
very important, and not just an implementation detail. [1]

So, in fact, we will not be able to just change the source URL of a Go
package if it moves to a new domain name.

Based on these properties of Go, the Guix packages are named based on
the import paths, plus a 'go-' prefix, in accordance with our practice
of adding language names to library packages.

> What do you think?

There are many Go libraries with the same "base name" (foo in my
previous example). So, we'll need to at least include some of the import
path in order to distinguish them.

Will we always need to use the entire import path, including the
domain-name component? I think so, but having only packaged one Go
application, I don't have an example of a cross-domain package name
collision. However, I have seen Go libraries use domain redirections to
signal API changes [2].

Does an import path always include some unique string besides the domain
name and the base name? I don't know.

Ultimately, I think we need a way to refer to Go libraries uniquely. I
think it will be confusing to have two different unique naming schemes
(Go import paths and whatever we'd come up with).

Does anyone have an idea for another way to uniquely refer to Go
libraries?

Finally, I don't think that including the string 'github-com' in package
names is unethical. It's too bad that there is a hosting monoculture.
But simply mentioning it, which is how I see the package names, is not
unethical, IMO.

[0] https://golang.org/doc/code.html#ImportPaths
[1] If you did a double-take, thinking "That's crazy!", then you
probably understood correctly.
[2] The site <https://gopkg.in/> is used for this.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Mark H Weaver]

Hi Leo,

Leo Famulari <leo@famulari.name> writes:

> On Fri, Oct 13, 2017 at 01:12:32PM -0400, Mark H Weaver wrote:
>> leo@famulari.name (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

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

[Maxim Cournoyer]

Hello!

Mark H Weaver <mhw@netris.org> writes:

> Hi Leo,
>
> Leo Famulari <leo@famulari.name> 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

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

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> Leo Famulari <leo@famulari.name> writes:
>
>> On Fri, Oct 13, 2017 at 01:12:32PM -0400, Mark H Weaver wrote:
>>> leo@famulari.name (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’.

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

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

On Sun, Oct 15, 2017 at 08:41:45PM -0400, Maxim Cournoyer wrote:
> >> [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?

Using the domain name as part of the *upstream* library name is useful
for upstream authors because of how Go's built-in dependency management
tools work. Go integrates dependency management into the language and
the `go` tool itself. Re-using the upstream library name is useful
because they have already disambiguated for us.

I don't intend to be rude, but I'm not going to put much effort into
responding to further comments that are not based on knowledge of how Go
handles package / dependency management with its built-in tools, or
modular programming in Go, in general. Already I used tons of my free
time to learn this stuff, just so I could make Guix packages of Go
software. Please meet me where I am.

Again, I don't see an ethical problem here, so any motivation for me to
participate in this discussion, as a volunteer, must be technical. If
it's *wrong* to name the packages in this way, I will behave
differently.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

On Mon, Oct 16, 2017 at 05:38:43PM -0400, Leo Famulari wrote:
> Using the domain name as part of the *upstream* library name is useful
> for upstream authors because of how Go's built-in dependency management
> tools work. Go integrates dependency management into the language and
> the `go` tool itself. Re-using the upstream library name is useful
> because they have already disambiguated for us.
> 
> I don't intend to be rude, but I'm not going to put much effort into
> responding to further comments that are not based on knowledge of how Go
> handles package / dependency management with its built-in tools, or
> modular programming in Go, in general. Already I used tons of my free
> time to learn this stuff, just so I could make Guix packages of Go
> software. Please meet me where I am.
> 
> Again, I don't see an ethical problem here, so any motivation for me to
> participate in this discussion, as a volunteer, must be technical. If
> it's *wrong* to name the packages in this way, I will behave
> differently.

I replied too harshly here, and I apologize for that. For me, this
conversation really started on the wrong foot.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Maxim Cournoyer]

Hello,

Leo Famulari <leo@famulari.name> writes:

> On Mon, Oct 16, 2017 at 05:38:43PM -0400, Leo Famulari wrote:
>> Using the domain name as part of the *upstream* library name is useful
>> for upstream authors because of how Go's built-in dependency management
>> tools work. Go integrates dependency management into the language and
>> the `go` tool itself. Re-using the upstream library name is useful
>> because they have already disambiguated for us.
>> 
>> I don't intend to be rude, but I'm not going to put much effort into
>> responding to further comments that are not based on knowledge of how Go
>> handles package / dependency management with its built-in tools, or
>> modular programming in Go, in general. Already I used tons of my free
>> time to learn this stuff, just so I could make Guix packages of Go
>> software. Please meet me where I am.
>> 
>> Again, I don't see an ethical problem here, so any motivation for me to
>> participate in this discussion, as a volunteer, must be technical. If
>> it's *wrong* to name the packages in this way, I will behave
>> differently.
>
> I replied too harshly here, and I apologize for that. For me, this
> conversation really started on the wrong foot.

I agree this conversation could have been more cheerful! I understand
your irritation; let me use this opportunity to thank you for your hard
work and time spent working on bringing Go to Guix! There seems to be
interesting solutions built with Go.

I'm trying to rectify my ignorance of the Go system; I've started
reading about Go but haven't gone so far yet to be able to answer my
question in a definitive way. I'll keep reading! I've seen that Debian
is also using the repo names in their go packages naming scheme, so
there must be some good to it.

Maxim