@anon94023334 I feel like we have completely miss-communicated. I absolutely agree that the best scenario is by far that all packages that extend the Neighborhood.jl interface depend on it, instead of the other way around. This has been clear for me well before even starting Neighborhood.jl, but thank you for clarifying it further.
This is not practically possible at the moment because at least I couldn’t communicate this interface to anyone else outside myself and I do not own any package that does nearest neighbor searches. Of course, this situation is perfectly okay in the open source world, as not everyone might have time, or will, or just care, for some unified API at this very point in time.
Yet, I know that there are several Julia packages (at least some belonging in JuliaDynamics) that have big gains in using Neighborhood.jl API, and I’ve been re-inventing the wheel all this time for many of them, so this it was useful for me to do this now. The interface by itself is useless if you don’t have at least one package participating in this interface… My choices were: do nothing or do what I just did, and instead make the packages part of it.
It is of course my hope that this can change in the future, if more people become interested in this interface and we can go to the original plan of having a FileIO-like interface. But until then, to my understanding, this is the best working alternative. If I am wrong about this, please demonstrate a better alternative on how to go about it! This is the first time I am publishing unified interface for something I don’t actually own, so its really difficult to decide the best course of action. If I actually owned a package about nearest neighbors, this interface would already be there and we wouldn’t be having this discussion…