[PATCH] gnu: Add r-edger.

[PATCH] gnu: Add r-edger.

[Roel Janssen]

Dear Guix,

Here is a package for 'r-edger'.
I sent another e-mail with the dependency 'r-limma'.

Kind regards,
Roel Janssen

From 5f31983e32f381dd5e98c93f8402770196fce4f2 Mon Sep 17 00:00:00 2001
From: Roel Janssen <roel@gnu.org>
Date: Tue, 3 May 2016 09:26:37 +0200
Subject: [PATCH] gnu: Add r-edger.

* gnu/packages/bioinformatics.scm (r-edger): New variable.
---
 gnu/packages/bioinformatics.scm | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/gnu/packages/bioinformatics.scm b/gnu/packages/bioinformatics.scm
index 079fd46..dc43fc0 100644
--- a/gnu/packages/bioinformatics.scm
+++ b/gnu/packages/bioinformatics.scm
@@ -4015,6 +4015,31 @@ use multiple corrections.  Visualization of data can be done either by
 barplots or heatmaps.")
     (license license:gpl2+)))
 
+(define-public r-edger
+  (package
+    (name "r-edger")
+    (version "3.12.1")
+    (source (origin
+              (method url-fetch)
+              (uri (bioconductor-uri "edgeR" version))
+              (sha256
+               (base32
+                "1s5xliiswij1v3nqgkf4999njwdr9jirg6ypza4002xz8mwmyki6"))))
+    (properties `((upstream-name . "edgeR")))
+    (build-system r-build-system)
+    (propagated-inputs
+      `(("r-limma" ,r-limma)))
+    (home-page "http://bioinf.wehi.edu.au/edgeR")
+    (synopsis "EdgeR does empirical analysis of digital gene expression data")
+    (description "This package can do differential expression analysis of
+RNA-seq expression profiles with biological replication.  It implements a range
+of statistical methodology based on the negative binomial distributions,
+including empirical Bayes estimation, exact tests, generalized linear models
+and quasi-likelihood tests.  It be applied to differential signal analysis of
+other types of genomic data that produce counts, including ChIP-seq, SAGE and
+CAGE.")
+    (license license:gpl2+)))
+
 (define-public r-biocgenerics
   (package
     (name "r-biocgenerics")
-- 
2.7.4

Re: [PATCH] gnu: Add r-edger.

[Leo Famulari]

On Tue, May 03, 2016 at 09:36:28AM +0200, Roel Janssen wrote:
> * gnu/packages/bioinformatics.scm (r-edger): New variable.

I tried to build this (and limma), but the source tarball is no longer
available. I couldn't find any archived releases on the bioconductor
site.

Re: [PATCH] gnu: Add r-edger.

[Ricardo Wurmus]

Leo Famulari <leo@famulari.name> writes:

> On Tue, May 03, 2016 at 09:36:28AM +0200, Roel Janssen wrote:
>> * gnu/packages/bioinformatics.scm (r-edger): New variable.
>
> I tried to build this (and limma), but the source tarball is no longer
> available. I couldn't find any archived releases on the bioconductor
> site.

Yes, this is a very annoying problem with Bioconductor.  I’m not sure
but I think this has been raised on the Bioconductor mailing lists some
months ago.  There is no archive at the moment.

All previous releases might still be available via SVN, though, so maybe
we can find a way to generalise this and add an SVN origin as a
fallback.  Maybe we should not use the tarballs at all and convert all
of the Bioconductor packages to use SVN instead?

~~ Ricardo

Re: [PATCH] gnu: Add r-edger.

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]

On Mon, May 23, 2016 at 09:33:28AM +0200, Ricardo Wurmus wrote:
> 
> Leo Famulari <leo@famulari.name> writes:
> 
> > On Tue, May 03, 2016 at 09:36:28AM +0200, Roel Janssen wrote:
> >> * gnu/packages/bioinformatics.scm (r-edger): New variable.
> >
> > I tried to build this (and limma), but the source tarball is no longer
> > available. I couldn't find any archived releases on the bioconductor
> > site.
> 
> Yes, this is a very annoying problem with Bioconductor.  I’m not sure
> but I think this has been raised on the Bioconductor mailing lists some
> months ago.  There is no archive at the moment.
> 
> All previous releases might still be available via SVN, though, so maybe
> we can find a way to generalise this and add an SVN origin as a
> fallback.  Maybe we should not use the tarballs at all and convert all
> of the Bioconductor packages to use SVN instead?
> 

It would be easier than making our own archive of releases or
systematically uploading them all to archive.org.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] gnu: Add r-edger.

[Roel Janssen]

Efraim Flashner writes:

> On Mon, May 23, 2016 at 09:33:28AM +0200, Ricardo Wurmus wrote:
>> 
>> Leo Famulari <leo@famulari.name> writes:
>> 
>> > On Tue, May 03, 2016 at 09:36:28AM +0200, Roel Janssen wrote:
>> >> * gnu/packages/bioinformatics.scm (r-edger): New variable.
>> >
>> > I tried to build this (and limma), but the source tarball is no longer
>> > available. I couldn't find any archived releases on the bioconductor
>> > site.
>> 
>> Yes, this is a very annoying problem with Bioconductor.  I’m not sure
>> but I think this has been raised on the Bioconductor mailing lists some
>> months ago.  There is no archive at the moment.
>> 
>> All previous releases might still be available via SVN, though, so maybe
>> we can find a way to generalise this and add an SVN origin as a
>> fallback.  Maybe we should not use the tarballs at all and convert all
>> of the Bioconductor packages to use SVN instead?
>> 
>
> It would be easier than making our own archive of releases or
> systematically uploading them all to archive.org.

I've encountered missing tarballs a couple of times now.  I think it would
make Guix more "complete" to add an option to consistently store source
tarballs, so they can be backed up somewhere.

We could integrate this with the substitutions infrastructure, or create a
separate component that works kind of like this:

If could add an option to export source tarballs from the store to a
custom directory that maintains the structure:
<dir>/<sha256-hash>-<name>-<version>.<extension>, then we could easily set
up a web server with <dir> as webroot.

Then all we have to do is "trust" the webserver that serves the
tarballs, which can be done in a similar way as trusting a substitution
server.

This can be completely automated, so I don't think it has to be a lot of
work:
1. guix package --export-source-tarballs=/var/www/public_html/
2. rsync /var/www/public_html/ user@remote-server:/var/www/public_html/

Kind regards,
Roel Janssen

Re: [PATCH] gnu: Add r-edger.

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Efraim Flashner writes:
>
>> On Mon, May 23, 2016 at 09:33:28AM +0200, Ricardo Wurmus wrote:
>>> 
>>> Leo Famulari <leo@famulari.name> writes:

[...]

>>> All previous releases might still be available via SVN, though, so maybe
>>> we can find a way to generalise this and add an SVN origin as a
>>> fallback.  Maybe we should not use the tarballs at all and convert all
>>> of the Bioconductor packages to use SVN instead?
>>> 
>>
>> It would be easier than making our own archive of releases or
>> systematically uploading them all to archive.org.
>
> I've encountered missing tarballs a couple of times now.  I think it would
> make Guix more "complete" to add an option to consistently store source
> tarballs, so they can be backed up somewhere.
>
> We could integrate this with the substitutions infrastructure, or create a
> separate component that works kind of like this:
>
> If could add an option to export source tarballs from the store to a
> custom directory that maintains the structure:
> <dir>/<sha256-hash>-<name>-<version>.<extension>, then we could easily set
> up a web server with <dir> as webroot.

Did you see:

  https://lists.gnu.org/archive/html/guix-devel/2016-05/msg00450.html

?

This should address 404s for people who don’t use substitutes (people
using substitutes don’t have these problems since sources are also
substitutable.)

> This can be completely automated, so I don't think it has to be a lot of
> work:
> 1. guix package --export-source-tarballs=/var/www/public_html/

We could do this, but I figured we might as well let others do it.  :-)
Currently we have tarballs.nixos.org, and I think there’ll be another
one pretty soon.  Hopefully that’ll cover our needs.

