Run rix_init after rix #231

b-rodrigues · 2024-06-28T12:34:46Z

This PR would run rix_init each time rix is executed

b-rodrigues · 2024-06-28T13:19:27Z

we could also add this: #230 (comment)

EDIT: done

b-rodrigues · 2024-06-28T19:50:08Z

ready for review

rix_init() is now always called when using rix() with create_missing
rix() creates the project path folder if it's missing
install.packages() is redefined in the .Rprofile if running inside a Nix session to throw an error
documentation was adapted

philipp-baumann · 2024-06-28T22:58:06Z

ready for review

* rix_init() is now always called when using rix() with create_missing

* rix() creates the project path folder if it's missing

* install.packages() is redefined in the .Rprofile if running inside a Nix session to throw an error

* documentation was adapted

@b-rodrigues i have to think about it and sleep over it. We really should recommend users to make use of rix::rix_init(), but i see a couple of problems mixing it into rix() because of the hidden effects. Will respond a bit later with concrete examples.

philipp-baumann · 2024-06-29T15:57:46Z

todos like discussed on matrix :-)

add message_type option and also forward it to rix_init() called.

…age (one for testing)

b-rodrigues · 2024-07-01T12:16:54Z

todos like discussed on matrix :-)

add message_type option and also forward it to rix_init() called.

Implemented, but with a twist: "verbose" is too chatty when rix_init() is called by rix(), so if the user chooses "verbose", it gets "downgraded" to "simple".

philipp-baumann · 2024-07-01T14:24:42Z

todos like discussed on matrix :-)

add message_type option and also forward it to rix_init() called.

Implemented, but with a twist: "verbose" is too chatty when rix_init() is called by rix(), so if the user chooses "verbose", it gets "downgraded" to "simple".

That doesn't make sense to me. If I choose"verbose", I explicitly want "verbose", and consistent behavior across all functions, here rix_init(). The default is "simple", and one either wants to have all outputs or none as an alternative.

b-rodrigues · 2024-07-01T14:29:28Z

That doesn't make sense to me. If I choose"verbose", I explicitly want "verbose", and consistent behavior across all functions, here rix_init(). The default is "simple", and one either wants to have all outputs or none as an alternative.

The issue is that "verbose" for rix_init() prints many lines that push the lines from rix() out of the console. So my thinking was that if I'm using "verbose" with rix(), I'm more interested to what rix() has to say. I feel like then having rix_init() message_type set to "simple" would be enough for "verbose" for rix().

But if I'm calling rix_init() directly with "verbose", then yeah, I'd like to know everything rix_init() has to tell me.

philipp-baumann · 2024-07-01T14:29:39Z

@b-rodrigues currently, we still don't get the expected behavior if we already have an .Rprofile that was generated before outside of nix. How would we know if a user called rix_init() before or not. One might have just a custom .Rprofile but without the necessary code to limit .libPaths() to nix store paths. In one situation it would work while in the second it gets overlooked and we still have interference from the user library.

b-rodrigues · 2024-07-01T14:30:41Z

@b-rodrigues currently, we still don't get the expected behavior if we already have an .Rprofile that was generated before outside of nix. How would we know if a user called rix_init() before or not. One might have just a custom .Rprofile but without the necessary code to limit .libPaths() to nix store paths. In one situation it would work while in the second it gets overlooked and we still have interference from the user library.

Right, we need to check for existence of an already existing .Rprofile!

Check for existence of already existing .Rprofile and warn user.

philipp-baumann · 2024-07-01T14:39:48Z

@b-rodrigues currently, we still don't get the expected behavior if we already have an .Rprofile that was generated before outside of nix. How would we know if a user called rix_init() before or not. One might have just a custom .Rprofile but without the necessary code to limit .libPaths() to nix store paths. In one situation it would work while in the second it gets overlooked and we still have interference from the user library.

Right, we need to check for existence of an already existing .Rprofile!
* [ ]  Check for existence of already existing .Rprofile and warn user.

how do you know its generated?

