migrate to gopkg.in/sconf/sconf.v0 about gcfg HOT 6 OPEN

Thanks, yes I intend to migrate it before Google Code goes read-only in August.
FTR: http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html

To expand on this, I plan to transition what has been known as gcfg to 
https://gopkg.in/sconf/sconf.v0 (github sconf organization).

The design/organization and implementation of gcfg leaves a lot to be improved 
(see TODOs and open issues), and I intend to take this opportunity of changing 
import paths to also do some API cleanup and so on. (I am anticipating that 
incorporating many of the enhancements will be much more straightforward with 
updated APIs.)

You can already find a simple wrapper that just uses gcfg internally (it passes 
all the tests included with gcfg) with a new API. (For a start, it uses the 
Must convention in case a function panics on invalid input.) I will try to 
gradually enhance it part by part.

I'll make a broader announcement when there is some more progress to report; in 
the mean time any feedback is welcome here. And of course the existing gcfg 
will continue to work as usual.

I migrated my code to sconf and it worked ok but now when I try to install the 
sconf dependency I am getting errors:

  go get gopkg.in/sconf/sconf.v0
  ../../gopkg.in/sconf/internal.v0/internal/internal.go:8:2: no buildable Go source files in /home/projects/go/src/gopkg.in/sconf/internal.v0/internal/gcfg

Can you reproduce this with a clean GOPATH?

There was indeed an interim version of sconf with a broken gcfg directory so 
re-getting with a clean GOPATH may help. (A fresh go-get seems to work for me 
now.)

sconf is somewhat experimental / work-in-progress, longer-term project that is 
in flux, as indicated by the ".v0". I hope to get it in a stable state by the 
time of googlecode read-only switch. For now it's safer to stick with the 
original gcfg.

Sorry if this has caused confusion. Maybe I should separate the tasks of 
migrating gcfg to github and creating sconf but I thought having two separate 
packages would be redundant and more confusing in the long run.

Thanks, removing the gopgk.in folder from the sources in my GOPATH solved the 
problem.