Remove deprecated arguments and functions

[jgabry]

closes #409

Submission Checklist

• Run unit tests
• Declare copyright holder and agree to license (see below)

Summary

Removes deprecated arguments and functions in preparation for v1.0.

Copyright and Licensing

Please list the copyright holder for the work you are submitting
(this will be you or your assignee, such as a university or company):
Columbia University

By submitting this pull request, the copyright holder is agreeing to
license the submitted work under the following licenses:

• Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
• Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

[jgabry]

@andrjohns @SteveBronder Is there any reason we'd want to do another release before 1.0? If not then we can just merge this into the master branch in preparation for 1.0. If we want to do a release before 1.0 then I guess this shouldn't go into master yet.

[jgabry]

I made a list of the user-facing stuff that's being removed. I guess it's listed under cmdstanr 0.8.1.9000 since that's the placeholder we use for the next release, but it's really for version 1.0

[jgabry]

I think this is now ready for review.

(The failure on macOS-latest (devel) is unrelated and seems to be happening with all PRs - it's some issue with testing a few of the message from install_cmdstan())

[andrjohns]

Just one of the comments can be updated, otherwise LGTM thanks!

[jgabry]

@andrjohns If we merge this one into master then the next release will remove all the deprecated functionality. Do you have a preference waiting to merge this until we're ready to do v1.0 or just going ahead and merging it now? Depends on whether we want to do a release before v1.0 with whatever is currently on master.

[andrjohns]

@andrjohns If we merge this one into master then the next release will remove all the deprecated functionality. Do you have a preference waiting to merge this until we're ready to do v1.0 or just going ahead and merging it now? Depends on whether we want to do a release before v1.0 with whatever is currently on master.

Ahh yeah that's a tricky one. Hmm I think if we're confident that the next release is going to be v1.0 and not a bugfix/patch (I think that should be the case anyway) then it should be ok, otherwise it might be a bit of a pain cherry-picking.

I'd vote for going ahead with the merge. I'm planning to sort out the num_threads handling for the MCMC multi-chain setup later this week, and I think that was the last nice-to-have on the v1.0 list?

[jgabry]

I'm planning to sort out the num_threads handling for the MCMC multi-chain setup later this week, and I think that was the last nice-to-have on the v1.0 list?

That would be great, thanks! If you're able to handle the multi-chain stuff, I think the other things we wanted to do for v1.0 are relatively straightforward compared to that:

1. Improve Handling of cpp_options #1022, which was not straightforward, but @katrinabrock already did the hard work (we just need to make sure we understand and are ok with all the code changes)

2. @SteveBronder mentioned accounting for new column in pathfinder output due to Feature/reduce mem pathfinder stan#3325

3. Limiting v1.0 to cmdstan >= 2.35, in which case we could extend Expand default RTools toolchain usage to all R versions #1065 to remove even more toolchain related code, right? (If people want to use older CmdStan versions they could always install an older cmdstanr from GitHub)

So those are all either mostly done already (1) or relatively simple changes to make (2, 3).

[andrjohns]

Limiting v1.0 to cmdstan >= 2.35, in which case we could extend #1065 to remove even more toolchain related code, right? (If people want to use older CmdStan versions they could always install an older cmdstanr from GitHub)

Oh yeah, we could remove all of the additional utilities for installing gcc/mingw32-make through pacman as well. Then we can also drop the fix = TRUE option from check_cmdstan_toolchain() (might have to deprecate that first still though, since it's pretty widely used).

I think we can also remove all of the R3.x toolchain handling as well, since CmdStan is now requiring c++17 and the Rtools35 toolchain barely supports c++14