papaja's scope 🤔: Split up package

[DominiqueMakowski]

Seeing the recent great developments and support for more models etc., I was wondering about the scope of the package, as it seems that it's composed of two core sets of features, 1) producing APA-formatted documents (theme-wise) and 2) formatting statistical results (in particular tables) following APA's guidelines. While they could be seen as overlapping in their end-goal (to have APA-compliant documents), they rely on different "fields" and R expertise, one being everything that has to do with rmarkdown, knitting, pandoc, pdfs etc. and the other more of R stats models post-processing.

Given my very biased experience, it seems that users tend to use mostly one or the other aspect of papaja; some use it just for the theme and others mainly for the postprocessing of models (for instance, without ever knitting the docs). Thus, I wonder if you ever considered for instance splitting the package into two more defined ones, or whether you think for example that these two "aspects" of papaja cannot be decoupled?

Just wanted to hear your thoughts on this ☺️

[crsh]

Hi Dominique, I'm not sure it's true that most user use only one or the other of these components of the package. That said, I have indeed considered splitting the package up for better maintainability and more modular usecases:

• variable_labels-related functions are a useful and could be used in other contexts and so should be in their own package (maintained by @mariusbarth) which papaja imports. See tinylabels
• Functions for formatting and reporting statistical results (apa_print(), apa_table(), and the plot functions), as you mention are a separable unit and some users may want to use them in other contexts.
• The document templates und formats (apa6_pdf() et al., revision_letter_pdf()) and the corresponding Lua-filters could become a more lightweight package.

Is this what you had in mind?

[jvcasillas]

I have also thought a lot about this. Mainly because I use papaja to prepare my manuscripts (going on 5 now!), but I have always used my own plots and custom functions for formatting tables and inserting results directly into prose. I don't really have much to add to the conversation at this point, but I wanted to mention that I think modularizing papaja in the way outlined above makes a lot of sense to me. It may also make it easier for users to contribute to specific issues/enhancements moving forward.

[DominiqueMakowski]

@crsh that's indeed what I roughly had in mind ☺️

Following @jvcasillas comment, it's true that for instance I've experienced sometimes some difficulties in installing or updating papaja (related to latex chenaningans), and so it could be a bit annoying for users that don't care about the knitting and just want the postprocessing. And like @jvcasillas, as I'm also a user of only the document knitting part, we too could benefit from a lighter package devoted to that (though this is not a big issue imo).

Anyway, feel free to close this issue, and thanks again for your very useful work 😁

[DominiqueMakowski]

On top of the conceptual reasons for a potential splitting, I just realized now (after a painful round of reinstalling & updating 😅 ) that splitting would allow to have a more efficient dependencies' management. For instance, the "document templates & knitting" module wouldnt require dependencies like broom (which has itself tons of dependencies - through tidyverse), which would make the module lighter and more stable :)

[mutlusun]

Hello,
I think splitting up the package and allowing the user to opt-in what is needed sounds very good to me! For example, I use the package markdown template (and thus all the nice automatic conversion stuff) and the apa_table function. For everything else I write custom print methods around functions from the parameters and the performance package. I would like to use some default print_apa_anova functions (or something similar) but in my experience there is always an edge case the functions doesn't handle (certain input or output).

I really love the combination of the papaja rendering, the apa_table function, and the output provided by the parameters and performance packages. Thus, I would really like to opt-in specific parts I want to use.

[tstenner]

I'm not sure it's true that most user use only one or the other of these components of the package.

I mainly use papaja to create markdown tables and inline results for my models (afex/mixed, emmeans) and convert them with pandoc to the target format.
I haven't used the templates, as I mostly copy the tables and results into my colleagues' word documents or e-mails.

Even if most users used both parts, separating them makes it easier to release incremental updates to one of the packages without forcing users to upgrade the other half.