That doesn't make sense to me. If I choose"verbose", I explicitly want "verbose", and consistent behavior across all functions, here rix_init(). The default is "simple", and one either wants to have all outputs or none as an alternative.

The issue is that "verbose" for rix_init() prints many lines that push the lines from rix() out of the console. So my thinking was that if I'm using "verbose" with rix(), I'm more interested to what rix() has to say. I feel like then having rix_init() message_type set to "simple" would be enough for "verbose" for rix().

But if I'm calling rix_init() directly with "verbose", then yeah, I'd like to know everything rix_init() has to tell me.

rix::rix() does two things and I would want to exactly know what it does. I see two options, either we delete

@b-rodrigues currently, we still don't get the expected behavior if we already have an .Rprofile that was generated before outside of nix. How would we know if a user called rix_init() before or not. One might have just a custom .Rprofile but without the necessary code to limit .libPaths() to nix store paths. In one situation it would work while in the second it gets overlooked and we still have interference from the user library.

Right, we need to check for existence of an already existing .Rprofile!
* [ ]  Check for existence of already existing .Rprofile and warn user.

Why don't we add a rprofile_action argument to rix::rix()? We default to create_missing, but also signal other options. How do we know whether rix::rix_init() .Rprofile is taking action?

b-rodrigues · 2024-07-01T15:13:48Z

@b-rodrigues currently, we still don't get the expected behavior if we already have an .Rprofile that was generated before outside of nix. How would we know if a user called rix_init() before or not. One might have just a custom .Rprofile but without the necessary code to limit .libPaths() to nix store paths. In one situation it would work while in the second it gets overlooked and we still have interference from the user library.

Right, we need to check for existence of an already existing .Rprofile!
* [ ]  Check for existence of already existing .Rprofile and warn user.
how do you know its generated?

I check for the sentence "File generated by rix_init" and don't show the warning if it is found.

Why don't we add a rprofile_action argument to rix::rix()? We default to create_missing, but also signal other options. How do we know whether rix::rix_init() .Rprofile is taking action?

we could, but I think that simply providing a default that works largely 95% of the time with a warning in the rare cases it doesn't could be enough?

philipp-baumann · 2024-07-01T15:40:52Z

for message_type = "quiet", it should not warn and message:

