On Tue, Mar 4, 2014 at 5:04 PM, Péter Szilágyi <pet...@gmail.com
> You force a package naming convention that cannot be circumvented. I agree
> that go<something> is boring, but go-<something> is equally boring and I
> don't like being restrained with my package names. The only place where I
That's not true. The *package* can be named to your taste. The tool
forces a naming convention on the GitHub repository, and that's
required to implement its functionality without more boilerplate. So
hopefully we'll have more foos and bars, and less gofoos and gobars,
but even that is up to if you really want it.
> Requiring each package to have it's own github user is imho a bit steep.
I don't know what you're talking about here. It doesn't.
> You require github exclusively. Although that is also my favorite source
GitHub is by far the most popular code hosting site. Sounds like a
good place to start.
> As brought up earlier, it's another dependency in the development life
> cycle, and a very serious one. Can you guarantee that your site will always
> remain online?
Of course not. I don't know of any site that always remains online.
That said, this is a trivial service, and having it highly available
is no trouble. The efforts on that will be proportional to its use.
> Will you operate it indefinitely? Any source code using this
> scheme will immediately be bound to it for all time. IMO, this is a very
> serious decision to make as a dev.
Yes, I will operate it indefinitely. It would be very ironic if while
pursuing the stability of code at large I broke everybody at once.
> As long as your within an organizations, these issues can be solved by
> sticking to *the* convention, but out at large I think the limitations
> outweigh the benefits.
If that's not clear, the goal of gonuts.org
is to strongly encourage
authors to consider the stability of their APIs over time, and to
offer a simple path towards that. Pretty much 100% of the packages
hosted at GitHub today don't do anything like that. So, if you're
worried that gonuts.org
will break your code somehow, we're on the
same side of the problem. Your code *will* be broken soon if the
packages you depend upon do not adopt a stability strategy.
gustavo @ http://niemeyer.net