Closed LTLA closed 1 week ago
Hi @LTLA
Thanks for submitting your package. We are taking a quick look at it and you will hear back from us soon.
The DESCRIPTION file for this package is:
Package: assorthead
Version: 0.99.0
Date: 2024-07-18
Title: Assorted Header-only C++ Libraries
Authors@R: person("Aaron", "Lun", role=c("cre", "aut"), email="infinite.monkeys.with.keyboards@gmail.com")
Description:
Vendors an assortment of useful header-only C++ libraries.
Bioconductor packages can use these libraries in their own C++ code by LinkingTo this package without introducing any additional dependencies.
The use of a central repository avoids duplicate vendoring of libraries across multiple R packages,
and enables better coordination of version updates across cohorts of interdependent C++ libraries.
License: MIT + file LICENSE
Suggests:
knitr,
rmarkdown,
BiocStyle
VignetteBuilder: knitr
URL: https://github.com/LTLA/assorthead
BugReports: https://github.com/LTLA/assorthead/issues
Encoding: UTF-8
biocViews:
SingleCell,
QualityControl,
Normalization,
DataRepresentation,
DataImport,
DifferentialExpression,
Alignment
Could we just rubberstamp this through? There's basically no R code here, I'm just centralizing all the header files that are currently scattered throughout beachmat, BiocNeighbors, etc.
Thanks Aaron -- this is going in a new direction for us so give us a couple of days more. I've been trying to raise awareness in core and TAB about the C++ "substrate" for key analytical processes that you've been working on. Theoretically any developer in the project should have some sense of how to understand and interact with or critique or enhance any key software components. I am putting myself in this position, so will try to work with the tatami gallery. Building it requires an upgrade to my Cmake installation (fine) but then I see that the default installation of tatami will write to /usr/local. I am ok with that but it would be nice for the installation narrative to indicate that. More later.
Apropos "rubber stamp" I don't think I want to accept that notion. A CMD check shows * checking DESCRIPTION meta-information ... NOTE License stub is invalid DCF.
so even though it's a NOTE, can it be improved? Additionally, I would like us to work together to establish a QA framework since there are so many external dependencies. Could we propagate information from the individual github action test results back into this package so that assorthead warns or fails when any of the external components does?
I am not trying to make work here. I think this is a transition for the Bioconductor project. We are doing a lot of internal work to modernize, take advantage of github action concepts, and to embrace a richer set of software concepts and tools. But we can't lose sight of coherence that Bioconductor brings to a very dynamic system of approaches.
Just to be clear - there is no need for package developers, end-users, or the BBS itself to interact with CMake. (At least, not for this package.) assorthead vendors header-only C++ libraries, meaning that LinkingTo:
and #include
is sufficient for their use in downstream packages. This paradigm is commonly used throughout CRAN (e.g., Rcpp, RcppEigen, BH) and also has some historical usage in Bioconductor (all versions of beachmat from v1).
LTLA/BiocNeighbors#25 provides a fairly sophisticated example of how to use these libraries. R users probably won't even notice the difference as everything works as normal. However, package developers now have the opportunity to accept a pointer to a knncolle::Prebuilt
constructed by BiocNeighbors::buildIndex()
, and use it in their C++ code for some custom neighbor searches. This is achieved by LinkingTo: assorthead, BiocNeighbors
to define the knncolle interface, while avoiding the need to actually compile the majority of the knncolle code (which is handled by BiocNeighbors). In effect, we create a shadow C++ ecosystem for experts that has a user-friendly R interface.
Also the LICENSE
is fixed.
Quick question: why include things that are already provided by other C++ header-only packages like RcppAnnoy, RcppEigen, RcppHNSW, etc...?
Version stability and control over the update cadence.
RcppAnnoy is a good example - a few years ago, it updated in the middle of a BioC release cycle, causing the release BiocNeighbors package (which was LinkingTo: RcppAnnoy
) to suddenly yield different results. After some discussion with Dirk (comments starting here), we decided that the best course of action was for BiocNeighbors to vendor its own copy of annoy so that I could align any updates with the BioC schedule.
RcppEigen is another good example - it took over 2 years to update to Eigen 3.4 (see the entire saga at RcppCore/RcppEigen#103), simply because of the inertia of the CRAN packages that were depending on an older version. By vendoring it ourselves, we can hopefully have more regular updates by coercing or cajoling Bioconductor packages to always use the latest version before each release.
Yes, I think I like the consolidation of this header family for Bioconductor. Understood that users and BBS are insulated from direct involvement but before we adopt I would like the core to have broader acquaintance with the approach.
To be a little more concrete about the QA enhancements noted above, thanks to a hint from @almahmoud the following
curl::curl("https://api.github.com/repos/tatami-inc/tatami/actions/runs") |> jqr::jq('[.workflow_runs[] | select(.name == "Run unit tests")]') |> jsonlite::fromJSON() |> dplyr::select(status, conclusion, run_started_at, updated_at)
gives us a table of times and outcomes for unit tests in tatami. This might be the basis of an R-based unit test in assorthead to verify that all its C++ friends are succeeding at their GHA tests. Just a thought.
I think code like the above would iterate over data in inst/manifest.csv to find action outcomes and report on them.
Note that the GitHub workflow runs operate on the HEAD
of their repositories, which may not be the same as the tagged version in the manifest (particularly in BioC-release, which could be up to 6 months "behind").
I suppose we could set up a schedule to routinely run checks across the tagged versions, but this is a bit annoying to do on GitHub as they automatically disable scheduled runs when the repository has no activity.
If we wanted to do this, we would configure a mega CMake project that pulls in all libraries, builds all the test binaries from every individual project, and checks them all together. This takes advantage of FetchContent
overrides to make sure we're consistently using the right version of each project, without requiring configuration of find_package()
.
TBH that seems like more work than is warranted. We could just let the other packages depending on assorthead to serve as de facto tests; if there's a breaking change, it should show up pretty quickly as downstream build failures.
Yes, I get the point about the de facto tests. I'd like us to be sure that a) the breaking change does show up and b) we don't have to do substantial forensics to learn about where the error is. Since we are in devel maybe some experiments can be done. @lshep I think we can start the review for assorthead.
Your package has been added to git.bioconductor.org to continue the pre-review process. A build report will be posted shortly. Please fix any ERROR and WARNING in the build report before a reviewer is assigned or provide a justification on why you feel the ERROR or WARNING should be granted an exception.
IMPORTANT: Please read this documentation for setting up remotes to push to git.bioconductor.org. All changes should be pushed to git.bioconductor.org moving forward. It is required to push a version bump to git.bioconductor.org to trigger a new build report.
Bioconductor utilized your github ssh-keys for git.bioconductor.org access. To manage keys and future access you may want to active your Bioconductor Git Credentials Account
Dear Package contributor,
This is the automated single package builder at bioconductor.org.
Your package has been built on the Bioconductor Single Package Builder.
On one or more platforms, the build results were: "WARNINGS". This may mean there is a problem with the package that you need to fix. Or it may mean that there is a problem with the build system itself.
Please see the build report for more details.
The following are build products from R CMD build on the Single Package Builder: macOS 12.7.1 Monterey: assorthead_0.99.0.tar.gz Linux (Ubuntu 22.04.3 LTS): assorthead_0.99.0.tar.gz
Links above active for 21 days.
Remember: if you submitted your package after July 7th, 2020,
when making changes to your repository push to
git@git.bioconductor.org:packages/assorthead
to trigger a new build.
A quick tutorial for setting up remotes and pushing to upstream can be found here.
A reviewer has been assigned to your package for an indepth review. Please respond accordingly to any further comments from the reviewer.
Received a valid push on git.bioconductor.org; starting a build for commit id: 20950a411b631b5dc09405f63aade4a34404e52e
Dear Package contributor,
This is the automated single package builder at bioconductor.org.
Your package has been built on the Bioconductor Single Package Builder.
On one or more platforms, the build results were: "WARNINGS". This may mean there is a problem with the package that you need to fix. Or it may mean that there is a problem with the build system itself.
Please see the build report for more details.
The following are build products from R CMD build on the Single Package Builder: macOS 12.7.1 Monterey: assorthead_0.99.1.tar.gz Linux (Ubuntu 22.04.3 LTS): assorthead_0.99.1.tar.gz
Links above active for 21 days.
Remember: if you submitted your package after July 7th, 2020,
when making changes to your repository push to
git@git.bioconductor.org:packages/assorthead
to trigger a new build.
A quick tutorial for setting up remotes and pushing to upstream can be found here.
Received a valid push on git.bioconductor.org; starting a build for commit id: 18bd9fb5f67bb1792afc2f0f02d5501819412184
Dear Package contributor,
This is the automated single package builder at bioconductor.org.
Your package has been built on the Bioconductor Single Package Builder.
On one or more platforms, the build results were: "WARNINGS". This may mean there is a problem with the package that you need to fix. Or it may mean that there is a problem with the build system itself.
Please see the build report for more details.
The following are build products from R CMD build on the Single Package Builder: macOS 12.7.1 Monterey: assorthead_0.99.2.tar.gz Linux (Ubuntu 22.04.3 LTS): assorthead_0.99.2.tar.gz
Links above active for 21 days.
Remember: if you submitted your package after July 7th, 2020,
when making changes to your repository push to
git@git.bioconductor.org:packages/assorthead
to trigger a new build.
A quick tutorial for setting up remotes and pushing to upstream can be found here.
Received a valid push on git.bioconductor.org; starting a build for commit id: c3ae95dd5c919cb7a7cf8f4d153b750117b5011b
Dear Package contributor,
This is the automated single package builder at bioconductor.org.
Your package has been built on the Bioconductor Single Package Builder.
Congratulations! The package built without errors or warnings on all platforms.
Please see the build report for more details.
The following are build products from R CMD build on the Single Package Builder: Linux (Ubuntu 22.04.3 LTS): assorthead_0.99.3.tar.gz
Links above active for 21 days.
Remember: if you submitted your package after July 7th, 2020,
when making changes to your repository push to
git@git.bioconductor.org:packages/assorthead
to trigger a new build.
A quick tutorial for setting up remotes and pushing to upstream can be found here.
Nudging this. Got a couple of other BioC package updates depending on these headers.
Hi Aaron, @LTLA Thank you for your submission. Your package has been accepted. Best regards, Marcel
Your package has been accepted. It will be added to the Bioconductor nightly builds.
Thank you for contributing to Bioconductor!
Reviewers for Bioconductor packages are volunteers from the Bioconductor community. If you are interested in becoming a Bioconductor package reviewer, please see Reviewers Expectations.
cannot build unless issue is open and has the 'pre-review' label or '2. review in progress' label, or is closed and has the 'TESTING' label.
Did this get added to the build? Usually I see a 3b badge.
I process packages once or twice a week. the accepted badge is there and with the holiday I did not process accepted packages yet. It should be added in the next day
The default branch of your GitHub repository has been added to Bioconductor's git repository as branch devel.
To use the git.bioconductor.org repository, we need an 'ssh' key to associate with your github user name. If your GitHub account already has ssh public keys (https://github.com/LTLA.keys is not empty), then no further steps are required. Otherwise, do the following:
See further instructions at
https://bioconductor.org/developers/how-to/git/
for working with this repository. See especially
https://bioconductor.org/developers/how-to/git/new-package-workflow/ https://bioconductor.org/developers/how-to/git/sync-existing-repositories/
to keep your GitHub and Bioconductor repositories in sync.
Your package will be included in the next nigthly 'devel' build (check-out from git at about 6 pm Eastern; build completion around 2pm Eastern the next day) at
https://bioconductor.org/checkResults/
(Builds sometimes fail, so ensure that the date stamps on the main landing page are consistent with the addition of your package). Once the package builds successfully, you package will be available for download in the 'Devel' version of Bioconductor using BiocManager::install("assorthead")
. The package 'landing page' will be created at
https://bioconductor.org/packages/assorthead
If you have any questions, please contact the bioc-devel mailing list (https://stat.ethz.ch/mailman/listinfo/bioc-devel); this issue will not be monitored further.
Update the following URL to point to the GitHub repository of the package you wish to submit to Bioconductor
Confirm the following by editing each check box to '[x]'
[x] I understand that by submitting my package to Bioconductor, the package source and all review commentary are visible to the general public.
[x] I have read the Bioconductor Package Submission instructions. My package is consistent with the Bioconductor Package Guidelines.
[x] I understand Bioconductor Package Naming Policy and acknowledge Bioconductor may retain use of package name.
[x] I understand that a minimum requirement for package acceptance is to pass R CMD check and R CMD BiocCheck with no ERROR or WARNINGS. Passing these checks does not result in automatic acceptance. The package will then undergo a formal review and recommendations for acceptance regarding other Bioconductor standards will be addressed.
[x] My package addresses statistical or bioinformatic issues related to the analysis and comprehension of high throughput genomic data.
[x] I am committed to the long-term maintenance of my package. This includes monitoring the support site for issues that users may have, subscribing to the bioc-devel mailing list to stay aware of developments in the Bioconductor community, responding promptly to requests for updates from the Core team in response to changes in R or underlying software.
[x] I am familiar with the Bioconductor code of conduct and agree to abide by it.
I am familiar with the essential aspects of Bioconductor software management, including:
For questions/help about the submission process, including questions about the output of the automatic reports generated by the SPB (Single Package Builder), please use the #package-submission channel of our Community Slack. Follow the link on the home page of the Bioconductor website to sign up.