Re: Move r-{desolve, quadprog, pracma, subplex} from maths.scm to cran.scm

[zimoun]

Hi Ricardo,

Thank you for your inputs.

On Fri, 22 Nov 2019 at 15:47, Ricardo Wurmus <address@hidden> wrote:

> > The packages r-desolve, r-quadprog, r-subplex and r-pracma are defined
> > in `maths.scm`. They come from the CRAN archive. For consistency, they
> > should be defined in the file `cran.scm`. Do you agree to move them?
>
> I think moving them to cran.scm is fine.  In my opinion both of these
> places are similarly poor choices: maths.scm because we drag in the R
> build system and dependencies, and cran.scm because it’s huge and will
> only get bigger.
>
> On the plus side, R code is rarely as “involved” as Python code, so I
> don’t expect cran.scm to become as tangled up with dependencies from all
> over the place as python-xyz.scm, so letting cran.scm grow is probably
> just fine.

Do you agree that we should document this rationale somewhere?
AFAIK, nothing is written down about the lang-xyz.scm or the R land
(cran vs bioconductor vs bioinformatics vs math vs statistiscs).
I will read our materials and come back with a proposal: manual or
cookbook or plain text in repo or etc.
What do you think?


> Since nobody else seems to hold any strong opinions on this issue, I’d
> say you’re welcome to move these package definitions to cran.scm.
> Please also update the Copyright comments at the top of the file where
> needed (use “git blame” and “git log” to simplify this task) and remove
> whatever spurious module imports there may be in maths.scm after
> removing the R package definitions.

I submitted patches [1] that respect these advices. I hope so. :-)

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38184


> PS: I also think that CRAN things in bioinformatics.scm should be moved
> to cran.scm, and even some or all of the R stuff in statistics.scm.
> (Same applies to Bioconductor packages, which should end up in
> bioconductor.scm where possible.)

I will do.
I will dig into the big move of Haskell or Lisp to see how it is
better to split the commits.


Thanks.
simon