Tidy up top-level directory

[squaremo]

For future growth, it's worth separating the weave script from the weave router code. The former is docker-specific, while the latter can be (and is, I'm told) run independently of docker, and may end up referring to images other than the router.

[squaremo]

NB, it'd be good to

1. Retain history
2. Keep the script in this repo, since this is what people look at

[rade]

need to figure out what to do with https://github.com/zettio/weave/tree/master/docs. The diagrams obviously need to be in the same repo as the readme. but the architecture and testing docs are about the weave router and make no reference to docker, so should probably stay with the router code.

[rade]

What about issues? Presumably most should be moved to the weave-router repo.

I do wonder whether this sort of fragmentation will hurt us more than benefit. The alternative would be to keep a single repo and move things around the dir/package structure.

[dpw]

Please, please, please, no premature splitting of repos. It's fine for things to live in the same repo even if they can potentially be used separately. Splitting projects over multiple repos has high costs, as anyone from the rabbitmq team should know. So unless splitting a repo solves immediate practical problems, it is better not to.

[squaremo]

@dpw Good points, well made.

On reflection I'm happy with the status quo, given a bit of minor up to make it clearer which bits are which. In particular, we could move the lib code *.go into a subpackage, so it's not cluttering up the top-level (and giving rise to confusion over compilation / containerisation phases).

[dpw]

Yes, I'd like to see the top-level *.go files moved into a subdir, though I don't know go conventions well enough yet to say what the implications of that might be.

[squaremo]

I don't know go conventions well enough yet to say what the implications of that might be.

It's a pain in the arse, it turns out. If you have a main in the same repository, it has to live in another directory (go doesn't like two different packages in the same dir). To find the dependencies of main.go, go will look in $GOPATH, and if you've imported your package as "github.com/zettio/weave", it expects it to be in the directory $GOPATH/src/github.com/zettio/weave/.

What I've done in squaremo/weavedns is to put the Dockerfile and Makefile in a docker/ directory, and main.go in its own directory, and left the rest in the top directory. go build in main/ or the top will work.

Another way would be to accept there will be subpackages e.g., "github.com/zettio/weave/net", though these are likely to collide with the libraries they themselves are using (net, dns, ..), which is a bit of a pain as well.

[dpw]

I was afraid that might be the answer. This is one area of go that doesn't seem so well thought-through.

Could call the package "weavenet", perhaps?

[rade]

Another way would be to accept there will be subpackages e.g., "github.com/zettio/weave/net"

Indeed there will be. The DNS stuff should certainly not live in the same package as the network stuff.

these are likely to collide with the libraries they themselves are using

Meh. Alias them on import. Or, better, pick names that are less likely to clash (though I'd really want to avoid weave-prefixing everything).

[squaremo]

The DNS stuff should certainly not live in the same package as the network stuff.

It doesn't anyway, since the repository determines the package basename.

Or, better, pick names that are less likely to clash

router and names or something, perhaps.

[rade]

[DNS] doesn't [live in the same package as the network stuff] anyway, since the repository determines the package basename.

Ah, but I thought the (new) plan was to move the DNS stuff into main weave repo.

[squaremo]

Ah, but I thought the (new) plan was to move the DNS stuff into main weave repo.

Is it? OK well subpackages will work fine, in any case.

[rade]

Most of the work here got done in 0f364f7e470b63145ce9607fa16bd3c6a773be79 and e2fd1fda31f729e2ff5ebd51dd1a47aee3eb3d6f. Merging the DNS stuff is a separate issue. Left to do here then, I think, is moving the Makefile, weave script, and docker-ns to the top level.

[squaremo]

moving the Makefile, weave script, and docker-ns to the top level.

Can we put docker-ns in bin/ or something, just to avoid distraction ..

[rade]

Can we put docker-ns in bin/

Sure.