Self hosted

[alexkappa]

Hi @niemeyer,

This is not an issue, more of a question really. Is there any plan to add support for self hosted deployments. It would be really cool if we can use this tool internally. I was reading through the code, and I suppose to do such a thing would be quite doable, for the most part it's about replacing "gopkg.in" with a variable (perhaps flag) and other such values which are now hard coded.

Would you be accepting pull requests for these additions? Do you have any guidelines or recommendations for contributing?

Thanks,
Alex

[niemeyer]

Hey Alex,

Indeed it should not be hard, and I wouldn't having a flag to make this a runtime option, as long as we can keep both cases clean.

No specific guidelines, other than the common ones for Go code in general.

[alexkappa]

Thanks for the quick reply, you can already see some changes at alexkappa/gopkg. I'll verify it a bit further and submit a PR.

I would like to hear your thoughts on another issue if you have the time. When self hosting, the github username may become unnecessary, since it's already under a custom domain. For example go.alexkappa.com/alexkappa/pkg.v0 is a bit verbose. It would be better if I could remove the username and just use go.alexkappa.com/pkg.v0. But then the go-pkg/pkg packages wouldn't resolve correctly. But that should be ok because for those, we should still use gopkg.in as they wouldn't work any other way.

-Alex

[niemeyer]

We can have a flag to alter between two modes:

1. The default behavior: a missing user means go-[repository name]
2. A custom default user

We cannot have a mix of both at once, because that'd be ambiguous.

[niemeyer]

Thanks for cooking this, Alex.

I'm trying to think about the consequences in terms of people understanding that although this looks a lot like a common gopkg.in, it actually follows slightly different rules which conflict with what's documented.

I still want to support your use case, though. Can you please detail it a little better? For example, a few questions:

a. Do you just want to support the repositories of a single user on a different domain, or multiple users?

b. Is that a private domain and service, or is going to be publicly visible?

Also, there's a small problem with the approach which I did not anticipate above: there's still ambiguity of user name vs. repository name. Imagine for example someone accesses go.alexkappa.com/jam.. is jam a project or a user? Depending on the answer to (a) above, there's an easy solution.

[natefinch]

Seems like the intent is just to support a single user... I was thinking of doing this, too. For example, pointing natefinch.com/lumberjack.v2 to github.com/natefinch/lumberjack (v2 branch)

However, you're right that it might be confusing that people will expect it to work like gopkg.in, but it'll have different behavior.

Maybe something as simple as a disclaimer at the top, like "This site redirects go get from to repos under github.com//."

[alexkappa]

I would say single user on a custom domain. Think of it as vanity plates :). It might help out in the future with private repos too. We could deploy gopkg on a restricted network to limit access for example. But that will need some work I suppose.

go.alexkappa.com/jam.v0 would resolve to github.com/alexkappa/jam so I guess the answer to your last question is jam is a project not a user. Now that I think about it, it might be even better to resolve to github.com/alexkappa/go-jam, as it's more common for libraries.

Supporting multiple users doesn't make much sense in a self deployment scenario imo. I mean, would someone prefer go.alexkappa.com/natefinch/lumberjack.v2 instead of what is already provided by gopkg.in, gopkg.in/natefinch/lumberjack.v2?

-Alex

[nathany]

If supporting multiple users, it could just be the default behaviour, which amounts to using gopkg.in as is on a different domain.

If I were using this, it would be for a single organization or user. As in:

go.fsnotify.org/fsnotify.v1 -> github.com/go-fsnotify/fsnotify

Ideally, I would want to configure the mount point and the organization/user it points to:

go.fsnotify.org/* -> github.com/go-fsnotify/*

or based on http://golang.org/s/go14subrepo:

fsnotify.org/x/* -> github.com/go-fsnotify/*

or if I prefer:

fsnotify.org/x/* -> github.com/fsnotify/*

I don't think it makes sense to only host one project. Something like v1.fsnotify.org is short, but won't result in a nice default name for the imported package. fsnotify.org/x/fsnotify.v1 seems better, even if it is more verbose.

All this said, I'm pretty happy hosting it on gopkg.in.
@niemeyer Thanks for running those servers for us. 😄

[nathany]

I like @slimsag's suggestion of making gopkg into a pkg where things like the GoPkg.in homepage are part of the cmd.

That would provide a lot of flexibility.

Stripe provides another reason for running self-hosted:

From a security perspective, having yet another layer of indirection means another attack vector we'd need to consider. We could have, of course, decided to run our own instance to alleviate this.

[slimsag]

If I did the work to split gopkg into a package itself (importable via github.com/niemeyer/gopkg/gopkg ? Or via gopkg.in as well?) would such a change be welcomed?

[elithrar]

Although this is a very old issue, you could potentially tackle it by using template tags - e.g.:

• The public gopkg.in matches on gopkg.in/{{github.username}}/{{repository}}.{{rev}} or gopkg.in/go-{{repository}}/{{repository}}
• Self-hosted instances could accept CLI options (or env vars, a config file, etc) that allows you to specify the base domain and default username (to use if unspecified). This would support things like project.io/pkg.v1
• Template tags could be used to specify a URL format other than the default - e.g. {{domain}}/{{github-username}}/{{repository}}.{{rev}} could become {{domain}}/{{rev}}/{{repository}} (e.g. project.io/v1/pkg) when configured with a default username.

I'd be happy to do the legwork on this if the design is agreeable.