Feature Request: Post-install commands

[billdenney]

The request: Can pkgr support post-installation commands that may be specific to a package? In my case, I would like to run Rscript -e 'tinytex::install_tinytex();tinytex::tlmgr_install(pkgs=c("babel-greek", "greek-fontenc", "cbfonts"))' or something very similar to that whenever tinytex is updated.

I think that @dpastoor and I discussed this in person a while ago and the consensus was that the feature was not a fit for pkgr, but I have a new use case, so I wanted to revisit it. I'll fully understand if this is still out of scope.

In yihui/tinytex#237, there is a requirement for installing some TeX packages manually due to an inaccurate expectation from the textgreek CTAN package that fonts will be installed. (I've separately requested from the maintainer of textgreek that he update the dependencies, but given that the last edit to that CTAN package was ~9 years ago, I'm not expecting the change.) The tinytex package will not work with the textgreek CTAN package without the command I mentioned at the top, so I would not have a working installation for this particular use case without the above command.

[billdenney]

@dpastoor, I have a new need along the same feature-request lines: cmdstanr requires install_cmdstan() to be run after installation of the package, and ideally also to have check_cmdstan_toolchain(fix=TRUE), too (https://mc-stan.org/cmdstanr/articles/cmdstanr.html#installing-cmdstan-1).

I assume that you're using cmdstanr. Are you installing it with pkgr, and if so, how are you ensuring that install_cmdstanr() is run?

[dpastoor]

Hey Bill,

Sorry for the delay. The simple answer, is for now there is nothing to guarantee that things like cmdstanr are present, that is left as an exercise to the user.

That being said, this is functionality I really want to design out and implement. Eg I would like pre- and post run hooks both globally and at the pkg level. I also do not know exactly how I want that to look.

# only run if actually installs
post_install:
  cmdstanr:
  - R -e "cmdstanr::install_cmdstanr(); check_cmdstan_toolchain(fix=TRUE)"

But there are all sorts of subtle decisions - that I'm not sure of - should we provide some magic or rely on the user to configure (Eg should R behave like the R settings pkgr has or the users default R - prob both but how to say which one)

My plan is to dig into this during vacation time this summer - including this upcoming weekend, and first step will be a design doc to consider. I'll be sure to rope you in for feedback

[billdenney]

Great!

I would assume that this type problem has been solved many times before, so there should be rich solutions which have thought of most of the pitfalls before. One example that immediately came to mind is how deb works for the Debian and Ubuntu Linux distributions: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

A few items that occur to me for consideration as you're thinking it through:

• Yes, both pre- and post-install actions should be allowed.
• Multiple actions should be possible at each step. In your example above I think that would be multiple lines like - R -e "cmdstanr::install_cmdstanr(); check_cmdstan_toolchain(fix=TRUE)" would be possible under cmdstanr:
• If any command fails, then the entire update should be rolled back. (I do not think that this should be overridden. If there is a failure, then change your yaml file to fix it or remove the step.)
• I agree that both pre-install and post-install should also be possible at the global level.
  • I could imagine something as extreme as installing a specified version of R with pre-installation to build the full environment. (No, I'm not trying to make this into a Docker or ansible/chef replacement, but with the goal of using this for reproducibility, this could be a major reproducibility enhancement.)
• It would probably be easier to have the global pre- and post-install as separate sections rather than trying to put them in with the package pre- and post-install. Perhaps rather than naming yaml sections pre_install and post_install, consider pre_install_global, post_install_global, pre_install_package, and post_install_package. (I could imagine a specific global subsection that is not a valid R package name, like _global_, instead of this suggestion. So, this is only a light suggestion.)

[billdenney]

One more thought related to your comment "only run if actually installs" above:

It would be good if the pre- and post-install commands ran any time an upgrade or installation occurs. One challenge will be that if the package does not successfully install, what should happen about the pre-install command? It would have already run, but if the upgrade does not happen, then the system would be in an indeterminate state (pre- ran, installation did not succeed, post- did not run).

I assume that package-level pre- would only run after the package were successfully found and downloaded so that it would occur at the latest possible time.

I also assume that global-level pre- would occur as long as there were at least one package to install or upgrade, but it would not occur if there were no packages to install or upgrade.

My guess is that you were already there, but I wanted it to be explicit in case it were a missed case.