Fix project structure

[katcipis]

We should have a more clear structure on the project root, like:

cli service lib

Instead of what we have today, it is hard to know where is the lib/service (the cli is pretty obvious :-)

[i4ki]

And where will go the Godeps directory? We will continue with that dependency tool ?

[i4ki]

cli/Godeps service/Godeps lib/Godeps

?? I don't like that tool... We need a better way of handle dependencies!

[i4ki]

This project structure brings some problems.

For example, the new way of get the project will be:

• library go get github.com/NeowayLabs/neosearch/lib
• server go get github.com/NeowayLabs/neosearch/service
• cli go get github.com/NeowayLabs/neosearch/cli

And to use the library, we will need to import and use like this:

import "github.com/NeowayLabs/neosearch/lib"

lib.New() lib.CreateIndex() etc ...

We can bypass this problem with import alias, but I don't like this solution ... =(

import neosearch "github.com/NeowayLabs/neosearch/lib"

Another problem is that the binaries will have the names "cli" and "service" when compiled with "go install"... Not useful names. If we force the usage of "make" for the build, we can give a better name for them, but this can be unusual for gophers that expect the Golang-way of build libraries and binaries.

All of that makes sense? Do you think that the implications above are problems?

[katcipis]

It makes sense... and I support the idea to allow people to build stuff using only go tools.

The dependencies thing, Im thinking on using vendoring...instead of "go getting" stuff.

Go has this thing of coupling the name of the import with the name of the directory where you imported (which is coupled to how you organized stuff on the repo :P), and aliasing does not seen cool too.

Did some reading, now Im thinking on something like:

go get github.com/NeowayLabs/neosearch/lib/neosearch

go get github.com/NeowayLabs/neosearch/cmd/neosearch-service

go get github.com/NeowayLabs/neosearch/cmd/neosearch-cli

It seems that naming would not be terribly wrong.

[katcipis]

The cmd thing I stole from Go :P

[i4ki]

What do you think of the structure below?

/hack
/docs

/lib
/lib/neosearch

/cmd
/cmd/neosearch-cli
/cmd/neosearch-bench (example, it dont exist)

/service
/service/neosearch

With that, we solve the problems that I have listed before.

To use the library:

import "github.com/NeowayLabs/neosearch/lib/neosearch"

neosearch.New()

To get the cli and service will be:

go get github.com/NeowayLabs/neosearch/cmd/neosearch-cli will install the binary neosearch-cli in the $GOPATH/bin

go get github.com/NeowayLabs/neosearch/service/neosearch will install the binary neosearch in the $GOPATH/bin

much Bizarre?

[katcipis]

I found it to be awesome (as you can see on my previous comments :P).

[i4ki]

hahahaha

OK, I like too =)

[i4ki]

We can leave the "cmd" directory only to "command-line" tools. Then, the service (REST) source code can be located in a different place.

[katcipis]

Yeah I was in doubt about that, go tools usually go in the cmd...I never saw any service :P. On the end I think it will be good enough for now (and at least better than what we have today :-).