added nim-ovr

[bluenote10]

No description provided.

[dom96]

Have you seen this? https://github.com/nimious/io-oculus

By the way, any chance I could ask you to rename your package(s) to not contain dashes? That is something that Nimble may have to enforce sooner rather than later. By convention, the name of your package's module should be the same as the name of the package.

[bluenote10]

Oh nice, last time I searched for bindings I couldn't find anything (maybe because I did not yet fully understand nimble). Well, was a good exercise anyway.

Sure, I'll rename the packages. My worry was simply that a too short name may lead to conflicts like in case of ovr. But isn't it a too dangerous to just name a package "heap"? I guess it is pretty likely that there will be several packages which should have the same name. I guess I'm just missing the package/namespace functionality of C++/Java/Scala here. Any other ideas how to "prefix" modules? Should I put the source in a subdirectory "bluenote" so that it becomes import bluenote/ovr?

[dom96]

You don't need to namespace them. ovr is fine as long as there isn't already a package by that name.

[bluenote10]

The import for io-oculus is import ovr, so this will already cause problems. I guess it is even more dangerous with something like heap: Doesn't this mean that users cannot have their own heap.nim in their sources when the heap package is installed? Even if local sources have precedence over nimble packages this feels very dangerous.

[dom96]

The io-oculus package unfortunately breaks the convention too. I haven't yet made a decision but I think it's likely that Nimble will reject packages which break this convention because of issues like these.

[dom96]

I guess it is even more dangerous with something like heap: Doesn't this mean that users cannot have their own heap.nim in their sources when the heap package is installed? Even if local sources have precedence over nimble packages this feels very dangerous.

That is true. Unfortunately I think that might require an addition to Nim to disambiguate these cases.

[bluenote10]

What if you would just require that there are no sources in the top-level directory? This would require to put the source in a subdirectory corresponding to e.g. the orginazation name and all imports would read import <organization>/<package>.

... but maybe this is not the place for this discussion. For the time being I'll just try to come up with some awkward names to avoid conflicts.

[bluenote10]

I have fixed the names, but I think I'll just open a new PR...