Move dev packages out from renv.lock and dependencies.R

[radbasa]

1. box.lsp is imported by rhino. This shows up in renv.lock.
2. treesitter and treesitter.r are hard-coded into dependencies.R. These show up in renv.lock.

These are developer-use packages and should not be included in renv.lock. or dependencies.R.

[kamilzyla]

Related issue: #343. There are other dev-only packages which are included in Rhino's DESCRIPTION (e.g. lintr, styler, testthat).

[dawiegriesel]

I am receiving docker build errors that I believe is related to this. Only started after upgrading to [email protected].

Any idea how to resolve this? Quite urgent at the moment. Even reverting back to [email protected] does not solve the problem.

[ 7/16] RUN sudo -u shiny Rscript -e 'renv::restore(clean = TRUE)':
0.666 # Bootstrapping renv 1.0.7 ---------------------------------------------------
0.666 - Downloading renv ... OK
8.330 - Installing renv ... OK
16.00
16.41 - One or more packages recorded in the lockfile are not installed.
16.41 - Use renv::status() for more details.
16.41 Error in loadNamespace(x) : there is no package called ‘box.lsp’
16.41 Calls: options ... loadNamespace -> withRestarts -> withOneRestart -> doWithOneRestart
16.41 Execution halted

[TymekDev]

{renv} does have profiles. However, with the way things are currently structured, {rhino} can't make a use of them.

That's because app.R contains rhino::app(), so it's not possible to deploy the app without {rhino} itself. So even if we had a different {renv} profile for production, then {rhino} would have to be recorded there (and as such {lintr}, {styler}, etc.).

I think it comes down to separating runtime and dev-time benefits of {rhino}. A couple ideas:

1. Move dev dependencies to Suggests
2. Sever the tie between app.R and {rhino} and make the deployed app not depend on {rhino}
   1. There are still things like rhino::log, though
3. Add a build step that would handle 2. - similarly to how things are in JS world: build dist/ -> publish
   1. This could have an added benefit of not having to manually run build_* functions and having app.min.* files checked into git
   2. Git-backed deployment becomes an issue?
4. Have a separate package, e.g. {rhino.runtime} that would be a collection of the things used within the app - not only during the development