Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do you reference a versioned sub-package? #9

Closed
Quantisan opened this issue Apr 8, 2014 · 9 comments
Closed

How do you reference a versioned sub-package? #9

Quantisan opened this issue Apr 8, 2014 · 9 comments

Comments

@Quantisan
Copy link

For example, if router.go of main uses trie package in a subdir, I tried gopkg.in/GlassyMedia/go-json-rest/trie.v1 but it doesn't seem to work. Is this feature available?

I can send in a pull request if you point me in the right direction on how to patch it.

├── router.go
├── router_benchmark_test.go
├── router_test.go
├── status.go
├── status_test.go
├── test
│   └── util.go
├── timer.go
└── trie
    ├── impl.go
    └── impl_test.go
@niemeyer
Copy link
Owner

niemeyer commented Apr 8, 2014

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

@niemeyer niemeyer closed this as completed Apr 8, 2014
@niemeyer
Copy link
Owner

niemeyer commented Apr 8, 2014

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

@niemeyer niemeyer reopened this Apr 8, 2014
@Quantisan
Copy link
Author

thanks

@mgutz
Copy link

mgutz commented Nov 1, 2014

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?

@GeertJohan
Copy link
Contributor

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

@Sam-Izdat
Copy link

@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.

@wwwdata
Copy link

wwwdata commented Dec 11, 2015

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.

@nathany
Copy link
Contributor

nathany commented Dec 11, 2015

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.

@niemeyer
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants