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
next prev parent 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.