-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bootstrap helper from renv.lock #5
Comments
that would be an amazing addition please feel free to code it up 😁 |
maybe I will wait until you commit your recent drafts into new remote branch :-) |
I think a challenge here is to first list only the required packages that are actually called by the user using If we have the list of packages that are actually called by the user, and pass that to fetchzip() (or rather, fetchzips() which handles multiple packages see: https://github.com/b-rodrigues/rix/blob/d505382ad8ef759a8257227a19043e228a6d70dd/R/find_rev.R#L203 then that should be simple enough I think. |
I'll also have a look at how {renv} implements the snapshotting. |
directionality: renv => nix |
way of interfacing renv: via |
I implemented the 'dumbest' version of this in my fork for personal use generating default.nix files from projects with renv.lock files. For the couple of projects with big renv.lock files I've tried it out on I've had to delete any packages installed from github from the list as these, expectedly, cause build errors. Also the This may be something for it's own issue but here are the logs for the V8 build issue:
|
Hey that's pretty neat, I actually wanted to implement exactly this, just listing the packages from an renv.lock file without handling any versions, and call this the "fast" method (while handling github packages though). And then have an "accurate" method that would, ideally, deal with versions. As for V8, thanks for letting us know, I confirm it's currently broken, and you don't seem to be the only one bitten by it: NixOS/nixpkgs#339861 the fix will soon be merged to master, in the meantime you should be able to use the recommend commit from that thread as the |
Thanks for the info on V8 @b-rodrigues. Happy clean it up a little and open a PR if you want the "fast" approach in upstream while people figure out the details of a more complete solution. should be pretty easy to add a check for github remotes that removes them by default and throws a warning. |
I’d be more than happy! But I don’t think we should remove the packages, but handle them instead. For example, here is the latest echarts4r from Github:
We need to provide |
OK interesting I'm still a nix packaging noob - easy enough to extract that repo info from the renv.lock file but I'm not certain what to do with it after that... I added a function to get the R version from the lock file and, for now, an option to filter out packages the source of which is not "Repository" to my fork. |
You can pass github packages to
|
Ah cool I missed that. The question is then what is the best interface for this? Following on with my current approach I would make 4 functions 1 for each argument, this seems cumbersome, but doesn't involve changing the behavior of Alternately an argument could be added to Then what would be the desired behavior of this argument if it is set and one of the existing ones is also set? Should the existing arguments supersede the values supplied by the Maybe add 3 arguments to
Adding If |
I think this should be a completely separate function called |
OK sounds good - what do you think of that function having arguments which allow you to override things from the renv file or do you think it best to discourage this by design? I believe renv can capture local packages - I tried it out a while ago when I was using a locally developed package in another project I think it just stored the path somewhere I'll check how it did it exactly. |
I don't think we should override the renv.lock file, but perhaps we should generate the actual R call to |
As an option to facilitate debugging or as the default behavior? - I'd lean towards the former. |
Agreed |
I've got a version of When renv installs a local package it's expecting a path to a local source folder not a compressed built package like I need to write some tests to check it handles things OK when the inputs stray from the 'happy path' but the basics are there. |
Looks very nice, that's amazing! If you allow me a little pre-review:
Thank you once again, this looks really promising! |
Sorry to interrupt your discussion. I just wanted to say that i think that this conversion from renv to rix is super important for many users I think. I am reading your book Bruno about reproducible pipelines in R (which is great and very much needed for reproducible data science in R ) and came across this issue. |
I've added the @mihem all I'm really doing here with this "fast"
because I've added the ability to detect and attempt to build packages recorded as coming from github and gitlab remotes. Its not checking that the versions of the packages installed from nix match those in the renv.lock file - I think that will take quite a lot more work. This explicitly installs all of the transitive dependencies of the primary dependencies of your project. These would be installed anyway but the transitive dependencies could be implicit as they are represented in the nix derivations of the primary dependencies. So whilst you don't need to explicitly list them it doesn't really do any harm to do so. At least a I understand it. |
@RichardJActon Well it's still very useful, evenif it's not much more than this one liner. So great work :) |
I'm currently thinking about having exact versions of packages and am experimenting a bit but there are some issues:
I'm trying to see if I can fork nixpkgs and have all CRAN packages versions in there, and backport fixes as well. But it's not that easy because there are a lot of moving parts. Another issue is that I would like to guarantee that it works for Linux and macos and that adds macos specific headaches as well |
The 'not all versions of all R packages being in nixpkgs' thing was why I really wasn't sure where to start when trying to do an 'accurate' version of this, I've not checked if all versions of R are available. A hack for when a specific version is needed that's not in nixpkgs could be to get that version from a remote but this wouldn't necessarily solve problems where the package won't build because of some system dependency issue. This doesn't generalize well so I'd say it's better addressed by some like what @b-rodrigues suggests but may help people fix individual environments. |
Hey @b-rodrigues , I thought it would be nice for people to be able to transition from a {renv} env to a nix setup in individual projects. For this, a helper that simply parses JSON in
renv.lock
and grabs the packages for therix::rix()
r_pkgs
arg would be straight-forward to implement. If useful, I am happy to draft a PR addressing it.The text was updated successfully, but these errors were encountered: