From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:47477) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iow0F-0006v1-5R for guix-patches@gnu.org; Tue, 07 Jan 2020 16:03:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iow0E-0002O0-79 for guix-patches@gnu.org; Tue, 07 Jan 2020 16:03:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:43496) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iow0E-0002Nr-4F for guix-patches@gnu.org; Tue, 07 Jan 2020 16:03:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iow0E-0005gV-2G for guix-patches@gnu.org; Tue, 07 Jan 2020 16:03:02 -0500 Subject: [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading Resent-Message-ID: Message-ID: From: Roel Janssen Date: Tue, 07 Jan 2020 22:02:13 +0100 In-Reply-To: <87h81ew0aw.fsf@gnu.org> References: <20191212074613.GA11713@zpidnp36> <87wob13mpn.fsf@elephly.net> <20191212100452.GE22717@zpidnp36> <87r210j5kq.fsf@gnu.org> <20200102073536.GA3066@zpidnp36> <87h81ew0aw.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= , Lars-Dominik Braun Cc: Ricardo Wurmus , 38576@debbugs.gnu.org On Thu, 2020-01-02 at 12:43 +0100, Ludovic Courtès wrote: > Hi, > > Lars-Dominik Braun skribis: > > > > An argument in favor of the status quo would be that it allows users to > > > choose between ‘r’ and ‘r-minimal’. Is that a compelling argument? > > reading the documentation I thought this was possible using > > --with-input=r-minimal=r ? > > Yes, good point. > > > > However, if we go that route, we should arrange to not propagate > > > ‘r-minimal’ (it’s intrusive) and instead have ‘kernel.json’ do the right > > > thing. > > I’m not following, sorry. What do you suggest kernel.json should do? > > I was suggesting hard-coding the file name of the ‘R’ executable in > ‘kernel.json’, but I see you already did that in your initial patch. > Sorry for the confusion. > > On second thought, I think propagating R is acceptable in this case > because a Jupyter kernel is a thin wrapper around a programming language > implementation. > > Unless there are objections, I’ll apply your initial patch. > I'm too late, but doesn't this break the kernel for people who have the "full" R in their profile, and therefore expect the "full" R to be available in a Jupyter notebook? Kind regards, Roel Janssen