adapt vec_compRelSEM() + tests to semTools 0.5-8

[TDJorgensen]

I have made some changes to semTools::compRelSEM() that break your vectorization of its output. This PR addresses those issues, conditional on the user's installed version of semTools. Could you please send a new version to CRAN as soon as you can? I cannot send the semTools update to CRAN until this is resolved.

[TDJorgensen]

Thank you for your quick action! I still have to wait on one more PR, then for both of your packages to be on CRAN before I can submit the new semTools to CRAN before it is archived on 23 February (which would have downstream consequences for its dependencies like yours). Hopefully, we can avoid that complication.

[sfcheung]

@TDJorgensen , thank you for making the changes. :) I am working on the submission right now. I will submit the updated version to CRAN today.

[sfcheung]

@TDJorgensen , the updated version is now on CRAN. I checked it locally using both 0.5-7 and 0.5-8 (the GitHub version), and it passed all tests. It also passed all the checks on winbuilder, including on r-devel. However, the first time I submitted it, it failed the pretest on Windows during the incoming check. One of the updated tests got an error. I checked the output, and semTools 0.5-8 was loaded in that test on CRAN. I am not sure why, and I am not sure whether the 0.5-8 loaded during the pretest was identical to the GitHub 0.5-8.

Therefore, I had to disable the tests for now, so it won't affect the submission of semTools to CRAN. After the official 0.5-8 is on CRAN, I will enable the test again in the next submission. If the error still occurs, it will only affect semhelpinghands, not semTools.

[TDJorgensen]

the updated version is now on CRAN

Thanks! Glad that went so quickly.

semTools 0.5-8 was loaded in that test on CRAN

Interesting, I suppose CRAN had my (currently rejected) submission loaded to run those tests.

FYI, you could simply copy my solution from vec_compRelSEM() to conditionally run 1 of 2 versions of that test (your original or my edited one), based on the installed version.

I had to disable the tests for now

I think that might be a better practice anyway. It shouldn't be CRAN's business to run tests that you create for your own development process. Having CRAN (re-)run them costs computing power (making their checks take longer) and can create problems for your reverse dependencies being updated (like this issue). I think there is a way to have your /tests subdirectory only in a branch that is not used to build the package for CRAN submission, or the R package itself can be in a subdirectory of a parent folder for development (like semTools has) where the tests are run. A GitHub Action can be used to automate running those tests without asking CRAN to repeat that process for you.

I'm going to learn more about these alternative workflows in the coming year, while I work with Yves to develop some best-practice guidelines for lavaan-ecosystem extensions. In the meantime, thanks again!