all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading
@ 2019-12-12  7:46 Lars-Dominik Braun
  2019-12-12  9:41 ` Ricardo Wurmus
  0 siblings, 1 reply; 12+ messages in thread
From: Lars-Dominik Braun @ 2019-12-12  7:46 UTC (permalink / raw)
  To: 38576

* gnu/packages/cran.scm (r-irkernel): Absolute path to R binary
[propagated-inputs]: Generate proper search paths by adding r-minimal
---
 gnu/packages/cran.scm | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/gnu/packages/cran.scm b/gnu/packages/cran.scm
index 765747ea3b..c54a076014 100644
--- a/gnu/packages/cran.scm
+++ b/gnu/packages/cran.scm
@@ -12414,6 +12414,12 @@ running IRkernel session.")
                        "--name" "ir"
                        "--prefix" out
                        (string-append out "/site-library/IRkernel/kernelspec"))
+               ;; Record the absolute file name of the 'R' executable in
+               ;; 'kernel.json'.
+               (substitute* (string-append out "/share/jupyter"
+                                           "/kernels/ir/kernel.json")
+                 (("\\[\"R\",")
+                  (string-append "[\"" (which "R") "\",")))
                #t))))))
     (inputs
      `(("jupyter" ,jupyter)))
@@ -12423,6 +12429,8 @@ running IRkernel session.")
        ("r-evaluate" ,r-evaluate)
        ("r-irdisplay" ,r-irdisplay)
        ("r-jsonlite" ,r-jsonlite)
+       ;; sets R_LIBS_SITE, so R can actually find this package (IRkernel)
+       ("r-minimal" ,r-minimal)
        ("r-pbdzmq" ,r-pbdzmq)
        ("r-repr" ,r-repr)
        ("r-uuid" ,r-uuid)))
