use of internal uuid package causes errors in forks about go.geteventstore HOT 7 CLOSED

Hi Thanks for highlighting this I will do some testing on this and get back to you.

from go.geteventstore.

This is a known issue with Go, because when forking the internal dependencies would still refer to the upstream repository. I'm facing this issue as well, been trying out some workarounds and haven't had luck so far.
This is a workaround that I found, let me know if it works for you @cwinkler http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html

from go.geteventstore.

@setyven yeah this should work, thank you.

I love go but i hate it's package management...

from go.geteventstore.

Thanks all,

I will be having a look at this and other issues today.

from go.geteventstore.

@setyven & @cwinkler

Is it agreed that the issue is with Go package management and generally an issue with forking Go projects.

@cwinkler the reason I did not want to include satoris package as a dependency and rather copy it into the project was to make it easier for people to use the package as it requires no dependencies. Copying code into the project rather than including as a dependency has been recommended as an approach where possible by some in the go community and that is what I was trying to do here. Perhaps using internal is not the best approach. Open to discussion on how to deal with this matter.

from go.geteventstore.

Since the EventID isn't necessarily a UUID I find it a bit odd to provide it automatically if an empty string is passed to NewEvent(). In order to know what kind of IDs are pushed to EventStore the User should provide his own ID.

But that are just my 2 cents. I'm fine with it as it is, my only problem was go's weird package management. As this is sorted out I can start implementing projection management into the client.

from go.geteventstore.

from go.geteventstore.