Closed kevinushey closed 1 year ago
It is not feasible. I suggest you debug pkgdepends instead of pak, pak is a very thin layer over pkgdepends.
Out of curiosity why isn't it possible?
@kevinushey Today I discovered this helpful trick to get a trace dump of the pak process:
options(callr.traceback = TRUE)
# Make the pak subprocess throw an error
...
# Gets you in a recover-like REPL
pak:::pkg_data$remote$debug()
Out of curiosity why isn't it possible?
It is just messy, and there is no way to make sure that it behaves the same way. You'd be constantly wondering if the behavior you see is real or not.
I would rather put this effort into making it easier to debug the background process.
Usually debugging pkgdepends is fine, because pak barely does anything.
Btw another option is to attach to the background process, once there is one:
❯ R -q
❯ pak:::remote(function() Sys.getpid())
[1] 58762
❯ pak:::pkg_data$remote$attach()
RS 58762 > Sys.getpid()
[1] 58762
RS 58762 >
# <CTRL+C>
❯
Since I am not going to work on this any time soon, I am going to close this now.
It would be helpful (when trying to debug
pak
behaviors) to allow users to tellpak
to perform installation in the current process, rather than a remote process. Would that be feasible?Alternatively, do you have any recommendations for debugging usages of
pak::pkg_install()
in general?