Update deprecated function calls from other packages

[bockthom]

Description

Some of the functions that we call from other packages are marked as deprecated.
Especially since igraph release 2.0.0, igraph has marked many functions as deprecated. In most cases, the functions have just been renamed. To provide one example, igraph::get.edgelist(...) has been renamed to igraph::as.edgelist(...).
As I assume that, at some point, these functions will become defunct, we should think about renaming them.

We can use this issue to collect deprecated function calls here, if necessary.

In some rare cases, also our contribution guide could be affected by that (e.g., that we recommend/enforce deprecated function calls in our contribution guide.) Thus, we should also check our contribution guide for that when we address this issue.

[maxloeffler]

I have conducted an analysis of the warning messages I retrieved (R: 4.1.2 on my Ubuntu VM). In total I classified 66 warnings into 7 classes:

1. "can't open file" (fixable: mixed)
2. "data length is not a multiple of split variable" (fixable: yes!) This warning actually stems from a "bug" in the implementation of the add.link <-> referenced.by edge list construction. There, we have a dataframe containing all add.link events called add.links and we want to mclapply over it. I used the split(add.links, ...) function for that and that function usually works, that is, if you supply a second parameter that is a vector from 1 to the length of the first parameter. However, to get this vector I used seq_along(add.links), which does return a vector from 1 to 17 in every case since we have 17 columns in an issue event. Therefore, we get the warning that the length of the second parameter is not in line with the length of the first parameter. I experimented a bit and was able to this by replacing the second parameter with seq_len(nrow(add.links)) or seq.int(nrow(add.links)), alternatively.
3. "All formats failed to parse. No formats found." (fixable: no, this is triggered by a test with an explicitly empty network. However, having this warning is senseful and we should not suppress it) There is an issue with project.data$get.data.timestamps(outermost = TRUE) in util-split.R:427. Sometimes this call does return a vector where start is Inf and end is -Inf. A consecutive get.date.from.string call then throws this issue, since Inf and -Inf are not in the correct format for conversion.
4. "no non-missing arguments to min; returning Inf", (fixable: same as 3) This is related to point 3. This warnings is being thrown inside the get.date.timestamps call. There reason for this is that the date.timestamps are empty
   This is because the test these issues come from is a test that operates on an empty network.
5. "All formats failed to parse. No formats found." 2.0. (fixable: no, this is triggered by tests that explicitly test incorrect bins. These warnings are complicated to remove and serve a purpose) This issue comes from splitting by invalid bins time based (the test splits explicitly wants to split by invalid bins) (these bins are not in correct date format)
6. "All formats failed to parse. No formats found." 3.0 (fixable: same as 5) Same as above just splitting by bins instead
7. "igraph deprecation warnings" (fixable: yes) These should be easy to fix

The reason I put fixable: unsure for some warning categories is that it would be technically possible to catch the reasons for these warnings and then throw our own warnings instead but I don't think it is worth it. I will of course address the fixable ones in the PR for this issue :)

Edit: update fixability

[maxloeffler]

I have had a look at all the "cannot open file" warnings. Contrary to your intuition, none of them originate from JIRA stuff. Here is a list of sources:

1. "nonexistent.file", The test describes this case as "Empty timestamps from invalid file". We could only fix that by creating an "invalid file" that does exist but is empty or malformated. This will then likely cause other warnings.
2. "reading empty commit interactions", This test is labeled with "Read the empty commit-interactions data.". Same as above.
3. "no bots", There are some tests that call get.sample.network(). This method builds an example network that includes authors as vertices. When reading authors, we also try to read the bots.list file which does not exist in this case.
4. "comparison", In one test, we compare two networks, one with the commit.interaction parameter set one without. When setting the parameter to TRUE, we try to read the interactions from a file that does not exist in this case. It is also not needed, we only care about the parameter.

In summary, none of these warnings come from JIRA. None of these warnings are easily fixable using conventional approaches, as they all read from files that are just not present in the demo data. All of these tests could be fitted with suppressWarnings calls, however, im not sure if that is intended.

[maxloeffler]

I also had a look at all warnings across the different R versions we support and found that the warnings are consistent and do not change over versions, i.e., all R versions display the same amount of warnings with the same content. Also I have noticed, that the CI runners produce one additional warning that does not come when running it on my machine, for which the reason is, that the CI runners do not support UI and therefore Tk is not available. I think we can disregard this warning savely.

[bockthom]

I have had a look at all the "cannot open file" warnings. Contrary to your intuition, none of them originate from JIRA stuff. [...]

Ok, then we are talking about non-existing files that are actually expected to be non-existing in the test. In these cases, we should keep the warnings and not try to avoid them.

In summary, none of these warnings come from JIRA. None of these warnings are easily fixable using conventional approaches, as they all read from files that are just not present in the demo data. All of these tests could be fitted with suppressWarnings calls, however, im not sure if that is intended.

No, we should not suppress any warnings there.
Regarding JIRA: As the test data contain JIRA data, the default configuration does not end up in warnings regarding missing JIRA data... Nevertheless, as mentioned by @hechtlC last week, in practice, we usually have only GitHub or JIRA data but not both of them in parallel. Therefore, we still should change the default to just "GitHub" to avoid tens or hundreds of warnings during practical use of coronet.

[maxloeffler]

Oh okay, then I just missed the point there. I will update the default then 🤓

[maxloeffler]

I have had a look at some of the tests that fail because of the sorting of the c("jira", "github") list. I found that at least in the splitting related tests that the order of sources does actually mess a lot with the order of events. The reason that I see for this is in read.issues. There the sources are being read from file then rbinded together. So when jira data is read first, it is above the github data and vice versa. But then - later - the dataframe is sorted by date attribute which causes jira and github issues to be interwoven and depending on the order of readin, the events will obtain different ids (indexes). In all splitting tests, we do comparison by doing something like

data$issues[rownames(data$issues) %in% c(18, 24:26, 44:47), ],

Therefore, all splitting tests would require thoughtful fixing when we decide to follow that route. Honestly, I think it is not tooooo much work, a couple of hours though. 😅

[bockthom]

Hm, that's bad. If it would just be reordering, it should not be that a big problem. But fixing the indices is a tedious and potentially error-prone task, I certainly understand that.

What would be the alternatives? Do you have any other ideas how we can circumvent this problem? But even if there are alternatives, we should not tweak the tests just to make them align with outdated and wrong design choices. In the end, the tests should mimic how our actual data processing is assumed to work in practice.

So, before we take a final decision, could you please provide us with some details which/how many tests are affected?
I'd guess that all the splitting tests are affected, maybe also many tests of the data module that deal with reading/accessing issue data. But is there anything else which also breaks? What about network construction, for instance? Just to get an overview.