move workspace out of goworld directory #82
Conversation
| @@ -2,7 +2,7 @@ | |||
| debug = 1 ; set to 0 in production | |||
|
|
|||
| [deployment] | |||
| desired_dispatchers=1 | |||
| desired_dispatchers=2 | |||
There was a problem hiding this comment.
kindly suggestion: do not involve unrelated change
There was a problem hiding this comment.
I didn't give this specific line much thought. It's just there are more than one dispatchers in the sample. And it doesn't seem like affecting much on dev phases by increasing on the count. You can reject this if you don't like it.
From my point of view, the sample config should be verbose about more than one dispatcher. And since all actual run time config were created by copying this sample file. It would be a good choice to default the count of dispatchers to at least 2.
| @@ -34,3 +34,4 @@ vendor/ | |||
| .idea.bak/ | |||
| .vscode/ | |||
| tests/ | |||
| /goworld.ini | |||
There was a problem hiding this comment.
why remove this file?
There was a problem hiding this comment.
This file is constantly edited across different projects. However, it's content can be reproduced directly by copying from the goworld.ini.sample. Removing it from the source file prevents others from accidentally committing non-relevant change, or worse, breaking others' project.
I've adding process to the build script, specifically handling creation of the goworld.ini from sample, and placing it to the bin folder. So most people won't even notice it.
This PR serves as an early preview, and fire up the talk about the subject.
Currently all documentations and the
goworldbuild tool suggest working directly inside thegoworldrepo directory. I've started to modifying the build tool to supportGowork flow and directory structure.So far I have modify the build process to follow go module rules. It now supports building projects outside of the
goworlddirectory. Further, I can make customization possible to gate, dispatcher, and game. Making them all can live outside ofgoworlddirectory. So it'll be possible for others to just use this package as a dependency, and customize the actual work flow as they want.However, as the imports are hard-linked to the original repo, I have no way of further testing the whole process. I've tried copying the chat demo from examples directory. Place it in various directories, inside and outside of
GOPATH. It seems the building process goes fine. Until I actually add thego.modfile to the demo. Which rquires the v0.1.6 version of the originalgoworld. And that version doesn't work well with redis cluster v1. I've tried switching to a commit from master with no success.Please share your thoughts regarding my approach. More importantly, do you think it's necessary to make this package usable as pure dependency, instead of working directly inside it?