-- 
2.20.1

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading
  2019-12-12  7:46 [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading Lars-Dominik Braun
@ 2019-12-12  9:41 ` Ricardo Wurmus
  2019-12-12 10:04   ` Lars-Dominik Braun
  0 siblings, 1 reply; 12+ messages in thread
From: Ricardo Wurmus @ 2019-12-12  9:41 UTC (permalink / raw)
  To: Lars-Dominik Braun; +Cc: 38576


Hi Lars-Dominik,

> * gnu/packages/cran.scm (r-irkernel): Absolute path to R binary
> [propagated-inputs]: Generate proper search paths by adding r-minimal
> ---
>  gnu/packages/cran.scm | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/gnu/packages/cran.scm b/gnu/packages/cran.scm
> index 765747ea3b..c54a076014 100644
> --- a/gnu/packages/cran.scm
> +++ b/gnu/packages/cran.scm
> @@ -12414,6 +12414,12 @@ running IRkernel session.")
>                         "--name" "ir"
>                         "--prefix" out
>                         (string-append out "/site-library/IRkernel/kernelspec"))
> +               ;; Record the absolute file name of the 'R' executable in
> +               ;; 'kernel.json'.
> +               (substitute* (string-append out "/share/jupyter"
> +                                           "/kernels/ir/kernel.json")
> +                 (("\\[\"R\",")
> +                  (string-append "[\"" (which "R") "\",")))
>                 #t))))))
>      (inputs
>       `(("jupyter" ,jupyter)))

This part looks fine to me, though I wonder if that’s what users of this
package would expect.  Is there an expectation that the effective R is
defined by the environment?  Or would that not work anyway?

> @@ -12423,6 +12429,8 @@ running IRkernel session.")
>         ("r-evaluate" ,r-evaluate)
>         ("r-irdisplay" ,r-irdisplay)
>         ("r-jsonlite" ,r-jsonlite)
> +       ;; sets R_LIBS_SITE, so R can actually find this package (IRkernel)
> +       ("r-minimal" ,r-minimal)
>         ("r-pbdzmq" ,r-pbdzmq)
>         ("r-repr" ,r-repr)
>         ("r-uuid" ,r-uuid)))

This doesn’t look right to me.  It seems wrong for any R package to
propagate R itself.  The R_LIBS_SITE variable is “attached” to
“r-minimal”, so when that is installed R will find the r-irkernel
package.  Am I missing something?

--
Ricardo

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading
  2019-12-12  9:41 ` Ricardo Wurmus
@ 2019-12-12 10:04   ` Lars-Dominik Braun
  2019-12-12 19:13     ` zimoun
  2019-12-19 22:47     ` [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading Ludovic Courtès
  0 siblings, 2 replies; 12+ messages in thread
From: Lars-Dominik Braun @ 2019-12-12 10:04 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: 38576

Hi Ricardo,

> This part looks fine to me, though I wonder if that’s what users of this
> package would expect.  Is there an expectation that the effective R is
> defined by the environment?  Or would that not work anyway?
it’s what python-ipykernel does – without explanation though. I’m not an R
expert, so I’m unsure whether any R installation from the environment (which
could be user-installed in $HOME) would be able to load this plugin or just the
one it was “built” for. This change assumes the latter.

> 
> > @@ -12423,6 +12429,8 @@ running IRkernel session.")
> >         ("r-evaluate" ,r-evaluate)
> >         ("r-irdisplay" ,r-irdisplay)
> >         ("r-jsonlite" ,r-jsonlite)
> > +       ;; sets R_LIBS_SITE, so R can actually find this package (IRkernel)
> > +       ("r-minimal" ,r-minimal)
> >         ("r-pbdzmq" ,r-pbdzmq)
> >         ("r-repr" ,r-repr)
> >         ("r-uuid" ,r-uuid)))
> 
> This doesn’t look right to me.  It seems wrong for any R package to
> propagate R itself.  The R_LIBS_SITE variable is “attached” to
> “r-minimal”, so when that is installed R will find the r-irkernel
> package.  Am I missing something?
If r-minimal is not installed, the kernel will simply not work and thus
render this package useless. That’s why I would consider it a dependency.

Cheers,
Lars

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading
  2019-12-12 10:04   ` Lars-Dominik Braun
@ 2019-12-12 19:13     ` zimoun
       [not found]       ` <20191213073056.GG22717@zpidnp36>
  2019-12-19 22:47     ` [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading Ludovic Courtès
  1 sibling, 1 reply; 12+ messages in thread
From: zimoun @ 2019-12-12 19:13 UTC (permalink / raw)
  To: Lars-Dominik Braun; +Cc: Ricardo Wurmus, 38576

Hi,

Thank you for your patch!

On Thu, 12 Dec 2019 at 13:36, Lars-Dominik Braun
<ldb@leibniz-psychology.org> wrote:

> > > @@ -12423,6 +12429,8 @@ running IRkernel session.")
> > >         ("r-evaluate" ,r-evaluate)
> > >         ("r-irdisplay" ,r-irdisplay)
> > >         ("r-jsonlite" ,r-jsonlite)
> > > +       ;; sets R_LIBS_SITE, so R can actually find this package (IRkernel)
> > > +       ("r-minimal" ,r-minimal)
> > >         ("r-pbdzmq" ,r-pbdzmq)
> > >         ("r-repr" ,r-repr)
> > >         ("r-uuid" ,r-uuid)))
> >
> > This doesn’t look right to me.  It seems wrong for any R package to
> > propagate R itself.  The R_LIBS_SITE variable is “attached” to
> > “r-minimal”, so when that is installed R will find the r-irkernel
> > package.  Am I missing something?

> If r-minimal is not installed, the kernel will simply not work and thus
> render this package useless. That’s why I would consider it a dependency.

Hum? it is true for any R package, isn't it?
I mean, all the R packages needs R to work but R is not a dependency.

We can discuss if a R package has to propagate R itself or not.
But it is not how the R packages are usually defined in Guix; AFAIU.
To stay coherent, "r-minimal" should not be propagated or I also miss
something. :-)

Currently, I usually type "guix install r r-pkg" and not "guix install r-pkg".

All the best,
simon

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Package runtime dependencies (see bug#38576)
       [not found]         ` <CAJ3okZ3TKG4K3ZE2hXGo6GXGUTC+xzKrd9vAzk8skJaLz3QPtQ@mail.gmail.com>
@ 2019-12-16  7:53           ` Lars-Dominik Braun
  0 siblings, 0 replies; 12+ messages in thread
From: Lars-Dominik Braun @ 2019-12-16  7:53 UTC (permalink / raw)
  To: guix-devel

Hi,

in light of bug#38576 I filed, I’d like to get some guidance on when to pull in
dependencies. The package in question is r-irkernel, which is essentially an R
package bridging between Jupyter and R. However, it would never be “imported”
by the user like other R packages. Instead Jupyter executes R and tells it to
run an IPC server written in R. Thus I would consider r-minimal a runtime
dependency of r-irkernel. (If r-minimal is not installed then R_LIBS_SITE is
not set and R can’t find the package IRkernel whenever Jupyter tries to run R
code.)

python-ipykernel however does *not* explicitcy depend on python, even though it
works exactly the same, whereas jupyter-guile-kernel depends on guile.

Any thoughts on this?

Thanks,
Lars

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading
  2019-12-12 10:04   ` Lars-Dominik Braun
  2019-12-12 19:13     ` zimoun
@ 2019-12-19 22:47     ` Ludovic Courtès
  2020-01-02  7:35       ` Lars-Dominik Braun
  1 sibling, 1 reply; 12+ messages in thread
From: Ludovic Courtès @ 2019-12-19 22:47 UTC (permalink / raw)
  To: Lars-Dominik Braun; +Cc: Ricardo Wurmus, 38576

Hello,

Lars-Dominik Braun <ldb@leibniz-psychology.org> skribis:

>> This part looks fine to me, though I wonder if that’s what users of this
>> package would expect.  Is there an expectation that the effective R is
>> defined by the environment?  Or would that not work anyway?
> it’s what python-ipykernel does – without explanation though. I’m not an R
> expert, so I’m unsure whether any R installation from the environment (which
> could be user-installed in $HOME) would be able to load this plugin or just the
> one it was “built” for. This change assumes the latter.
>
>> 
>> > @@ -12423,6 +12429,8 @@ running IRkernel session.")
>> >         ("r-evaluate" ,r-evaluate)
>> >         ("r-irdisplay" ,r-irdisplay)
>> >         ("r-jsonlite" ,r-jsonlite)
>> > +       ;; sets R_LIBS_SITE, so R can actually find this package (IRkernel)
>> > +       ("r-minimal" ,r-minimal)
>> >         ("r-pbdzmq" ,r-pbdzmq)
>> >         ("r-repr" ,r-repr)
>> >         ("r-uuid" ,r-uuid)))
>> 
>> This doesn’t look right to me.  It seems wrong for any R package to
>> propagate R itself.  The R_LIBS_SITE variable is “attached” to
>> “r-minimal”, so when that is installed R will find the r-irkernel
>> package.  Am I missing something?
> If r-minimal is not installed, the kernel will simply not work and thus
> render this package useless. That’s why I would consider it a dependency.

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?

It may be more important for ‘r-irkernel’ to work out of the box, like
you did.

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.

How does that sound?

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading
  2019-12-19 22:47     ` [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading Ludovic Courtès
@ 2020-01-02  7:35       ` Lars-Dominik Braun
  2020-01-02 11:43         ` Ludovic Courtès
  0 siblings, 1 reply; 12+ messages in thread
From: Lars-Dominik Braun @ 2020-01-02  7:35 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Ricardo Wurmus, 38576

Hi Ludo,

> 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 ?

> 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?

Lars

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading
  2020-01-02  7:35       ` Lars-Dominik Braun
@ 2020-01-02 11:43         ` Ludovic Courtès
  2020-01-03 15:12           ` bug#38576: " Ludovic Courtès
                             ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Ludovic Courtès @ 2020-01-02 11:43 UTC (permalink / raw)
  To: Lars-Dominik Braun; +Cc: Ricardo Wurmus, 38576

Hi,

Lars-Dominik Braun <ldb@leibniz-psychology.org> 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.

Apologies for the delay, but I think it was good to have this
discussion!

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#38576: [PATCH] gnu: r-irkernel: Fix R kernel loading
  2020-01-02 11:43         ` Ludovic Courtès
@ 2020-01-03 15:12           ` Ludovic Courtès
  2020-01-06 18:14           ` [bug#38576] " zimoun
  2020-01-07 21:02           ` Roel Janssen
  2 siblings, 0 replies; 12+ messages in thread
From: Ludovic Courtès @ 2020-01-03 15:12 UTC (permalink / raw)
  To: Lars-Dominik Braun; +Cc: Ricardo Wurmus, 38576-done

Ludovic Courtès <ludo@gnu.org> skribis:

> 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.

Done!

Ludo’.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading
  2020-01-02 11:43         ` Ludovic Courtès
  2020-01-03 15:12           ` bug#38576: " Ludovic Courtès
@ 2020-01-06 18:14           ` zimoun
  2020-01-07 21:02           ` Roel Janssen
  2 siblings, 0 replies; 12+ messages in thread
From: zimoun @ 2020-01-06 18:14 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Ricardo Wurmus, 38576, Lars-Dominik Braun

Hi,

On Thu, 2 Jan 2020 at 12:44, Ludovic Courtès <ludo@gnu.org> wrote:

> 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.

So, the argument is "IRkernal is not an ordinary R package" and
because this very package is special it "is acceptable" to propagate R
(r-minimal).

No objection, but adding this explanation or a link to this thread
appears to me welcome. :-)
For example in the commit message or perhaps better a comment in
propagated-inputs.

Thank you for this package. Nice to have it! :-)

All the best,
simon

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading
  2020-01-02 11:43         ` Ludovic Courtès
  2020-01-03 15:12           ` bug#38576: " Ludovic Courtès
  2020-01-06 18:14           ` [bug#38576] " zimoun
@ 2020-01-07 21:02           ` Roel Janssen
  2020-01-07 23:01             ` Ludovic Courtès
  2 siblings, 1 reply; 12+ messages in thread
From: Roel Janssen @ 2020-01-07 21:02 UTC (permalink / raw)
  To: Ludovic Courtès, Lars-Dominik Braun; +Cc: Ricardo Wurmus, 38576

On Thu, 2020-01-02 at 12:43 +0100, Ludovic Courtès wrote:
> Hi,
> 
> Lars-Dominik Braun <ldb@leibniz-psychology.org> 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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading
  2020-01-07 21:02           ` Roel Janssen
@ 2020-01-07 23:01             ` Ludovic Courtès
  0 siblings, 0 replies; 12+ messages in thread
From: Ludovic Courtès @ 2020-01-07 23:01 UTC (permalink / raw)
  To: Roel Janssen; +Cc: Ricardo Wurmus, 38576, Lars-Dominik Braun

Hi Roel,

Roel Janssen <roel@gnu.org> skribis:

> On Thu, 2020-01-02 at 12:43 +0100, Ludovic Courtès wrote:
>> Hi,
>> 
>> Lars-Dominik Braun <ldb@leibniz-psychology.org> 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?

Indeed, it forces ‘r-minimal’ for use in the kernel.  But there are
workarounds, as Lars-Dominik suggests above.

WDYT?

Ludo’.

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2020-01-07 23:02 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-12-12  7:46 [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading Lars-Dominik Braun
2019-12-12  9:41 ` Ricardo Wurmus
2019-12-12 10:04   ` Lars-Dominik Braun
2019-12-12 19:13     ` zimoun
     [not found]       ` <20191213073056.GG22717@zpidnp36>
     [not found]         ` <CAJ3okZ3TKG4K3ZE2hXGo6GXGUTC+xzKrd9vAzk8skJaLz3QPtQ@mail.gmail.com>
2019-12-16  7:53           ` Package runtime dependencies (see bug#38576) Lars-Dominik Braun
2019-12-19 22:47     ` [bug#38576] [PATCH] gnu: r-irkernel: Fix R kernel loading Ludovic Courtès
2020-01-02  7:35       ` Lars-Dominik Braun
2020-01-02 11:43         ` Ludovic Courtès
2020-01-03 15:12           ` bug#38576: " Ludovic Courtès
2020-01-06 18:14           ` [bug#38576] " zimoun
2020-01-07 21:02           ` Roel Janssen
2020-01-07 23:01             ` Ludovic Courtès

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.