How do you reference a versioned sub-package? about gopkg HOT 9 CLOSED

This would be the right URL: http://gopkg.in/GlassyMedia/go-json-rest.v1/trie

from gopkg.

Actually, I'm reopening this as it should be better documented. Thanks for bringing it up.

from gopkg.

thanks

from gopkg.

I have a project go-godo/godo with many subpackages.

cmd/godo/main.go looks like this

package main

import (
    . "github.com/go-godo/godo"
    "github.com/go-godo/godo/util"
)

I expected import rewrites but the source in gopkg.in/godo.v1 still refers to github.com/go-godo/godo so how would that work if multiple projects in the workspace reference godo.v1 and godo.v2? Am I supposed to use import `"gopkg.in/godo.v1" in the godo project itself?

from gopkg.

@mgutz yes you would need to import gopkg.in/godo.v1 instead of direct github path.

from gopkg.

@GeertJohan That makes things quite problematic, doesn't it? You can't exactly refer to non-existent packages while your project is in development, so you have to develop in $GOROOT/gopkg.in/project.v[number] -- which kind of defeats the purpose of an isolated, version-locked directory, cloned from a normal github repo. On top of that, almost no one uses that standard, so any packages or libraries that import internally from github.com are now broken or basically just waiting to be broken.

from gopkg.

any updates on this? If I have a package that contains multiple sub packages, which are always 100% compatible to the parent package, renaming the imports is a lot of wasted effort/time and just overhead.

from gopkg.

I haven't tried gopkg.in with subpackages yet. Do you have a v1 branch with different import paths? And on every release you merge changes from master and have to update import paths or deal with conflicts?

Looking at some of the Canonical uses,mike go-aws, they don't have a mater branch at all. So they only need to change import paths when releasing a new major version. You can set your default branch to something other than master on GitHub.

from gopkg.

This was here as a doc issue, but the links here seem to be talking about git modules?

Either way, not that "go get" works more like gopkg.in itself, seems less of a concern.

from gopkg.