Provide contribution development installation guidelines about easystats HOT 8 CLOSED

Hey @DominiqueMakowski it's been a while and I've restructured my thinking of this question.

In short, how do you isolate the development version of each package you are working on? Do you use renv? If so, do you have separate environments for each package, or some chaotic web of all of them? Or is there no isolation and your forks are easystats... so to speak...

from easystats.

ooooops, it seems like I've missed this issue altogether, my bad!! 😬

• Issue of installation: yes this has been is an issue, because of the fast development pace and because some of the packages are still not on CRAN (but getting there). Basically, as all packages depend on one another, it pretty much requires to have everything updated at all times, which can be annoying. I am confident that this issue will disappear further as the ecosystem gets stabilized.

I'm guessing there's an alternative in which I can fork and then clone every single easystats package

That's a good question. I don't know how the others work and would be curious to hear. AFAIK, what I do is the following:

First, I have github desktop (never managed to get used to git 💁‍♂), and a folder called "easystats" (that is in my dropbox, so it gets automatically updated at least across all the different machines I am using). In this easystasts folder, I have cloned all the easystats repos, so I have a folder for each package.

Now, for instance, recently I wanted to update parameters to do some edits. So what I do is I open github desktop, "fetch" the corresponding repo, which updates my local folder from github. Then I open parameters.Rproj and click on "build" which basically installs/updates the package in my R.

However, as it sometimes happens, this threw an error, saying "parameters" (the new version I was trying to install) requires insight > 0.8.1, which I didn't have (because Daniel updated the requirements and I didn't update insight). So I closed R, fetched/updated the insight repo, built the updated insight, and then built parameters again.

However, if I hadn't used/updated for a certain period of time, I usually do a global update, so I fetch all the folders from github (note that as I am usually on the dev branch, I make sure to click on "update from master" because some crazy people commit directly to master, which results in the dev being behind master), and then re-build all the packages, in the following order: insight, bayestestR, performance, parameters, and the rest.

It might sound like a tedious process, but either I got used to it, or it's not that tedious once you mastered the github fetching -> building sequence.

I don't know if there's any better or simpler way of getting around that, though, curious to see how others do @strengejacke @mattansb @IndrajeetPatil

from easystats.

I would recommend following, if you want to use the easyststs package:

1. install each single package from GitHub, starting with insight, bayestestR, parameters, performance, effectsize, modelbased, see, then correlation and report.

2. now it should be possible to install easystats from GitHub.

I'm using GitHub desktop and git integration in RStudio. Usually, I open GitHub desktop and leave it open in the background for a while. After some minutes, you see which packages have new commits, so you can pull all changes.

As a user, you probably will never need to clone the repositories. Once you've installed easyststs, you can simply use install_easystats_latest() to get the latest updates from GitHub. Or you do nothing and wait for official CRAN updates. When you load the library (library(easyststs)), you will be informed which packages are up to date and which have newer versions on CRAN.

from easystats.

Btw, once you have installed easyststs, and want to contribute, simply update all packages from GitHub as described above, then fork the package you need, and simply file an PR. I think this is the easiest way of contributing of you have no direct write access.

from easystats.

How isolate production from development?

I don't do that. Stable versions on CRAN, development versions on GitHub. Though the GitHub versions of the packages I maintain are usually "stable" ;-) , it's just that they probably depend on changes in the other GitHub repos. But, as I said, simply use install_easystats_latest() after starting RStudio, and it should be ok.

from easystats.

Thanks all for the feedback. It's more or less answered my question.

The issue with install_easystats_latest is that it's not transparent how it interacts with existing local git repositories, in terms of your R environment. If I have my own forks of all easystats packages, and then call that command, and go back and start building my local versions, I assume it's overwriting the version called from install_easystats_latest?

I was anticipating a more complex approach, where core development versions (i.e., forks of each package on dev branch) could be isolated in a virtual environment. This would ensure it is easier to actively develop a package alongside current/stable versions of all deps. That way, when I need to use a 'stable' version (i.e., to reproduce bugs reported in issues, or for work purposes), I could simply use the CRAN version. The trouble was/is that renv doesn't seem to have an intuitive way to deal with the complexities of co-dependent packages like you see in easy-stats.

@DominiqueMakowski, a challenge that is also magnified for contributions from my perspective is that I don't feel totally comfortable working directly with the upstream easystats repository itself (in fact, I imagine everyone other than perhaps core team in theory should be on their own forks). It's not a big issue, but I do need to drop to the command line to pull upstream, or make my forks off upstream at time of editing.

I think what I will be working towards next instead (to expedite my development time) is simply have all easystats packages in a single directory, and have a script that can automatically ensure the local dev branch is up to date with upstream/dev (assuming no edits have been made).

I will say my thoughts above are probably a reflection of my desire for perfection in face of complexity; rather than a pragmatic approach to GSD.

I will close this for now, however if you do have another method @mattansb @IndrajeetPatil feel free to reopen and comment of course.

from easystats.

I was anticipating a more complex approach, where core development versions (i.e., forks of each package on dev branch) could be isolated in a virtual environment. This would ensure it is easier to actively develop a package alongside current/stable versions of all deps.

I think this is partly due to the fact that we have no background in software dev or computer science, to me "virtual envs" are black magic, and 'til now I managed by basically updating/installing everytime as any user could do.

That being said, I'm open and curious to see what other approaches are, if they are indeed simpler (but as we said the process is quite straightforward and to be honest, now you need less and less to re-update all the easystats packages as they are getting more and more mature).

a challenge that is also magnified for contributions from my perspective is that I don't feel totally comfortable working directly with the upstream easystats repository itself (in fact, I imagine everyone other than perhaps core team in theory should be on their own forks)

I can understand, in that case wouldn't it work to have your own fork and then updating it from dev, and the making a PR to dev?

I think what I will be working towards next instead (to expedite my development time) is simply have all easystats packages in a single directory, and have a script that can automatically ensure the local dev branch is up to date with upstream/dev (assuming no edits have been made).

Let us know how it goes! But again, I wouldn't worry too much about breaking stuff and all, that's what the dev branch is for. And worst-case scenario we can revert. And worst-case worst-case scenario something is broken and no biggie, we are still in a development phase so it can happen ☺️

from easystats.

The issue with install_easystats_latest is that it's not transparent how it interacts with existing local git repositories

Not at all. It just installs packages, like install.packages(), and it does not change any local repositories. It's just that when you work on parameters, which requires the latest GitHub version of insight installed locally, you just run install_easystats_latest and can then work with the repositories if you want to make changes.

and go back and start building my local versions, I assume it's overwriting the version called from install_easystats_latest?

Yes. But that's intended anyway.

from easystats.