name colision

[AntonioMeireles]

hi again

would you consider renaming this great project to something other than plain xhyve to avoid collision with upstream xhyve ? (making it clear that it builds on top of xhyve, simplify forks, etc). something along the lines of xhyve-go / ghyve, would IMHO be a way better fit.

Thanks!

[c4milo]

I did it for convenience when using the library from Go. I believe that weighs in more than collisions when forking or cloning, especially considering that xhyve upstream is not a Go package. I will leave this issue open to gather more feedback from the community.

[c4milo]

Also, when I forked xhyve, my first attempt was to create a static library out of it, in order to retain xhyve project structure as-is, but then I started running into this issue: machyve/xhyve#61 and the only way I could fix that was dumping the C files at the root of the project so that CGO could compile them all, including the bindings, without linking any static library.

[AntonioMeireles]

fwiw i opened this just because as is it is impossible for an user to fork in gh both this and upstream at same time in github without renaming one of them or resorting to tricks like multiple orgs, etc.

anyway not a blocker :-)

[c4milo]

fwiw i opened this just because as is it is impossible for an user to fork in gh both this and upstream at same time in github without renaming one of them or resorting to tricks like multiple orgs, etc.

Exactly the same would happen if this project were a github-made fork from upstream, and you were forking both.

[AntonioMeireles]

techically true but i'd expect most ppl to just fork from one given project and eventually add other 3rd party forks as remotes of their own fork (i'd say that this is the common case for the vast majority). anyway & as i said before not a blocker / deal breaker :-)

[c4milo]

haha, I understand it isn't a deal breaker, I'm just trying to be as fair as I can with your request and to understand better where you are coming from.

techically true but i'd expect most ppl to just fork from one given project and eventually add other 3rd party forks as remotes of their own fork (i'd say that this is the common case for the vast majority). anyway & as i said before not a blocker / deal breaker :-)

Agreed, that's the usual workflow when forks match up on structure. However, in this project I'm trying to favor Go developer's user experience over friendliness to fork or clone when contributing to both mist64/xhyve and hooklift/xhyve. In fact, the contribution process for both is very different. For this library I have outlined the steps here: https://github.com/hooklift/xhyve/blob/master/CONTRIBUTING.md#workflow-for-third-party-code-contributions