Will there be trouble compiling spatial_graph on some architectures?

[funkey]

spatial_graph uses witty to compile the C/C++ parts during runtime and load them as a module. witty, in turn, uses cython.

My take is that in environments that can successfully install cython packages that are build at install time, spatial_graph should also compile without issues. The underlying mechanism is the same. It's possible that if someone runs spatial_graph from within an IDE there could be interference with their PATH or other environment variables, which could affect compilation (hi @tlambert03!).

For windows users, that seems to mean that they have to install a compiler (MSVC or MinGW). I'm not familiar with those. Would it be enough to include msvc-runtime in the dependencies?

[tlambert03]

My take is that in environments that can successfully install cython packages that are build at install time, spatial_graph should also compile without issues

yeah, this is definitely true. but i would bet that we'll run into a fair degree of end-user variability here. I would wager that most cython packages now are no longer build-at-install-time. Most of them do (and all definitely should) ship wheels for every platform that they intend to target, precisely because it's a bit too risky to expect that all users will be set up to build a cython package, and if you look around image.sc or stack overflow, you'll see a bunch of people with errors like error: command 'gcc' failed with exit status 1 or error: Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools" when they just try to pip install something for which a wheel wasn't available for their platform. Pretty much everyone ships wheels now (honestly, even for pure python packages where it isn't even necessary).

It's not necessarily a deal breaker, and the simpler you go with regards to the assumptions you make in your source code about system level C/C++ headers or other compile-time dependencies, the more likely it is to work. I just think we'll need to kind of expect there to be occasional issues, and perhaps wait and see just how occasional they are.

Would it be enough to include msvc-runtime in the dependencies?

while that might work, I think it's probably inadvisable, and may well break other packages in the environment. (Python itself is built against specific MSVC versions and bundling a conflicting version could cause conflicts). The main tool that people use to build relocatable wheels on CI (cibuildwheel) itself encourages you to just tell users to download Visual C++ Redistributable themselves. In any case, I think we get input from someone who is actually an expert in python/msvc/windows considerations before doing including a package like that