Jamovi and GGIR package

[J P G]

  Is the GGIR package available for Jamovi?  

[Vincent van Hees]

I am not familiar with Jamovi. If Jamovi is something that requires package maintainers to make an active effort to make their packages available in Jamovi, then I would be happy to do that as a paid consultancy. If no active effort is needed then I think you should ask Jamovi about adding GGIR.

Best regards,

Vincent

Dr. Vincent van Hees | Independent consultant | https://accelting.com/

On Tuesday, 21 May 2024 at 5:02 PM, J P G <joaopau...@gmail.com> wrote:

Is the GGIR package available for Jamovi?

--
You received this message because you are subscribed to the Google Groups "R package GGIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to RpackageGGIR...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/RpackageGGIR/0bd920cb-faaa-4695-8cb4-9acd06b3214cn%40googlegroups.com.

[J P G]

Hi Vincent,

 

Thanks for getting back to me. I went to jamovi's forum to look for answers to your questions. Jamovi's co-founder, Jonathon Love, answered my questions, and I've pasted his answer below.

 

 

generally speaking, modules don't require too much maintenance once they're developed, but it comes down to what breaking changes occur in upstream R packages ... if your module has a small amount of dependencies, then your module will probably continue to work indefinitely. there are lots of modules that haven't been touched (by developers) in years, and they continue to function.

which makes sense, based on tinyverse principles:

https://www.tinyverse.org/

modules with lots of dependencies tend to have a higher maintenance burden ... because it's not just their dependencies, but their dependencies dependencies. taking a look at GGIR, that imports quite a few packages.

this means there's an even chance you'll need to revisit the module every 12 months or so (we bump the R version, and move forward the R snapshot about once every 12 months ... this usually happens when we update, say, 2.4 to 2.5) ... and it's at these time points it's worth investigating whether breaking changes have occurred in any of your modules dependencies, and adjusting your module to suit.

 

I don't have the funds to sponsor you or Accelting to create a package for jamovi. So, my question for now is whether you would ever consider developing a ggIR package for jamovi. I'm new to jamovi, but I can already see that it's an excellent and capable platform.

 

This is the link to jamovi’s tutorial

https://dev.jamovi.org/

 

Best,

Joao

[Vincent van Hees]

Hi Joao,

Regarding the feedback you received from Jonathan Love: Most of GGIR is intentionally written in base R. Only when strictly necessary I have added dependencies to other packages. GGIR has a lot of functionalities (19000 lines of code) so the number of dependencies could be argued to be proportionally small. Note that most of GGIR's dependencies are only needed for very specific sub-functions, most GGIR users do not user. Further, I always check that the new dependency is well designed and actively maintained to avoid the kind of problems Jonathan refers to. Also, I put high priority on keeping the GGIR API consistent to preserve consistency for users. Despite all that GGIR still evolves following the needs from the research community. As a result, some maintenance effort will be needed on a Jamovi-GGIR app to keep it up to date with GGIR.

So, my question for now is whether you would ever consider developing a ggIR package for jamovi. 

Jamovi seems a great environment for running statistical analysis in a SPSS GUI style. However, I do not directly see how Jamovi will enhance working with GGIR. GGIR is an elaborate data processing pipeline subject to ongoing improvements. Tying such an evolving package into a Jamovi dashboard interface is like asking for consistency problems. So, I think the best way to use Jamovi with GGIR is to first run GGIR either as R script in Jamovi or in Rstudio and then to apply Jamovi to the csv reports as created by GGIR.

By the way if you are interested in using GGIR via a GUI then you may want to check out https://github.com/habitus-eu/HabitusGUI which is a Shiny app I designed with the need for flexibility in mind. It intentionally does not have many buttons but instead centres around the config.csv file which you can interactively edit before running an analyses.

So, what I need is a convincing pitch why a specific Jamovi app to work with GGIR would enhance the GGIR experience and does not complicate ongoing GGIR development.

Best,

Vincent

To view this discussion on the web, visit https://groups.google.com/d/msgid/RpackageGGIR/53d2b120-c883-47be-977c-c0136811ff8en%40googlegroups.com.

[joaopau...@gmail.com]

Hi Vincent,

 

Thanks for clarifying. I look forward to our GGIR training session in July.

 

Best regards,

Joao