From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: [PATCH] gnu: r: Update to 3.3.1. Date: Tue, 02 Aug 2016 08:00:03 +0200 Message-ID: <871t27678c.fsf@elephly.net> References: <874m77gpll.fsf@gnu.org> <8660rmgbgh.fsf@gmail.com> <20160731040956.GA22271@thebird.nl> <87popup2e9.fsf@gnu.org> <8660rllmur.fsf@gmail.com> <20160801060032.GB26920@thebird.nl> <86eg68cstn.fsf@gmail.com> <874m745kci.fsf@elephly.net> <86wpk0gq8w.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUSkQ-00006U-Ha for guix-devel@gnu.org; Tue, 02 Aug 2016 02:00:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUSkM-0002t0-BU for guix-devel@gnu.org; Tue, 02 Aug 2016 02:00:13 -0400 Received: from sender163-mail.zoho.com ([74.201.84.163]:24802) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUSkM-0002sR-3F for guix-devel@gnu.org; Tue, 02 Aug 2016 02:00:10 -0400 In-reply-to: <86wpk0gq8w.fsf@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: myglc2 Cc: guix-devel@gnu.org myglc2 writes: > Ricardo Wurmus writes: > >> myglc2 writes: >> >>> I imagine that, in the spirit of guix, we also want a user to be able to >>> "help themself" instead of depending on a 'manager.' This would probably >>> require an additional R "package manager component" that is usable by a >>> manager or user. Such a thing would certainly showcase the unique >>> capabilities of guix. >> >> We have importers that generate Guix package expressions from CRAN or >> Bioconductor. Taken one step further we might have a transparent >> wrapper to quickly install any version of a package even if it is not >> yet part of Guix. >> >> This might work like this: >> >> * user issues “guix package --install --via cran gdtools@0.0.3” >> >> * Guix runs the CRAN importe to recursively generate package expressions >> for “gdtools” at the given version. The package does not have to >> exist in Guix yet. The generated package expressions are cached >> somewhere (e.g. ~/.cache/guix/…genomation…). >> >> * Guix loads the newly imported package expressions from >> ~/.cache/guix/…genomation… and tries to build them. >> >> * Optionally, users can take the imported expressions, clean them up and >> send them as patches to us :) >> >> This obviously depends on the quality of the importers, but I think it >> wouldn’t take much effort to make this a reality. > > Could this approach also support earlier R versions? Reasons one would > want this: > > - one comes back to a project after sebatical. Because new R versions > have been installed the analysis gives different results and/or is > broken. > > - one needs to re-run an analysis to reproduce a result or to do > sensitivity studies. > > In such cases it is far preferable, but usually problematic, to > reconstruct the environment in which the anaysis was run. If guix could > be used to do this, it would be a compelling argument for adoption in a > research lab situation. At the institute where I work and where Guix is deployed we never upgrade users packages centrally. Scientists use per-project manifests to keep a list of packages they want to have installed for their current work. After returning from vacation their software is still the same as only they upgrade things. We also encourage them to record the git hash of both package repositories we use (one for Guix upstream and another for our custom Guix BIMSB repo) at the time they instantiate a manifest. We provide a wrapper that essentially just runs “git describe” on the two repos. Given the manifest and the two git hashes a user can reproduce the exact same binary state of a profile. This is more granular than thinking in terms of version numbers as this captures the complete graph of dependencies. >> The main problem with offering magic like this is that it must be >> reliable or else it would just be frustrating users. > > Agreed. But any experienced R user knows that package installation can > be a drama. So it does not have to be perfect to match or exceed user > expectaions. If the user's alternatives are ... > > 1) wait for sysadmin to do it > > 2) give this a shot > > ... most users will happily try pushing this button ;-) This has also been my experience here at the MDC. Some are already using the CRAN importer themselves to install packages via Guix that I haven’t packaged for them yet. (Admittedly, as bioinformaticians they are likely more comfortable with the command line than scientists in other fields.) ~~ Ricardo