myglc2 writes: > Pjotr Prins <pjotr.publi...@thebird.nl> writes: > >> On Sat, Jul 30, 2016 at 03:41:50PM -0400, myglc2 wrote: >>> The workaround used by sysops where I work (hospital research lab) is to >>> give notice of R upgrades and to make previous releases available for >>> reference by ongoing projects. IMO, we should consider how the guix R >>> recipe(s) might support a pattern of use like this. >>> >>> I can assure you that if our users do guix pull and invisibly get a new >>> R release, their analyses will from time to time break. So we may want a >>> simple way for them to back down to a previous release. So.. I am >>> thinking it would make sense to keep previous versions of R in the >>> recipe. What do others think? > >> Note, meanwhile, that a new R install does not remove the old packages >> automatically. One way to work older versions is by using guix >> profiles effectively. We introduced Unix modules with Guix, so a >> module would point to a well tested and working profile. Just make >> sure it does not get GC'd at some point. > > This functionality could be adequate in some situations if it can be > made simple to use. Some questions to answer... > > What do you mean by "Unix modules"?
I think Pjotr means environment variables. > How does one "make sure it does not get GC'd"? Keep it in a profile linked to the store. (So once you've installed a version in a profile, Guix will not GC it as long as you haven't removed the profile, or the programs in the profiles and its accompanying generations). > What happens when a user wants something else (e.g., not R) updated? He can just to `guix package --upgrade=<specific-package>'. >> Another way to work it is by using a checked out Guix source tree. > > This is not simple and is beyond the capability of the medical > researchers I have met. I agree. However, when upgrading packages, they can be careful not to upgrade a package. You can do that by `guix package --upgrade --do-not-upgrade=r'. This may seem too difficult as well, but let's consider the alternative: Not upgrading packages upstream. That's what we can already do downstream (simply don't run `guix pull'). I like having the latest versions available in GNU Guix, and when I need an older version, I can find it in the version control system. Kind regards, Roel Janssen