Thoughts?

Thanks,
Ludo’.

Re: [PATCH] gnu: Add r-edger.

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> Efraim Flashner writes:
>>
>>> On Mon, May 23, 2016 at 09:33:28AM +0200, Ricardo Wurmus wrote:
>>>> 
>>>> Leo Famulari <leo@famulari.name> writes:
>
> [...]
>
>>>> All previous releases might still be available via SVN, though, so maybe
>>>> we can find a way to generalise this and add an SVN origin as a
>>>> fallback.  Maybe we should not use the tarballs at all and convert all
>>>> of the Bioconductor packages to use SVN instead?
>>>> 
>>>
>>> It would be easier than making our own archive of releases or
>>> systematically uploading them all to archive.org.
>>
>> I've encountered missing tarballs a couple of times now.  I think it would
>> make Guix more "complete" to add an option to consistently store source
>> tarballs, so they can be backed up somewhere.
>>
>> We could integrate this with the substitutions infrastructure, or create a
>> separate component that works kind of like this:
>>
>> If could add an option to export source tarballs from the store to a
>> custom directory that maintains the structure:
>> <dir>/<sha256-hash>-<name>-<version>.<extension>, then we could easily set
>> up a web server with <dir> as webroot.
>
> Did you see:
>
>   https://lists.gnu.org/archive/html/guix-devel/2016-05/msg00450.html
>
> ?
>
> This should address 404s for people who don’t use substitutes (people
> using substitutes don’t have these problems since sources are also
> substitutable.)

