I don't know if it is a bug, but it certainly a issue

[yuanqingye]

To reproduce the bug
Create an r file with these lines(you don't need to run these lines, since renv by default catch the package use):

renv::install("nnet")
library(nnet)
nnet::which.is.max(c(1,2,3))

Then run renv::status() nothing happens
I guess that is due to renv knows nnet is kind of system package, so it didn't care if it used or not.
Actually I was wondering what is the complete set renv knows as "we know this package is installed by default"; it should include base,stats... but I don't have the complete set. I really want to know this set, since right now I notice renv inited project is not start from a white sheet, it starts from some package it recognize as by default installed. If anyone knows this default package list or the document record this default package list, let me know.

Here is what magic happens:
1if you using renv::record("nnet@7.3-19"), to manually add this default package into renv.lock, then using renv::status() it will tell you this nnet package is not used(which is not true)

2 if you also add renv::record("base@4.3.0"), and run renv::snapshot(), renv will inform you the package base and nnet will be removed from renv.lock but with nnet along it won't notify you delete it.

I guess that is some thing related some package should be treated as default, but when we manually add it to renv.lock, strange things happens.

[Kevin Ushey]

Sorry, but I'm not able to reproduce what you're describing. If I do the following:

renv::init()
renv::install("nnet")

Then, include a file in the project like:

library(nnet)

then I see:

> renv::status()
The following package(s) are in an inconsistent state:

 package installed recorded used
 nnet    y         n        y   

See ?renv::status() for advice on resolving these issues.
> renv::snapshot()
The following package(s) will be updated in the lockfile:

# CRAN ----------------------------------------------------
- nnet   [* -> 7.3-19]

Do you want to proceed? [Y/n]: y

- Lockfile written to "~/scratch/renv-nnet/renv.lock".

I really want to know this set, since right now I notice renv inited project is not start from a white sheet, it starts from some package it recognize as by default installed. If anyone knows this default package list or the document record this default package list, let me know.

Please read the documentation from ?renv::init.

[yuanqingye]

Sorry, but I'm not able to reproduce what you're describing. If I do the following:

renv::init()
renv::install("nnet")

Then, include a file in the project like:

library(nnet)

then I see:

> renv::status()
The following package(s) are in an inconsistent state:

 package installed recorded used
 nnet    y         n        y   

See ?renv::status() for advice on resolving these issues.
> renv::snapshot()
The following package(s) will be updated in the lockfile:

# CRAN ----------------------------------------------------
- nnet   [* -> 7.3-19]

Do you want to proceed? [Y/n]: y

- Lockfile written to "~/scratch/renv-nnet/renv.lock".

I really want to know this set, since right now I notice renv inited project is not start from a white sheet, it starts from some package it recognize as by default installed. If anyone knows this default package list or the document record this default package list, let me know.

Please read the documentation from ?renv::init.

Can you try it in a new package instead of a new project?
I think that may make a difference.
If still can't reproduce, then since I have build some packages managed by renv and I have installed nnet inside one of them.
And if a package is installed, then it may be in cache, it may have different behavior than brand new project to install.

By the way, I am running Rstudio in windows 10 professional, it may be irrelevant, or may be useful info for you.

[Kevin Ushey]

Can you try it in a new package instead of a new project?

If you're working within an R package project, then renv will only look at the DESCRIPTION file (as that's the canonical way for R packages to declare their package dependencies). See https://r-pkgs.org/description.html for some prose on the topic.