Documentation clash with network candidate 1.20.0

[CarterButts]

OK, we have folded in Pavel's proposed changes to network, which make a lot more things generic. revdepcheck suggests no major issues, except that networkDynamic shows the following:

 ```
 S3 methods shown with full name in Rd file 'network.extensions.Rd':
   ‘get.edgeIDs.active’ ‘get.edges.active’ ‘get.neighborhood.active’
   ‘is.adjacent.active’
 
 The \usage entries for S3 methods should use the \method markup and not
 their full name.
 See chapter ‘Writing R documentation files’ in the ‘Writing R
 Extensions’ manual.
 ```

This is because get.edgeIDs, get.edges, get.neighborhood, and is.adjacent are now S3 generics. Thus, R thinks that get.edges.active is a method, and is upset at the docs.

The fix I have used for the same kind of issue in the sna package has been to just write the command as if it is a method, e.g.

\method{as.edges}{active}(blah blah)

This seems to calm down the CRAN checks, at least for now.

I can try to implement a fix, or someone else can do so....

[skyebend]

This is because get.edgeIDs, get.edges, get.neighborhood, and is.adjacent are now S3 generics. Thus, R thinks that get.edges.active is a method, and is upset at the docs.

My (very vague) memory is that this collision is why we didn't implement the generics in network a long time ago. @CarterButts are you sure the issue is limited to documentation, won't it also cause dispatch issues looking for the active class? or will it still find the correct function as long as we don't have an active class?

[CarterButts]

I was indeed concerned about downstream problems, but I think we should be OK so long as the code explicitly calls the full function name. (Otherwise, various things in the sna package would have broken a long time ago.) I.e., if you call as.edges.active, then you should get that function per se, and will never call as.edges. But we should test before I commit! I created a branch, BTW, that has the doc change. The proposed version of network is now the master, so if you check it out, you'll have the changes.

FWIW, I just ran R CMD check --as-cran on networkDynamic with the changes made and the new network package installed, and I got no errors. But I will also experiment some more.

[CarterButts]

So far, so good - with the new network loaded, I am able to run the examples on the relevant methods without issues....

[CarterButts]

BTW, I also realized when making the change that we had already done this for some other functions in an earlier iteration (e.g., network.dyadcount). AFAIK, that has not caused problems, so hopefully we are also in the clear here.

[CarterButts]

(I also created a pull request for the proposed change.) @krivit, do you want to chime in on any of this? It is based on your proposed network change....

[CarterButts]

Hey, hate to bug folks - I know everyone is super busy - but network is going to get pulled from CRAN very soon if I don't push an update. I can go ahead if we think that the fix I proposed works, or if there's another fix, but obviously I don't want to create any downstream issues by integrating the new generics; I can roll it back if we must. It looks like it should be safe after the documentation change, but I don't want to run roughshod over any concerns (since that rarely goes well!). @skyebend, @krivit, do you have thoughts on it?

[sgoodreau]

It sounds to me as if you've done due diligence, @CarterButts, but I will download and try out some of the code base involving EpiModel now.

[sgoodreau]

OK, all of my checks went well - no errors or weird changes in model behavior.

[CarterButts]

Awesome. OK, I think we'll roll with Pavel's changes - need to push, so that the package doesn't get pulled. Have to run a few last CRAN checks, but hope to do so tonight.

[CarterButts]

Pushed to CRAN. Assuming it goes through, they will presumably come knocking about the doc issue. (Also, I note that the new tests are also doing a much more anal job of URL verification. Not sure if networkDynamic will be impacted, but if so some minor cleanup might be needed.)

[skyebend]

Thank you Carter. Looks like the "Note" has shown up on CRAN, but no alarming warnings yet.

Version: 0.11.5
Check: Rd \usage sections
Result: NOTE
  S3 methods shown with full name in Rd file 'network.extensions.Rd':
    ‘get.edgeIDs.active’ ‘get.edges.active’ ‘get.neighborhood.active’
    ‘is.adjacent.active’
  
  The \usage entries for S3 methods should use the \method markup and not
  their full name.
  See chapter ‘Writing R documentation files’ in the ‘Writing R
  Extensions’ manual.

I'm staring the upgrade marathon..

[CarterButts]

Cool. I hope it will be smooth! At least the revdep check packages are getting better - that was always the worst. But CRAN is always full of surprises. :-/ Thanks!

…

On Sun, Feb 8, 2026 at 11:29 AM Skye Bender-deMoll ***@***.***> wrote: *skyebend* left a comment (statnet/networkDynamic#27) <#27 (comment)> Thank you Carter. Looks like the "Note" has shown up on CRAN, but no alarming warnings yet. Version: 0.11.5 Check: Rd \usage sections Result: NOTE S3 methods shown with full name in Rd file 'network.extensions.Rd': ‘get.edgeIDs.active’ ‘get.edges.active’ ‘get.neighborhood.active’ ‘is.adjacent.active’ The \usage entries for S3 methods should use the \method markup and not their full name. See chapter ‘Writing R documentation files’ in the ‘Writing R Extensions’ manual. I'm staring the upgrade marathon.. — Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJM3GCQGTISMTNG3OVXOAT4K6E7VAVCNFSM6AAAAACTXWQBFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNRYGA2DOOBUGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[skyebend]

Working through cran updates

• checking S3 generic/method consistency ... NOTE
  Mismatches for apparent methods not registered:
  is.adjacent:
  function(x, vi, vj, na.omit, ...)
  is.adjacent.active:
  function(x, vi, vj, onset, terminus, length, at, rule, na.omit,
  active.default)

get.edgeIDs:
function(x, v, alter, neighborhood, na.omit, ...)
get.edgeIDs.active:
function(x, v, onset, terminus, length, at, alter, neighborhood,
rule, na.omit, active.default)

get.edges:
function(x, v, alter, neighborhood, na.omit, ...)
get.edges.active:
function(x, v, onset, terminus, length, at, alter, neighborhood,
rule, na.omit, active.default)

get.neighborhood:
function(x, v, type, na.omit, ...)
get.neighborhood.active:
function(x, v, onset, terminus, length, at, type, rule, na.omit,
active.default)
See section 'Registering S3 methods' in the 'Writing R Extensions'
manual.

which I think is pointing out that ordering of the arguments and "..." don't align, which will probably require a shallow but breaking refactor to rearrange the argument order of all of the networkDynamic functions.

I think I abandoned this before because I was afraid this was going to break every dependency that relied on argument order 😟

[skyebend]

Not surprisingly, changing argument order for the core network functions breaks most of the tests because it is common that they are specified without named arguments to functions.

I think we can assume this break reverse depends, i.e. EpiModel, tergm. and probably lots of downstream user code
@smjenness @krivit are we ready for a big cascading refactor? I'm not sure we really have a choice at this point if cran is forcing this. I'm not familiar enough with R ecosystem anymore to know if it is feasible to go back to network and try another approach. @CarterButts