github repo names with "go-" prefix?

[Tim Peoples]

I've noticed a somewhat common practice of people naming their github repositories with a "go-" prefix (and then, of course, subsequently dropping the prefix in the actual package name) -- yet a similar naming scheme doesn't seem to be commonplace among many other languages.

Is this recommended somewhere?  If so, where?

Conversely, is it explicitly discouraged?

[Tim Peoples]

[yes, I'm responding to myself (I tend to do that sometimes)]

Hmm.... I suspect part of it may be coming from this PackagePublishing wiki page, where it's mentioned almost as a foregone conclusion yet may often be interpreted as a recommendation.

However, I'll assume the genesis is elsewhere.

[Dave Cheney]

On Sunday, 24 December 2017 05:18:14 UTC+11, Tim Peoples wrote:
> I've noticed a somewhat common practice of people naming their github repositories with a "go-" prefix (and then, of course, subsequently dropping the prefix in the actual package name) -- yet a similar naming scheme doesn't seem to be commonplace among many other languages.
>

I believe the zeitgeist originated with JavaScript.

>
> Is this recommended somewhere?  If so, where?
>

It is not recommended for your package’s repository or directory name to differ from its package declaration.

>
> Conversely, is it explicitly discouraged?

Yes, for the reasons above, it’s confusing, also it’s redudant for the same reasons go programmers do not start interface declarations with a capital I.

[Jakob Borg]

On 23 Dec 2017, at 19:18, Tim Peoples <t...@timpeoples.com> wrote:
>
> I've noticed a somewhat common practice of people naming their github repositories with a "go-" prefix (and then, of course, subsequently dropping the prefix in the actual package name) -- yet a similar naming scheme doesn't seem to be commonplace among many other languages.

I think this is acceptable when you’re providing a library foo implemented in several languages and naturally get go-foo, python-foo, ruby-foo etc repositories. It’s still annoying but a natural effect of using the GitHub etc namespace for package naming and not having a Go specific package namespace.

In all other cases it’s discouraged.

//jb

[Tim Peoples]

Thanks Dave, that's exactly what I'd assumed (but didn't want to overly expose my original bias).

I only asked because every time I see this, it tends to make me wince (and I often end up forking the repo just so I can rename it).

I suppose the real question is, "How do we get people to stop?" :D

[Tim Peoples]

Sadly, that is rarely the case.

In fact, I often find authors with dozens of repos covering a number of languages -- yet, only their "go" repos are named as such (repos with no corresponding implementation in another language, mind you).

Oh well... :/

t.

[Manlio Perillo]

The only reason to use the go prefix is when, on the same github account, you want to publish an implementation of a protocol (e.g. a client for Amazon S3) in multiple programming languages (e.g. go-s3, python-s3, rust-s3).

Manlio Perillo

[Mariusz Gronczewski]

On Saturday, December 23, 2017 at 8:48:37 PM UTC+1, Tim Peoples wrote:

Sadly, that is rarely the case.

In fact, I often find authors with dozens of repos covering a number of languages -- yet, only their "go" repos are named as such (repos with no corresponding implementation in another language, mind you).

Oh well... :/

t.

Because other languages do not force you to have name of the package be derivative of the repo name. For example in Perl, repo with lib Foo::Bar can have any name, just that repo dir structure would be "./lib/Foo/Bar.pm.

That's the cost of having import statement be able to accept "just a path to a thing in the internet" (which is reasonable imo)

[Jan Mercl]

> On Sun, Dec 24, 2017 at 12:31 AM Mariusz Gronczewski <xan...@gmail.com> wrote:

> Because other languages do not force you to have name of the package be derivative of the repo name.

Neither does Go. The whole tool chain uses the name in the package clause, the import path is used solely to locate the package directory, it is never used to determine the package name.

> That's the cost of having import statement be able to accept "just a path to a thing in the internet" (which is reasonable imo)

Same comment applies here. The repository at github.com/user/bar can be package bar just fine. It'll simply be always what's written in the package clause, unrelated to the import path.

--

-j

[Tamás Gulácsi]

gopkg.in forces me to have github.com/go-goracle/goracle to produce gopkg.in/goracle.v2 as the import path. Seemed to be a little price for a nice import path.

[Tim Peoples]

...and yet, a vast majority of the instances where I see a go package hosted as "github.com/user/go-foobar", they are not using gopkg.in.

I'm w/ Dave on this one; except in very rare instances, this shouldn't be done (and even then, you should try find a way to avoid it).

Also, in many ways, this is a side effect of github's insistence that all their users live within a flat namespace.  (n.b. I once had Chris Wanstrath ask me which one feature I thought was missing from Github. I told him "global cross reference links". I should have said, "How about a hierarchical namespace?") 

t.