mediocregopher/goat — pull request #2 by mediocregopher (2013-08-24 20:27:06+00:00)
Title: Loopback

I encountered a problem with my initial design of goat. At the start my goal was to get rid of the "absolute import paths" (aka `github.com/mediocregopher/ghost`, as opposed to the "relative import path" of `ghost`). I realized this is both a bad goal and not actually workable anyway.

For example, say you have a GoProject and a GoLibrary, both being goat projects, and GoProject wants to import GoLibrary. goat will put GoLibrary in GoProject's path using the absolute import path (under `lib`). But inside of GoLibrary all the import paths will be relative because it is also a goat project and it was developed in the relative path sandbox.

This was a bad goal to have anyway because those full paths are important, as they say where the project is coming from. Without them you'd have to look inside the Goatfile. If they're there then tools like `go install` can still be used on the project (although without the versioning provided by goat it might not actually work, but for a stand-alone project there might still be value). Having the absolute path would also get rid of the need for the `src` directory in the goat project.

My solution was to add a field to the Goatfile which specifies the absolute path of the project, and goat will create a symlink back to the project root inside of `lib` matching that path. So when you go to import the absolute path version of a module inside your project it'll still be able to find it.

Goatfiles have also been reworked, although the old syntax still works, it just gives an error about it being deprecated.