more focused dependency options?

[pearsonca]

I'm using socialmixr in a little analysis, purely for its contact matrix manipulation functionality. Adding socialmixr ended up actually adding 22 package dependencies, which don't really seem relevant to my use of the package. Feels like a lot.

What might be a nice solution here is something like the core calculation(s) (e.g. looking at a single population demography + contact pattern data) extracted into a smixrlite package which provides only the math and none of the (useful, but potentially superfluous for some users) other capabilities. socialmixr could then wrap those core capabilities with the current interface.

[sbfnk]

My main worry here would be the added burden of maintenance with two separate packages (requiring integration tests spanning both packages). Not insurmountable but worth considering if the benefits from splitting outweighs these drawbacks.

That said both the downloading and plotting functions could probably stand on their own and have separate dependencies.

Currently socialmixr has 12 dependencies, which is well within the CRAN limit of 20.

[sbfnk]

A split that I could see make sense (and perhaps what you meant initially, @pearsonca) would be one package (socialmixr) that does all the transformation from a survey to a contact matrix, and another one (contactsurveys or the like) that does the interaction with the Zenodo repo and brings in dependencies for downloading/scraping the web interface.

[pearsonca]

A split that I could see make sense (and perhaps what you meant initially, @pearsonca) would be one package (socialmixr) that does all the transformation from a survey to a contact matrix, and another one (contactsurveys or the like) that does the interaction with the Zenodo repo and brings in dependencies for downloading/scraping the web interface.

That's exactly what I want ideally.

However, I was proposing something relative to maintaining backwards compatibility - I just want the mixing, but as written socialmixr also does the other stuff. To maintain backwards compat, one solution would be to introduce a new package which just does the mixing, and then have socialmixr then be a thin wrapper to that package (in addition to continuing to provide the survey-related functionality). I imagine there would also be a use for an independent surveys related data package, and then socialmixr would be a thin wrapper for that as well, but that's not my particular use case.