all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: zimoun <zimon.toutoune@gmail.com>
Cc: 54787@debbugs.gnu.org
Subject: bug#54787: importer Bioconductor: no tarball, only Git
Date: Thu, 14 Apr 2022 13:43:36 +0200	[thread overview]
Message-ID: <87wnfrvqcw.fsf@elephly.net> (raw)
In-Reply-To: <87ilre5kvk.fsf@gmail.com>


zimoun <zimon.toutoune@gmail.com> writes:

> First, note that annotations do not have Git repo; at least not always,
> e.g.,
>
> <https://bioconductor.org/packages/release/data/annotation/html/GenomeInfoDbData.html>

That’s fine.  We just ignore annotation and experiment packages, and use
git only for regular packages.

> Second, if we go for something like:
>
> (define* (bioconductor-git-reference name #:optional
>                                      (release %bioconductor-version))
>   "Return a <git-reference> for the R package archive on Bioconductor for the
> RELEASE corresponding to NAME."
>   (git-reference
>    (url (string-append %bioconductor-git-url name))
>    (commit (string-append "RELEASE_" (string-replace-substring
>                                       %bioconductor-version "." "_")))))
>
>
> then, it raises the question: import/cran.scm or build-system/r.scm ?
> i.e., do we put a module dependency against (guix git-download) for the
> r-build-system or not?
>
> TeXLive already has a dependency to svn-download, so why not.

Yes, I don’t think that’s a problem.

We probably should *not* use RELEASE_3_14 (or whatever) as the commit,
though, because that is a moving target.  We need to resolve to the
actual commit and use its hash.

I wonder how the updater would need to be changed.  It would need to
know about the release branch and look for new commits in that branch
only.

> Well, I am also in favor to break the API and move %bioconductor-version
> and %bioconductor-url to (guix build-system r).  WDYT?  It would
> simplify some things (#36805 and #39885), I guess.

We tried this before and we couldn’t do this because of a circular
reference.

> Back to CHETAH, note that
>
>    guix import cran -a git htpps://git.bioconductor.org/CHETAH
>
> works but it points to master instead of RELEASE_3_14.  Well, I am not
> very familiar with the Bioconductor workflow for their release.

That’s because the importer doesn’t let us specify a different branch.
We should add that, but it’s strictly separate from the migration we’re
about to embark on.

> Last, using this in gnu/packages/bioconductor.scm,
>
> (define-public r-chetah
>   (package
>     (name "r-chetah")
>     (version "1.11.2")
>     (source
>      (origin
>        (method git-fetch)
>        (uri (bioconductor-git-reference "CHETAH"))
>        (file-name (git-file-name name version))
>        (sha256
>         (base32 "021v5831zqdy4pirfsb35kbnz8kmz4lxqc4cwi55qgd6r081xlgh"))))
>     (properties `((upstream-name . "CHETAH")))
>     (build-system r-build-system)
>     (propagated-inputs
>      (list r-biodist
>            r-corrplot
>            r-cowplot
>            r-dendextend
>            r-ggplot2
>            r-gplots
>            r-pheatmap
>            r-plotly
>            r-reshape2
>            r-s4vectors
>            r-shiny
>            r-singlecellexperiment
>            r-summarizedexperiment))
>     (native-inputs (list r-knitr))
>     (home-page "https://git.bioconductor.org/packages/CHETAH")
>     (synopsis "Fast and accurate scRNA-seq cell type identification")
>     (description
>      "CHETAH (CHaracterization of cEll Types Aided by Hierarchical classification) is
> an accurate, selective and fast scRNA-seq classifier.  Classification is guided
> by a reference dataset, preferentially also a scRNA-seq dataset.  By
> hierarchical clustering of the reference data, CHETAH creates a classification
> tree that enables a step-wise, top-to-bottom classification.  Using a novel
> stopping rule, CHETAH classifies the input cells to the cell types of the
> references and to \"intermediate types\": more general classifications that ended
> in an intermediate node of the tree.")
>     (license #f)))
>
> it just builds with,
>
>     ./pre-inst-env guix build r-chetah
>
>
>
> WDYT?

Neat :)

-- 
Ricardo




  reply	other threads:[~2022-04-14 11:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-08 11:48 bug#54787: importer Bioconductor: no tarball, only Git zimoun
2022-04-11 16:15 ` Ricardo Wurmus
2022-04-12 16:25   ` zimoun
2022-04-14 11:43     ` Ricardo Wurmus [this message]
2022-04-14 12:59       ` zimoun
2022-04-14 13:57         ` Ricardo Wurmus
2022-04-14 15:03           ` zimoun
2022-04-14 14:04       ` Maxime Devos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wnfrvqcw.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=54787@debbugs.gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.