Vendor in kastore.c/h?

[jeromekelleher]

A lot of complexity in the repo layout comes from us using git submodules to bring in the code for kastore, and then do some funky symlinking so that we can use the same code when building the C library and the Python module. #1958 simplifies this a bit, but introduces the problem that we have to update kastore in two different places.

This is quite a bit of complexity in order to, fundamentally, get two files into the repo. We could just copy in these files and be done with it. It would make building the library significantly easier for third parties, because they wouldn't have to worry about kastore also. It also makes it more likely that kastore would be kept up to date in third party code.

I did it like this originally so that it'd be easy to keep kastore up to date, but kastore is stable now and is unlikely the change much, so that motivation isn't really there any more.

The cons of vendoring in like this is that some packagers don't like it and specifically ban it, but I think the degree to which kastore really is a third party dependency is pretty minimal. It's not like anyone else is using kastore beyond tskit.

Any thoughts here, @benjeffery, @bhaller, @molpopgen ?

[bhaller]

As you know, SLiM already does this with both tskit and kastore (and parts of the GSL, and small bits of Boost!). I’m a fan of it, personally, and haven't gotten any pushback about it from anybody. The way SLiM does it with parts of bigger libraries like GSL and Boost is probably somewhat questionable (although I'm still very happy with it in those cases too – it gives me control over when I move to a new version of those dependencies, and makes the build very simple), but for a simple case like kastore it seems like a slam dunk.

[benjeffery]

Sounds good to me, I have spent more than enough time fiddling with symlinks on windows CI to motivate simplifying this.

[molpopgen]

I think this is easier for client code. It may be fickle to handle 2 submodules and make sure that kastore is synced to the same version that tskit expects.

[jeromekelleher]

OK, no contrary opinions sounds like a positive decision to me. I'll make the changes.