Yes, and this is a very nice feature!

>> This can be completely automated, so I don't think it has to be a lot of
>> work:
>> 1. guix package --export-source-tarballs=/var/www/public_html/
>
> We could do this, but I figured we might as well let others do it.  :-)
> Currently we have tarballs.nixos.org, and I think there’ll be another
> one pretty soon.  Hopefully that’ll cover our needs.
>
> Thoughts?

I'd say we should definitely do this.  Making the Guix project
self-contained will make it look more solid to people outside of the
project.  This is an issue we have solved half-way now..  We rely on
infrastructure we cannot easily create with Guix only.  I think it's
important that we can show that with GNU Guix, we've got everything
covered, from source to binary, without relying on other projects (even
though Nix is a friendly project :-))

It doesn't matter if we actually create a content-addressed mirror any
time soon, what matters is that we provide the tools to do so easily.

WDYT?

Thanks!

Kind regards,
Roel Janssen

Re: [PATCH] gnu: Add r-edger.

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

[...]

>>> This can be completely automated, so I don't think it has to be a lot of
>>> work:
>>> 1. guix package --export-source-tarballs=/var/www/public_html/
>>
>> We could do this, but I figured we might as well let others do it.  :-)
>> Currently we have tarballs.nixos.org, and I think there’ll be another
>> one pretty soon.  Hopefully that’ll cover our needs.
>>
>> Thoughts?
>
> I'd say we should definitely do this.  Making the Guix project
> self-contained will make it look more solid to people outside of the
> project.  This is an issue we have solved half-way now..  We rely on
> infrastructure we cannot easily create with Guix only.

What part of the infrastructure do you have in mind?  It’s true that we
fetch sources from a wide range of places now.

> I think it's important that we can show that with GNU Guix, we've got
> everything covered, from source to binary, without relying on other
> projects (even though Nix is a friendly project :-))
>
> It doesn't matter if we actually create a content-addressed mirror any
> time soon, what matters is that we provide the tools to do so easily.

I agree.  :-)  A command to create a content-addressed cache along the
lines of tarballs.nixos.org would be welcome, indeed, and rather easy to
implement (we wouldn’t be able to generate the cache on the fly like
‘guix publish’ does because the daemon does not store raw content
hashes; instead, it stores the hash of the nar of the contents, but
anyway a detail.)