> rix(
+     r_ver = "latest",
+     r_pkgs = c("dplyr", "ggplot2"),
+     system_pkgs = NULL,
+     git_pkgs = NULL,
+     local_pkgs = NULL,
+     ide = "code",
+     project_path = "_test",
+     overwrite = TRUE,
+     print = FALSE,
+     message_type = "quiet",
+     shell_hook = NULL
+ )
Warning message:
In rix(r_ver = "latest", r_pkgs = c("dplyr", "ggplot2"), system_pkgs = NULL,  :
  

### .Rprofile file already exists. You may want to call rix_init(profile_action = 'append') manually to ensure correct functioning of your Nix environment. ###

philipp-baumann · 2024-07-01T16:53:07Z

profile_action -> rprofile_action. We could include something like "Please see ?rix_init for an explanation and further options" in the message. Would make sense to include project_path as first arg.
suggestion: use warning() with .call = FALSE to declutter.

b-rodrigues · 2024-07-01T16:59:22Z

for message_type = "quiet", it should not warn and message:

> rix(
+     r_ver = "latest",
+     r_pkgs = c("dplyr", "ggplot2"),
+     system_pkgs = NULL,
+     git_pkgs = NULL,
+     local_pkgs = NULL,
+     ide = "code",
+     project_path = "_test",
+     overwrite = TRUE,
+     print = FALSE,
+     message_type = "quiet",
+     shell_hook = NULL
+ )
Warning message:
In rix(r_ver = "latest", r_pkgs = c("dplyr", "ggplot2"), system_pkgs = NULL,  :
  

### .Rprofile file already exists. You may want to call rix_init(profile_action = 'append') manually to ensure correct functioning of your Nix environment. ###

should we keep this warning, even if quiet ? That message only appears if .Rprofile already exists and wasn't created by rix_init, so it would appear very rarely and I'd say in these cases the users would like to be informed. What do you think ?

philipp-baumann · 2024-07-01T18:27:14Z

for message_type = "quiet", it should not warn and message:

> rix(
+     r_ver = "latest",
+     r_pkgs = c("dplyr", "ggplot2"),
+     system_pkgs = NULL,
+     git_pkgs = NULL,
+     local_pkgs = NULL,
+     ide = "code",
+     project_path = "_test",
+     overwrite = TRUE,
+     print = FALSE,
+     message_type = "quiet",
+     shell_hook = NULL
+ )
Warning message:
In rix(r_ver = "latest", r_pkgs = c("dplyr", "ggplot2"), system_pkgs = NULL,  :
  

### .Rprofile file already exists. You may want to call rix_init(profile_action = 'append') manually to ensure correct functioning of your Nix environment. ###

should we keep this warning, even if quiet ? That message only appears if .Rprofile already exists and wasn't created by rix_init, so it would appear very rarely and I'd say in these cases the users would like to be informed. What do you think ?

yeah, you have a good point. Let's keep it like this. Technically it's a warning and it is good to inform at least, while message_type infers that it is messaging with message() or cat() (its fair to use cat() like we do in a lot of other places in {rix}. I find message() a bit too aggressive in RStudio because it is also in red and assuming many people use RStudio cat is much nicer for many messages.

Something that just came to my mind: If there is no problem, I would expect that rix::rix() gives me a short message that the nix expression was generated and written todefault.nix at project_path = <project_path>, given message_type = "simple" (changed the default to "simple" in c7e124c).

It would nice to have something like this implemented before we merge; currently, there is none:

> devtools::load_all(".")
ℹ Loading rix
> rix(
+     r_ver = "latest",
+     r_pkgs = c("dplyr", "ggplot2"),
+     system_pkgs = NULL,
+     git_pkgs = NULL,
+     local_pkgs = NULL,
+     ide = "code",
+     project_path = "_test",
+     overwrite = TRUE,
+     print = FALSE,
+     message_type = "simple",
+     shell_hook = NULL
+ )

b-rodrigues · 2024-07-01T18:30:42Z

R/rix.R

+                                     "simple", message_type))
+
+      if(message_type != "quiet"){
+        message("\n\n### Successfully generated `default.nix` and `.Rprofile` ###\n\n")


Regarding your comment bout a successful run, wouldn't this be it ?

philipp-baumann · 2024-07-01T19:00:19Z

proposition, after 31399a9 we have

> rix(
+     r_ver = "latest",
+     r_pkgs = NULL,
+     system_pkgs = NULL,
+     git_pkgs = NULL,
+     local_pkgs = NULL,
+     tex_pkgs = NULL,
+     ide = c("other", "code", "radian", "rstudio", "rserver"),
+     project_path = ".",
+     overwrite = TRUE,
+     print = FALSE,
+     message_type = "simple",
+     shell_hook = NULL
+ )


### Successfully generated `default.nix`. Keeping `.Rprofile` generated by `rix::rix_init()`###

Bruno Rodrigues added 2 commits June 28, 2024 14:34

rix_init_after_rix

262a242

better warning if default.nix exists already

2f8c143

b-rodrigues requested a review from philipp-baumann June 28, 2024 13:00

Bruno Rodrigues added 2 commits June 28, 2024 21:09

shimed install.packages()

a23b433

Adapted documenattion

00f6dfb

Bruno Rodrigues added 6 commits July 1, 2024 10:20

Merge remote-tracking branch 'origin/master' into rix_init_after_rix

dff3231

documentation

3caf8ad

Merge remote-tracking branch 'origin/master' into rix_init_after_rix

7a3325f

handle situations where two description files are present in the pack…

23be343

…age (one for testing)

documentation

de04bee

added message_type

04fda64

Bruno Rodrigues added 2 commits July 1, 2024 15:15

documentation

dfb32fd

removed old code

93a7fb9

b-rodrigues mentioned this pull request Jul 1, 2024

Prevent users from using install.packages() #230

Closed

check for existence of .Rprofile

2b62be4

handling cases where .Rprofile was already generated by rix_init()

2f1cfb0

use message_type = "simple" as default (consistency in rix)

c7e124c

b-rodrigues commented Jul 1, 2024

View reviewed changes

philipp-baumann added 2 commits July 1, 2024 20:36

please CRAN and R

b9b1e31

update docs

31399a9

philipp-baumann and others added 6 commits July 1, 2024 21:02

use file.path() for file paths

705efef

profile_action -> rprofile_action

26cac1d

message if keeping valid rix_init() .Rprofile

8121ddf

please CRAN

a4387a9

restore default.nix

6bc2e2d

- Changed argument to in rix()

1e5a412

b-rodrigues merged commit e23c9c4 into master Jul 2, 2024
10 of 14 checks passed

b-rodrigues deleted the rix_init_after_rix branch July 2, 2024 06:27

philipp-baumann mentioned this pull request Jul 2, 2024

rix::rix() local_pkgs -> local_r_pkgs #232

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Run rix_init after rix #231

Run rix_init after rix #231

b-rodrigues commented Jun 28, 2024

b-rodrigues commented Jun 28, 2024 •

edited

Loading

b-rodrigues commented Jun 28, 2024 •

edited

Loading

philipp-baumann commented Jun 28, 2024 •

edited

Loading

philipp-baumann commented Jun 29, 2024 •

edited by b-rodrigues

Loading

b-rodrigues commented Jul 1, 2024

philipp-baumann commented Jul 1, 2024

b-rodrigues commented Jul 1, 2024

philipp-baumann commented Jul 1, 2024

b-rodrigues commented Jul 1, 2024 •

edited

Loading

philipp-baumann commented Jul 1, 2024 •

edited

Loading

b-rodrigues commented Jul 1, 2024

philipp-baumann commented Jul 1, 2024

philipp-baumann commented Jul 1, 2024 •

edited

Loading

b-rodrigues commented Jul 1, 2024

philipp-baumann commented Jul 1, 2024 •

edited

Loading

b-rodrigues Jul 1, 2024

philipp-baumann commented Jul 1, 2024 •

edited

Loading

Run rix_init after rix #231

Run rix_init after rix #231

Conversation

b-rodrigues commented Jun 28, 2024

b-rodrigues commented Jun 28, 2024 • edited Loading

b-rodrigues commented Jun 28, 2024 • edited Loading

philipp-baumann commented Jun 28, 2024 • edited Loading

philipp-baumann commented Jun 29, 2024 • edited by b-rodrigues Loading

b-rodrigues commented Jul 1, 2024

philipp-baumann commented Jul 1, 2024

b-rodrigues commented Jul 1, 2024

philipp-baumann commented Jul 1, 2024

b-rodrigues commented Jul 1, 2024 • edited Loading

philipp-baumann commented Jul 1, 2024 • edited Loading

b-rodrigues commented Jul 1, 2024

philipp-baumann commented Jul 1, 2024

philipp-baumann commented Jul 1, 2024 • edited Loading

b-rodrigues commented Jul 1, 2024

philipp-baumann commented Jul 1, 2024 • edited Loading

b-rodrigues Jul 1, 2024

Choose a reason for hiding this comment

philipp-baumann commented Jul 1, 2024 • edited Loading

b-rodrigues commented Jun 28, 2024 •

edited

Loading

b-rodrigues commented Jun 28, 2024 •

edited

Loading

philipp-baumann commented Jun 28, 2024 •

edited

Loading

philipp-baumann commented Jun 29, 2024 •

edited by b-rodrigues

Loading

b-rodrigues commented Jul 1, 2024 •

edited

Loading

philipp-baumann commented Jul 1, 2024 •

edited

Loading

philipp-baumann commented Jul 1, 2024 •

edited

Loading

philipp-baumann commented Jul 1, 2024 •

edited

Loading

philipp-baumann commented Jul 1, 2024 •

edited

Loading