Where is this package used?

[szhorvat]

I mistakenly posted the following at bioc/Rigraphlib#1 Seeing that this package is under libscran partially answers my question. The original post follows below.

---

Hi @LTLA,

We just noticed this package and I am wondering which other packages rely on it, both to keep an eye on what issue may arise, and also just to see who uses igraph.

Be aware that in-memory igraph_t data structures shouldn't be operated on by different versions of the igraph C library. This sort of compatibility cannot be guaranteed, even between bugfix versions. Graphs can still be safely transferred through their edge list.

---

Some comments:

# Skipping the optional dependencies.
options <- c(options,
    "-DIGRAPH_BISON_SUPPORT=0",
    "-DIGRAPH_FLEX_SUPPORT=0"
)

This has no effect, I suggest removal. Bison/Flex won't be used for as long as you are using the release archives (as you are doing now).

---

options <- c(options, "-DIGRAPH_WARNINGS_AS_ERRORS=OFF")

This is reasonable as a pre-emptive measure, but I'm wondering if you've run into real issues. If you ever see a warning that would be turned into an error with default settings, please open an issue in the igraph bug tracker, as we want to fix such issues quickly.

---

BTW we should get back to the C++ interface project. My work on it has stalled, partly due to lack of time, and partly due to being over-ambitious and trying to be compatible with STL algorithms, which likely won't be possible.

[LTLA]

We just noticed this package and I am wondering which other packages rely on it, both to keep an eye on what issue may arise, and also just to see who uses igraph.

Currently, exactly one other package relies on it: scrapper. Originally, I didn't even have a separate Rlibigraph library, and I was building libigraph.a in scrapper's configure step; but I ended up hacking it out into a separate package for modularity + convenience + because I was told to.

You may have already figured out the context, but to give a summary: scrapper is just a thin R wrapper around my various C++ libraries, some of which in turn rely in the igraph C code - hence the creation of Rlibigraph to provide a ready-to-link binary. I did ponder whether the igraph R package could make a similar binary available to linking, but that's a pretty big commitment for such a niche use case, so I thought that would be too much to ask.

Another consideration was to align Rlibigraph to the BioC release schedule, so that we can control the update frequency. This is particularly relevant for projects like the live-compiled OSCA book where small changes to the results of the clustering algorithms (e.g., cluster 3 becomes cluster 6) can cause annoying discrepancies between the results and the text.

Be aware that in-memory igraph_t data structures shouldn't be operated on by different versions of the igraph C library.

Sure. Bioconductor's release schedule should make sure that the same static binary is used in all release packages. Might need to manually bump downstream packages to trigger a rebuild if we have an urgent patch in BioC-release, but this is a pretty rare event.

This has no effect, I suggest removal. Bison/Flex won't be used for as long as you are using the release archives (as you are doing now).

Oh good to know, thanks.

This is reasonable as a pre-emptive measure, but I'm wondering if you've run into real issues. If you ever see a warning that would be turned into an error with default settings, please open an issue in the igraph bug tracker, as we want to fix such issues quickly.

I don't recall any recent issues on my machines, aside from that one time with Emscripten that I already posted on the igraph forum. As you say, it's just a pre-emptive measure so that R CMD INSTALL doesn't fail for other users with more recent toolchains that emit more warnings.

BTW we should get back to the C++ interface project. My work on it has stalled, partly due to lack of time, and partly due to being over-ambitious and trying to be compatible with STL algorithms, which likely won't be possible.

Yeah I didn't do anything more on it, still getting by with my little raiigraph library. From the scrapper perspective, the ambition is very limited; all it needs is the RAII behavior. I haven't looked at your interface in a while but I suspect that it will also satisfy my requirements. I guess I could ship your interface headers with Rlibigraph; that would incentivize me to start dogfooding by actually using it in downstream code.