use of internal uuid package causes errors in forks

[cwinkler]

Hi,

if someone wants to fork this package it throws an error on compiling/testing in the forked folder

package github.com/forkinguser/go.geteventstore
imports github.com/jetbasrawi/go.geteventstore/internal/uuid: use of internal package not allowed

I can't see the usefulness of including the satori/go.uuid package in the repository. A better solution would be to import the original package or getting rid of it completely requiring the user to provide a uuid on firing events.

Regards,

Chris

[jetbasrawi]

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

[setyven]

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

[cwinkler]

@setyven yeah this should work, thank you.

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

[jetbasrawi]

Thanks all,

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

[jetbasrawi]

@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.

[cwinkler]

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.

[jetbasrawi]

In general UUIDs are used. This is the 99th percentile case i would imagine. Although you could use any ID I have never actually seen an example. The method allows you to use your own ID. I feel it is a good user experience to have this generated for you. I will give some thought to your suggestion though and check I am not being blinkered.

…

On Thu, Jan 19, 2017 at 4:54 PM, Christoph Winkler ***@***.*** > wrote: 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. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHw6we6990bkCq2XaPNIBVNuHTFPGvFks5rT5VbgaJpZM4LPE3u> .