dependency on optmatch

[andrewpbray]

Hello, thanks for your work on this wonderful package!

We're using on a project that runs inside a docker container. Traditionally, as we add packages to our project, we add them to the dockerfile and that pretty much works. I was surprised today to see that our project wasn't able to build within a container because of this snippet of code:

library(MatchIt)
grad_matched <- matchit(cal_grad ~ GPA + years_exp + rec, method = 'optimal',
                        distance = 'euclidean', data = grad_job)

Error in matchit2optimal(treat = base::quote(c(`1` = 0L, `2` = 0L, `3` = 0L,  : 
  The package "optmatch" is required.

It's an easy enough problem to solve - we can add optmatch to the dockerfile as well - but I'm curious what drove the decision to put optmatch as a Suggests instead of Imports. This is a question I've thought about for other projects that I've worked on, so I'm interested to hear how y'all are thinking about it.

Thanks!

[andrewpbray]

Ahh, perhaps this was the original reason?

https://github.com/kosukeimai/MatchIt/issues/3

[ngreifer]

Simply speaking, it's because MatchIt only needs optmatch if you are using optimal or full matching, which are not necessarily the right methods to use for a given application. Any packages that are not required for all methods (or for the default method) are in Suggests and not Imports because we should not require users to install every package when they are only using one matching method. This also keeps the package robust in case a package is removed from CRAN, which has happened in the past. I believe the package would be fully compliant if any of the Suggested packages were removed from CRAN; one could still build the package and use the matching methods that do not depend on that package.

The help page for each matching methods lists the packages that are required for that method to work.

[andrewpbray]

That's helpful - thanks.