Q: symlink to avoid $PROJECT/src/github.com/my/project hierarchy?

[tve]

My projects tend to have sub-packages that import each other. E.g. in github.com/my/project/pkgA I have import "github.com/my/project/pkgB. As far as I can tell, this means that all my source code has to be placed into $PROJECT/src/github.com/my/project/pkg* instead of just into $PROJECT/src/pkg*, or am I missing something?

To avoid the deep nesting I created a symlink: $PROJECT/src/github/my/project -> ../.. and it seems to work fine. Is it safe or am I going to run into issues down the road? Is this an officially supported method or an officially banned method?

[davecheney]

Symlinks are not supported because they allow one piece of code to have
more than one import path.

As gb doesn't require URLs in the import path you can avoid this name
spacing if you choose. I'll address this with a FAQ entry.

On Sat, 23 May 2015 07:41 Thorsten von Eicken notifications@github.com
wrote:

My projects tend to have sub-packages that import each other. E.g. in
github.com/my/project/pkgA I have import "github.com/my/project/pkgB. As
far as I can tell, this means that all my source code has to be placed into
$PROJECT/src/github.com/my/project/pkg* instead of just into
$PROJECT/src/pkg*, or am I missing something?

To avoid the deep nesting I created a symlink:
$PROJECT/src/github/my/project -> ../.. and it seems to work fine. Is it
safe or am I going to run into issues down the road? Is this an officially
supported method or an officially banned method?

—
Reply to this email directly or view it on GitHub
#116.

[tve]

Ok, how does this translate to libraries using gb? If I have a library with 2 packages one of which imports the other, how can this work? E.g. pkgB imports pkgA but then the library gets vendored into some other project as $PROJECT/vendor/src/github.com/my/library and the import paths all need to be rewritten? Is that the intent?

[davecheney]

I'm not sure if I understand your question, but if you have a project with two packages

$PROJECT/
   src/
      github.com/you/
         a/
             b/

Then `github.com/you/a/a.go` should `import "github.com/you/a/b"`

Sorry in advance if I didn't understand your question.

[tve]

To pick-up your example, if I want to avoid the /github.com/you part and I have a library with:

$PROJECT/
   src/
      a/
      b/

Then a/a.go should import "b", but the moment it is vendored into another project these import paths no longer work. So bottom line is that everything has to be 3 more levels down in the hierarchy, which I really dislike, but of course that's a matter of taste.

Another issue that concerns me is that even with the full layout:

$PROJECT/
   src/
      github.com/
         you/
            library/
               a/
                  a.go // import "github.com/you/library/b"
               b/

Doesn't this library become impossible to go get into a non-gb application because that would have to import "github.com/you/library/src/github.com/you/library/a" (which is pretty horrible) and then the import of b from a would not work?

Maybe a good question is the following: is it a must-have to you to make gb usable for libraries, and if so is it also a must-have to make these libraries usable outside of gb without having to jump through major hoops? (If the answer isn't yes & yes then that makes gb much less attractive to me, but I don't claim to be anywhere close to "representative" :-).

[davecheney]

Then a/a.go should import "b", but the moment it is vendored into another project these import paths no longer work.

When a and b are vendored, they will be placed in

$PROJECT/
   vendor/
       src/
          a/
          b/

So they retain their canonical import path. I am sorry, this is yet not very well explained on the getgb site. #49

Doesn't this library become impossible to go get into a non-gb application because that would have to import "github.com/you/library/src/github.com/you/library/a"

Yes, gb projects are not go gettable. This is a result of adopting a different layout for projects that is not compatbile with go get.

Maybe a good question is the following: is it a must-have to you to make gb usable for libraries, and if so is it also a must-have to make these libraries usable outside of gb without having to jump through major hoops?

Yes, gb supports writing libraries, groups of packages that don't produce a binary directly, see #49.

[tve]

When a and b are vendored, they will be placed in

I see, thanks for the clarification. That's a pretty drastic butchering of the repo the library comes from, but it's clearly necessary. Mhhh, not sure what to think about that...

Regardless, thanks for taking the initiative to attack the beast!

[davecheney]

Answered; closing for the moment.