Marcin

I created an alternate PR where we use `callr` instead of `future` and `promises`. https://github.com/insightsengineering/teal/pull/1255 Testing it now

The simplified version that does not use `future`+`promise` combination can be found in here and is ready for testing https://github.com/insightsengineering/teal/pull/1255 Waaay more simplified, however we lost track of the possibility...

This issue is basically using `pak::create_lockfile` that creates a file of all dependencies and their source addresses for future reproducibility. This process pulls and installs all packages during the creation...

Hey @gogonzo , hey @pawelru maybe it is safer or more robust to go as @vedhav proposed, which is: app developer pre-computes the `.lockfile` (with `pak::lockfile_create()`. We can create functions...

Hey, I created an alternative PR https://github.com/insightsengineering/teal/pull/1232 where `pak::lockfile_create()` is run in a parallel process to the shiny session using `futures` + `shiny::ExtendedTask()`

Also summarized issues I see with our own support of the lockfile creation https://github.com/insightsengineering/teal/pull/1232#issuecomment-2126867283

> It would be a hard no if we cannot guarantee reproducibility. It's always hard to guarantee 100% reproducibility, even with pak, which states this in their own documentation https://github.com/insightsengineering/nestdevs-tasks/issues/55#issuecomment-2125661627...

@gogonzo 1,2,3 this is the part that looks like we already figured out in the comments. I think the biggest question is if we really use `future` and `future::plan` in...

I see that @pawelru provided his thoughts about on how to make use of pak https://github.com/insightsengineering/teal/pull/1232#discussion_r1611901282

> I guess pak is better in a long term - https://github.com/rstudio/renv/issues/1210 My personal opinion is that `pak` is better for installation, when a `lockfile` exists, but `renv` is better...