FWIW I don’t have plans to work on it in the near future, so
contributions are welcome!  ;-)

Thanks,
Ludo’.

Re: [PATCH] gnu: Add r-edger.

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
> [...]
>
>>>> This can be completely automated, so I don't think it has to be a lot of
>>>> work:
>>>> 1. guix package --export-source-tarballs=/var/www/public_html/
>>>
>>> We could do this, but I figured we might as well let others do it.  :-)
>>> Currently we have tarballs.nixos.org, and I think there’ll be another
>>> one pretty soon.  Hopefully that’ll cover our needs.
>>>
>>> Thoughts?
>>
>> I'd say we should definitely do this.  Making the Guix project
>> self-contained will make it look more solid to people outside of the
>> project.  This is an issue we have solved half-way now..  We rely on
>> infrastructure we cannot easily create with Guix only.
>
> What part of the infrastructure do you have in mind?  It’s true that we
> fetch sources from a wide range of places now.

In this case, just a "content-addressed mirror" (we don't have the ui to
create it).  So, we have the code in place to fetch from other
content-addressed mirrors, but we don't have the code in place to create
one.

>> I think it's important that we can show that with GNU Guix, we've got
>> everything covered, from source to binary, without relying on other
>> projects (even though Nix is a friendly project :-))
>>
>> It doesn't matter if we actually create a content-addressed mirror any
>> time soon, what matters is that we provide the tools to do so easily.
>
> I agree.  :-)  A command to create a content-addressed cache along the
> lines of tarballs.nixos.org would be welcome, indeed, and rather easy to
> implement (we wouldn’t be able to generate the cache on the fly like
> ‘guix publish’ does because the daemon does not store raw content
> hashes; instead, it stores the hash of the nar of the contents, but
> anyway a detail.)

Could we create a mapping between the hash from the package recipe and
the hash of the nar of the contents?  Then this wouldn't be a problem.

> FWIW I don’t have plans to work on it in the near future, so
> contributions are welcome!  ;-)

It seems like a task I can work on.  However, I am working on some other
things that I would like to finish first.  So if anyone else is
interested in this.. :-)

Kind regards,
Roel Janssen

Re: [PATCH] gnu: Add r-edger.

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <roel@gnu.org> skribis:

[...]

>>> I'd say we should definitely do this.  Making the Guix project
>>> self-contained will make it look more solid to people outside of the
>>> project.  This is an issue we have solved half-way now..  We rely on
>>> infrastructure we cannot easily create with Guix only.
>>
>> What part of the infrastructure do you have in mind?  It’s true that we
>> fetch sources from a wide range of places now.
>
> In this case, just a "content-addressed mirror" (we don't have the ui to
> create it).  So, we have the code in place to fetch from other
> content-addressed mirrors, but we don't have the code in place to create
> one.

OK.

>>> I think it's important that we can show that with GNU Guix, we've got
>>> everything covered, from source to binary, without relying on other
>>> projects (even though Nix is a friendly project :-))
>>>
>>> It doesn't matter if we actually create a content-addressed mirror any
>>> time soon, what matters is that we provide the tools to do so easily.
>>
>> I agree.  :-)  A command to create a content-addressed cache along the
>> lines of tarballs.nixos.org would be welcome, indeed, and rather easy to
>> implement (we wouldn’t be able to generate the cache on the fly like
>> ‘guix publish’ does because the daemon does not store raw content
>> hashes; instead, it stores the hash of the nar of the contents, but
>> anyway a detail.)
>
> Could we create a mapping between the hash from the package recipe and
> the hash of the nar of the contents?  Then this wouldn't be a problem.

This sounds like a description of how Guix works.  ;-)
Roughly, <package> objects compile down to derivations, and there’s a
mapping from the derivation name (the .drv file) to its outputs.

The same is true of origins, which (usually) compile to fixed-output
derivations.

Now, store items are not necessarily plain regular files, which is why
the daemon stores the hash of their nar-serialization.

Cheers,
Ludo’.