#package-submission

2021-04-28

Hervé Pagès (10:52:45): > @Hervé Pagès has joined the channel

Hervé Pagès (10:52:45): > set the channel description: Ask any question about the submission and review process of new packages here.

Vince Carey (10:55:35): > @Vince Carey has joined the channel

Martin Morgan (10:55:35): > @Martin Morgan has joined the channel

Lori Shepherd (10:55:35): > @Lori Shepherd has joined the channel

Nitesh Turaga (10:55:35): > @Nitesh Turaga has joined the channel

Marcel Ramos Pérez (10:55:35): > @Marcel Ramos Pérez has joined the channel

Matthew McCall (17:19:27): > @Matthew McCall has joined the channel

Eric Davis (17:19:30): > @Eric Davis has joined the channel

Samuel David Gamboa-Tuz (17:19:45): > @Samuel David Gamboa-Tuz has joined the channel

Kelly Street (17:20:35): > @Kelly Street has joined the channel

Meena Choi (17:20:47): > @Meena Choi has joined the channel

Eli Miller (17:21:21): > @Eli Miller has joined the channel

Peter Hickey (17:21:47): > @Peter Hickey has joined the channel

Russ Bainer (17:23:37): > @Russ Bainer has joined the channel

Sara Ballouz (17:26:05): > @Sara Ballouz has joined the channel

Alan O’C (17:28:07): > @Alan O’C has joined the channel

Laurent Gatto (17:30:59): > @Laurent Gatto has joined the channel

Benjamin Reisman (17:32:28): > @Benjamin Reisman has joined the channel

Mateusz Staniak (17:52:35): > @Mateusz Staniak has joined the channel

Daniela Cassol (17:57:22): > @Daniela Cassol has joined the channel

Sean Davis (18:06:15): > @Sean Davis has joined the channel

Jayaram Kancherla (18:38:16): > @Jayaram Kancherla has joined the channel

Lluís Revilla (18:47:16): > @Lluís Revilla has joined the channel

Kevin Blighe (18:53:31): > @Kevin Blighe has joined the channel

Lisa Cao (19:09:59): > @Lisa Cao has joined the channel

Stevie Pederson (19:31:55): > @Stevie Pederson has joined the channel

Joan (19:50:42): > @Joan has joined the channel

Mahmoud Ahmed (20:18:01): > @Mahmoud Ahmed has joined the channel

koki (21:11:13): > @koki has joined the channel

Jayaram Kancherla (21:19:41): > I submitted a package (https://github.com/Bioconductor/Contributions/issues/2092) but another package with the same name already exists in CRAN. Since we changed our package name, should I create a new issue on github ?

Hervé Pagès (23:19:11): > Yes please, start a new issue for scTreeViz, thanks!

Pedro Baldoni (23:49:18): > @Pedro Baldoni has joined the channel

2021-04-29

Charlotte Soneson (00:21:15): > @Charlotte Soneson has joined the channel

Hervé Pagès (00:23:59): > set the channel description: Ask any question about the submission and review process of new packages here. Package currently under review are listed here: https://github.com/Bioconductor/Contributions/issues

Hervé Pagès (00:40:39): > set the channel description: Ask any question about the submission and review process of new packages here. Packages currently under review are listed here: https://github.com/Bioconductor/Contributions/issues

Helena L. Crowell (01:07:50): > @Helena L. Crowell has joined the channel

Davide Risso (01:24:34): > @Davide Risso has joined the channel

Johannes Rainer (01:46:18): > @Johannes Rainer has joined the channel

Alan Murphy (02:14:19): > @Alan Murphy has joined the channel

Robert Ivánek (02:41:54): > @Robert Ivánek has joined the channel

Christian Panse (02:45:15): > @Christian Panse has joined the channel

Thomas Naake (02:47:18): > @Thomas Naake has joined the channel

Federico Marini (03:29:23): > @Federico Marini has joined the channel

Davide Corso (03:33:07): > @Davide Corso has joined the channel

rohitsatyam102 (03:52:37): > @rohitsatyam102 has joined the channel

Gavin Rhys Lloyd (03:58:32): > @Gavin Rhys Lloyd has joined the channel

Chris Vanderaa (04:04:52): > @Chris Vanderaa has joined the channel

Mike Smith (04:13:59): > @Mike Smith has joined the channel

Jovan Tanevski (04:23:02): > @Jovan Tanevski has joined the channel

Boris Hejblum (04:35:22): > @Boris Hejblum has joined the channel

Haichao Wang (06:19:21): > @Haichao Wang has joined the channel

Jim Hunter (06:41:16): > @Jim Hunter has joined the channel

Pierre-Luc Germain (09:36:56): > @Pierre-Luc Germain has joined the channel

2021-04-30

Tobias Kockmann (05:04:55): > @Tobias Kockmann has joined the channel

2021-05-03

Jovan Tanevski (08:16:23): > my package (https://github.com/Bioconductor/Contributions/issues/2060) build is failing on machv2 only due to missing hdf5 library on that system (it passes successfully on linux and win). this weekend on the bioc-devel mailing list it was mentioned that the setup of machv2 was tweaked. did this maybe include adding this library? if that is the case, can the moderators rerun the build manually or should i make a new commit?

Jesús Vélez Santiago (10:32:55): > @Jesús Vélez Santiago has joined the channel

Krithika Bhuvanesh (16:50:21): > @Krithika Bhuvanesh has joined the channel

Hervé Pagès (19:13:50) (in thread): > Hi, I don’t see that the failure reported by the SPB for mistyR on machv2 has anything to do with hdf5 so I’m confused. Note that I’m looking at the latest report posted by the SPB in the issue (the report is 4 days old) and what I see there is the “polygon edge not found” error instead. This is the error that was affecting hundreds of packages a few days ago on machv2. It was a problem on our side and it has been fixed. So yes please bump the package version and push. This will trigger a new build. Thanks!

2021-05-04

Jovan Tanevski (03:28:03) (in thread): > Thank you for the response. I have bumped the version and the hdf5 issue still persists: > > Please install hdf5r to read HDF5 files > > In the old report on line 36, in the new report on line 80. The package hdf5r (in Suggests in my package) requires the system library hdf5 to be installed.

Sara Stankiewicz (15:40:03): > @Sara Stankiewicz has joined the channel

Jesús Vélez Santiago (16:03:43): > My Packagehttps://github.com/Bioconductor/Contributions/issues/2048build has a warning related to the help files of special function (e.g.,%>%or:=) in Windows. What should I do? The problem does not come from the package itself. > > * checking whether package 'decoupleR' can be installed ... WARNING > Found the following significant warnings: > Rd warning: cannot open file 'C:/Users/pkgbuild/packagebuilder/workers/jobs/2048/ff8b5f7f98bb6c3c2d770abb5951b4beba4b10a6/decoupleR.buildbin-libdir/00LOCK-decoupleR/00new/decoupleR/help/%>%.html': Invalid argument > Rd warning: cannot open file 'C:/Users/pkgbuild/packagebuilder/workers/jobs/2048/ff8b5f7f98bb6c3c2d770abb5951b4beba4b10a6/decoupleR.buildbin-libdir/00LOCK-decoupleR/00new/decoupleR/help/:=.html': Invalid argument >

Lori Shepherd (16:06:58): > The windows warnings concerning %>% and the liked can be ignored. It’s a known issue.

Hervé Pagès (20:18:36) (in thread): > Oh I realize now thatmistyRcontains 3 vignettes:mistyR.Rmd,mistySeurat.Rmd, andmistySpatialExperiment.Rmd. Two of them (the 1st and 3rd) were failing because of the “polygon edge not found” error on machv2. But I missed the “Please install hdf5r to read HDF5 files” error in the 2nd one, sorry. We strongly encourage Bioconductor packages to userhdf5instead ofhdf5rfor reading HDF5 files. So unless you have a good reason for using the latter, please make the switch. Also note that the latter is not available on macOS for R 4.1 at the moment, hence the error on machv2.

2021-05-05

Jovan Tanevski (03:30:50) (in thread): > Ah, yes, the binary package for win and the source is available but not the binary for mac. Unfortunately i can’t change the dependency to another package since it is a Seurat dependency. I use it only in the vignette to give an example of using mistyR with Seurat for the part of the community that is using Seurat for spatial data. I guess for the time being removing it is the only solution. Thank you for your help.

2021-05-10

Federico Marini (03:28:50): > Hi there - any news concerning a possible shift of the deadline due to 4.1.0 release date (expected according to R’s main website on May 18)?

Federico Marini (03:30:47): > i.e., is the 12th as deadline for Bioc 3.13 still in plan? cc@Arsenij Ustjanzew

Arsenij Ustjanzew (05:39:36): > @Arsenij Ustjanzew has joined the channel

Lori Shepherd (06:25:56) (in thread): > We have shifted the main two days but the deadline for new package submissions as with most of the deadlines stayed the samehttp://bioconductor.org/developers/release-schedule/

Federico Marini (06:38:58) (in thread): > Thanks Lori! Hopefully then the revision of our edits will come in time for the package to be accepted:wink:(cbpManagerin this case)

Federico Marini (06:41:27) (in thread): > but whatever estimation I might have of your (extra) work load in these days, it will most likely not match the real situation:nerd_face:

2021-05-11

Megha Lal (16:45:20): > @Megha Lal has joined the channel

2021-05-12

Wancen Mu (00:42:17): > @Wancen Mu has joined the channel

2021-05-13

Aedin Culhane (17:24:03): > @Aedin Culhane has joined the channel

2021-05-14

Luke Zappia (03:15:30): > @Luke Zappia has joined the channel

Malte Thodberg (08:15:12): > @Malte Thodberg has joined the channel

2021-05-25

Frank Rühle (05:09:26): > @Frank Rühle has joined the channel

Quang Nguyen (12:20:36): > @Quang Nguyen has joined the channel

2021-05-28

Izaskun Mallona (10:15:55): > @Izaskun Mallona has joined the channel

2021-05-31

Maria Doyle (07:37:45): > @Maria Doyle has joined the channel

2021-06-03

Oliver Voogd (22:13:28): > @Oliver Voogd has joined the channel

Oliver Voogd (22:19:22): > Hi, > I’m getting a warning with my package (https://github.com/Bioconductor/Contributions/issues/2049) on tokay2 relating to the permissions on theconfigurefile. How can I resolve this? > The warning doesn’t appear any of the other build systems, or on my own. > > Thanks for the help > > =============================== > > R CMD BUILD > > =============================== > > * checking for file 'FLAMES/DESCRIPTION' ... OK > * preparing 'FLAMES': > * checking DESCRIPTION meta-information ... OK > * cleaning src > * installing the package to build vignettes > * creating vignettes ... OK > * cleaning src > * checking for LF line-endings in source and make files and shell scripts > * checking for empty or unneeded directories > * building 'FLAMES_0.99.19.tar.gz' > Warning: file 'FLAMES/configure' did not have execute permissions: corrected >

Hervé Pagès (23:43:24) (in thread): > You need to set execute permissions on theconfigurefile. On Unix do this withchmod +x configure. Then bump the version, commit and push.

2021-06-04

Tobias Kockmann (06:47:46): > Hi@Hervé Pagès,

Tobias Kockmann (06:48:36): > we are still having issues installingrawrrusing theBiocManager. Is there still something that we need to do?

Tobias Kockmann (06:50:26): > > > BiocManager::version() > [1] '3.11' > > BiocManager::available("rawrr") > character(0) > > BiocManager::available("MSstats") > [1] "MSstats" "MSstatsBioData" "MSstatsQC" "MSstatsQCgui" "MSstatsSampleSize" "MSstatsTMT" > > >

Tobias Kockmann (06:53:25): > uups

Tobias Kockmann (06:54:16): > my laptop is still running an old version ofBiocManager, but I was a similar output using 3.13

Lori Shepherd (07:24:58): > rawrr was only accepted for Bioconductor release 3.13; It will not be available or listed in the repositories for any version of Bioconductor under that. It is not available on 3.13 because it has yet to have a clean install/build/check on linux and mac buildershttp://bioconductor.org/checkResults/release/bioc-LATEST/rawrr/

Tobias Kockmann (08:15:27): > Hi@Lori Shepherd, that’s why I said “uuuups”.:wink:According to our tests there is mono library missing on the build system.

Tobias Kockmann (08:16:19): > https://community-bioc.slack.com/archives/CEQ04GKEC/p1622471822059500?thread_ts=1622210563.051300&cid=CEQ04GKEC - Attachment: Attachment > Dear Hervé; The libmono-system-data4.0-cil package seems to be the only missing dependency when installing the mono-runtime . I updated the INSTALL file for Linux and checked on debian:10 and ubuntu:20.04 systems (both systems behave the same). > sudo apt-get install mono-runtime libmono-system-data4.0-cil -y > should solve the rawrr issue on Linux. I can not wait to see rawrr source tarball on bioc. Thanks again. Christian

Lori Shepherd (08:16:43): > Thank you for the information. We will look into this

Tobias Kockmann (08:18:37): > Thx! Sorry to be pushy, but havingrawrrlisted in the bioc release 3.13 generates a certain expectation that it also can be installed.:wink:

Lori Shepherd (08:19:42): > Yes understandable. Thank you for pointing it out. We’ll make sure it gets discussed today with the build team.

Tobias Kockmann (08:22:47): > :+1:

Andres Wokaty (10:02:34): > @Andres Wokaty has joined the channel

Hervé Pagès (11:08:16): > Hi@Tobias Kockmann, we’re still working out these issues with therawrrauthors. See discussion in the#bioc-buildschannel. Thanks for your patience.

Tobias Kockmann (11:10:35): > Hi@Hervé PagèsI am one of two rawrr authors.

Tobias Kockmann (11:18:34): > Is there still something that you need?

Tobias Kockmann (11:20:43): > ok. I saw your reply to Christian question just now. Sorry!

Hervé Pagès (11:27:01): > > I am one of two rawrr authors. > Right, I’m slowly connecting the dots now… So then you’re aware of the issues and can help fix them:wink:

2021-06-08

Lorenzo Bonaguro (08:49:45): > @Lorenzo Bonaguro has joined the channel

2021-06-09

Oliver Voogd (21:48:31) (in thread): > Thanks for the help!

2021-06-14

GuandongShang (22:59:17): > @GuandongShang has joined the channel

2021-06-15

GuandongShang (01:52:30): > Hi, I get a error when I run bioccheck > Thanks for your help :) > > $error > [1] "At least 80% of man pages documenting exported objects must have runnable examples. The following pages do not:" > [2] "Maintainer must register at the support site; visit[https://support.bioconductor.org/accounts/signup/](https://support.bioconductor.org/accounts/signup/)." > > But I have register at support site > > Here is my packageDescription > > > packageDescription("FindIT2") > Package: FindIT2 > Title: find influential TF and Target based on multi-omics data > Version: 0.99.0 > Date: 2021-06-07 > Authors@R: c( person("Guandong", "Shang", role = c("aut", "cre"), email = > "shangguandong@cemps.com", comment = c(ORCID = > "0000-0002-9509-0314")) ) > Description: What the package does (one paragraph). > License: Artistic-2.0 > URL:[https://github.com/shangguandong1996/FindIT2](https://github.com/shangguandong1996/FindIT2)BugReports:[https://support.bioconductor.org/t/FindIT2](https://support.bioconductor.org/t/FindIT2)biocViews: Software, Annotation, ChIPSeq, ATACSeq, GeneRegulation, > MultipleComparison, GeneTarget > Encoding: UTF-8 > Roxygen: list(markdown = TRUE) > RoxygenNote: 7.1.1 > Suggests: BiocStyle, knitr, RefManageR, rmarkdown, sessioninfo, > TxDb.Athaliana.BioMart.plantsmart28 > VignetteBuilder: knitr > Depends: R (>= 2.10), GenomicRanges > Imports: withr, BiocGenerics, GenomeInfoDb, rtracklayer, S4Vectors, > GenomicFeatures, magrittr, dplyr, rlang, patchwork, ggplot2, > BiocParallel, qvalue, stringr, utils, shiny, stats, ggrepel, > tibble, tidyr, SummarizedExperiment, MultiAssayExperiment, IRanges, > progress, purrr, glmnet > NeedsCompilation: no > Packaged: 2021-06-15 02:12:05 UTC; 商冠东 > Author: Guandong Shang [aut, cre] (<[https://orcid.org/0000-0002-9509-0314](https://orcid.org/0000-0002-9509-0314)>) > Maintainer: Guandong Shang <shangguandong@cemps.com> > Built: R 4.1.0; ; 2021-06-15 02:12:06 UTC; windows >

GuandongShang (01:52:55): - File (PNG): 图片.png

Davide Risso (02:14:04): > Hi@GuandongShangthe email address in your maintainer field seems different from the one you used to register to the support site (.com vs .ac.cn)

GuandongShang (02:19:26) (in thread): > Thanks, it works ! so embarrassed:joy:

Davide Risso (02:34:22) (in thread): > No need to be embarrassed! Sometimes all it takes is a second pair of eyes!

GuandongShang (03:00:43): > @GuandongShang has joined the channel

2021-06-16

Melanie Loth (14:57:29): > @Melanie Loth has joined the channel

2021-06-30

GuandongShang (09:06:52): > Hi, I just have a error with my package(https://github.com/Bioconductor/Contributions/issues/2166) related my bioc Mailing list. > > * Checking for bioc-devel mailing list subscription... > * ERROR: Maintainer must subscribe to the bioc-devel mailing list. > Subscribe here:[https://stat.ethz.ch/mailman/listinfo/bioc-devel](https://stat.ethz.ch/mailman/listinfo/bioc-devel) > > I just have subscribed to the bioc-devel mailing list, > > but the BiocCheck still say > > "Cannot determine whether maintainer is subscribed to the bioc-devel mailing list\n(requires admin credentials). Subscribe here:\n[https://stat.ethz.ch/mailman/listinfo/bioc-devel](https://stat.ethz.ch/mailman/listinfo/bioc-devel)" > > Here is my package description > > Package: FindIT2 > Title: find influential TF and Target based on multi-omics data > Version: 0.99.0 > Date: 2021-06-07 > Authors@R: c( person("Guandong", "Shang", role = c("aut", "cre"), email = > "shangguandong1996@163.com", comment = c(ORCID = "0000-0002-9509-0314")) ) > Description: This package implements functions to find influential TF and target > based on different input type.It have five module:Multi-peak multi-gene > annotaion(mmPeakAnno module), Calculate regulation potential(calcRP > module), Find influential Target based on ChIP-Seq and RNA-Seq data(Find > influential Target module), Find influential TF based on different > input(Find influential TF module), Calculate peak-gene or peak-peak > correlation(peakGeneCor module), And there are also some other useful > function like integrate different source information, calculate jaccard > similarity for your TF. > License: Artistic-2.0 > URL:[https://github.com/shangguandong1996/FindIT2](https://github.com/shangguandong1996/FindIT2)BugReports:[https://support.bioconductor.org/t/FindIT2](https://support.bioconductor.org/t/FindIT2)biocViews: Software, Annotation, ChIPSeq, ATACSeq, GeneRegulation, > MultipleComparison, GeneTarget > Encoding: UTF-8 > Roxygen: list(markdown = TRUE) > RoxygenNote: 7.1.1 > Suggests: BiocStyle, knitr, rmarkdown, sessioninfo, testthat (>= 3.0.0), > TxDb.Athaliana.BioMart.plantsmart28 > VignetteBuilder: knitr > Depends: GenomicRanges, R (>= 3.5.0) > Imports: withr, BiocGenerics, GenomeInfoDb, rtracklayer, S4Vectors, GenomicFeatures, > magrittr, dplyr, rlang, patchwork, ggplot2, BiocParallel, qvalue, stringr, > utils, shiny, stats, ggrepel, tibble, tidyr, SummarizedExperiment, > MultiAssayExperiment, IRanges, progress, purrr, glmnet > Config/testthat/edition: 3 > Author: Guandong Shang [aut, cre] (<[https://orcid.org/0000-0002-9509-0314](https://orcid.org/0000-0002-9509-0314)>) > Maintainer: Guandong Shang <shangguandong1996@163.com> > Built: R 4.1.0; ; 2021-06-30 12:58:30 UTC; windows > > -- File: C:/Users/dell/AppData/Local/Temp/RtmpOi6uoY/file4e402cec56b8/lib/FindIT2/Meta/package.rds > > Thanks for your help :) - File (PNG): image.png

GuandongShang (09:07:45): > please forgive me if I misunderstand something : )

Lori Shepherd (09:11:09): > This is the result of you running it locally. You need the admin credentials to accurately run that particular bioccheck. If you registered you email, on your next build through the single packages builder it should run without error. If it still persists please post on your issue and we can investigate further

GuandongShang (09:17:39) (in thread): > Thanks, I will see it : )

GuandongShang (09:34:33): > Hi, I am sorry I just have another issue(http://bioconductor.org/spb_reports/FindIT2_buildreport_20210630070619.html#riesling1_check_anchor). MycalcRP_coveragefunction run successfully on linux and macos system ,but has a error onWindows Server 2019 Standard/x64But I has run successfully on my windows PC. According to the error, it seems that it has a error onimportfunction fromrtracklayer. Is it because I rename seqlevels not correctly ? or my bigwig file is not right ? > > **** running examples for arch 'i386' ... [11s] ERROR > Running examples in 'FindIT2-Ex.R' failed > The error most likely occurred in: > > > base::assign(".ptime", proc.time(), pos = "CheckExEnv") > > ### Name: calcRP_coverage > > ### Title: calcRP_coverage > > ### Aliases: calcRP_coverage > > > > ### **** Examples > > > > if (require(TxDb.Athaliana.BioMart.plantsmart28)) { > + Txdb <- TxDb.Athaliana.BioMart.plantsmart28 > + seqlevels(Txdb) <- paste0("Chr", c(1:5, "M", "C")) > + bwFile <- system.file("extdata", "E50h_sampleChr5.bw", package = "FindIT2") > + > + RP_df <- calcRP_coverage( > + bwFile = bwFile, > + Txdb = Txdb, > + Chrs_included = "Chr5" > + ) > + > + } > Loading required package: TxDb.Athaliana.BioMart.plantsmart28 > Loading required package: GenomicFeatures > Loading required package: AnnotationDbi > Loading required package: Biobase > Welcome to Bioconductor > > Vignettes contain introductory material; view with > 'browseVignettes()'. To cite Bioconductor, see > 'citation("Biobase")', and for packages 'citation("pkgname")'. > > >> preparing gene features information... 2021-06-30 6:54:22 AM > >> some scan range may cross Chr bound, trimming... 2021-06-30 6:54:23 AM > >> preparing weight info... 2021-06-30 6:54:23 AM > >> loading E50h_sampleChr5.bw info... 2021-06-30 6:54:23 AM > Warning in .local(con, format, text, ...) : > Invalid argument > lseek(5, 28651, invalid 'whence' value (1822621639)) failed > Error in .local(con, format, text, ...) : UCSC library operation failed > Calls: calcRP_coverage ... <Anonymous> -> <Anonymous> -> import -> import -> .local -> .Call > Execution halted > **** running examples for arch 'x64' ... [49s] OK > * checking for unstated dependencies in 'tests' ... OK > * checking tests ... > **** running tests for arch 'i386' ... > Running 'testthat.R' [42s] > [42s] ERROR > Running the tests in 'tests/testthat.R' failed. > Last 20 lines of output: > Joining, by = "feature_id" > `geom_smooth()` using formula 'y ~ x' > Joining, by = "feature_id" > Joining, by = "feature_id" > `geom_smooth()` using formula 'y ~ x' > == Failed tests ================================================================ > -- Error (test_calcRP.R:9:5): calcRP_coverage test ----------------------------- > Error: UCSC library operation failed > Backtrace: > x > 1. +-FindIT2:::quiet(...) test_calcRP.R:9:4 > 2. | \-base::force(x) > 3. \-FindIT2::calcRP_coverage(bwFile = bwFile, Txdb = Txdb, Chrs_included = "Chr5") > 4. +-rtracklayer::import(bwFile, format = "Bigwig", as = "RleList") > 5. \-rtracklayer::import(bwFile, format = "Bigwig", as = "RleList") > 6. +-BiocIO::import(FileForFormat(con, format), ...) > 7. \-rtracklayer::import(FileForFormat(con, format), ...) > 8. \-rtracklayer:::.local(con, format, text, ...) > > [ FAIL 1 | WARN 1 | SKIP 0 | PASS 61 ] > Error: Test failures > Execution halted > **** running tests for arch 'x64' ... > Running 'testthat.R' [45s] > [45s] OK > > I search some issue aboutError: UCSC library operation failedon google, but it seems that about reading bigwig on the web? > > Best wishes > Guandong Shang

Mike Smith (10:10:56) (in thread): > Note that this occurs only when “running examples for arch ‘i386’” which is the 32-bit version of R. It looks like it’s fine when running the example on “x64” or the 64-bit version. > > Perhaps you could try checking if you encounter the error by explicitly running 32-bit R (I think that’s an option from the Windows start menu) and running the example code there. > > That doesn’t really help with why it’s happening, but maybe it help direct efforts and will let you test things without waiting for the single-package builder to report back.

Ben Story (14:37:25): > @Ben Story has joined the channel

Ben Story (15:41:09): > I’m trying to submit a new package (mitoClone2) that takes advantage of external software. The basic way I could do this is do a system call check to see if the user has the software installed locally - but Hervé suggested given the external software is very easy to compilehttps://github.com/cbg-ethz/SCITEwith a GPL3 license that it might be a better idea (which I totally agree with) to include the raw source code instead and have it be compiled when the package is installed. I’ve tried to do that somewhat unsuccessfully all of today. I’ve been able to throw together a cross-system configure script but I think that due to the way in which packages are assembled and checked that I’m doing it wrong. I added a configure script (see my first reply to this). And although the configure script seems to work in most cases such as when usingdevtools::load_all("./mitoClone2")- the ‘R CMD build’ fails as the vignettes require the created executable :system.file("src/scite",package = "mitoClone2")and although thatsciteexecutable is created with theload_allcommand it seems to not be created during theR CMD buildcall. This results in a failure to create my vignettes and thus an error. Any ideas or suggestions would be greatly appreciated. Thanks.

Mike Smith (15:41:14) (in thread): > Just to confirm, I see this behaviour in 32-bit Windows but not in 64-bit. Here’s a minimal example that uses the file in {FindIT2} but calls {rtracklayer} directly: > > > R.version > _ > platform i386-w64-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status > major 4 > minor 1.0 > year 2021 > month 05 > day 18 > svn rev 80317 > language R > version.string R version 4.1.0 (2021-05-18) > nickname Camp Pontanezen > > > bwFile <- system.file("extdata", "E50h_sampleChr5.bw", package = "FindIT2") > > bwInfo <- rtracklayer::import(bwFile, format = "Bigwig", as = "RleList") > Error in .local(con, format, text, ...) : UCSC library operation failed > In addition: Warning message: > In .local(con, format, text, ...) : Invalid argument > lseek(3, 28651, invalid 'whence' value (1822621639)) failed >

Ben Story (15:42:52) (in thread): > #!/bin/bash``case "$(uname -s)" in`` Darwin)`` ## Mac OS X`` clang++ -stdlib=libc++ src/SCITEpkg/findBestTrees.cpp src/SCITEpkg/matrices.cpp src/SCITEpkg/mcmcBinTreeMove.cpp src/SCITEpkg/mcmc.cpp src/SCITEpkg/mcmcTreeMove.cpp src/SCITEpkg/output.cpp src/SCITEpkg/rand.cpp src/SCITEpkg/scoreBinTree.cpp src/SCITEpkg/scoreTree.cpp src/SCITEpkg/treelist.cpp src/SCITEpkg/trees.cpp -o src/scite`` ;;`` Linux)`` ## Linux `` g++ -Wl,--hash-style=both -std=c++11 src/SCITEpkg/findBestTrees.cpp src/SCITEpkg/matrices.cpp src/SCITEpkg/mcmcBinTreeMove.cpp src/SCITEpkg/mcmc.cpp src/SCITEpkg/mcmcTreeMove.cpp src/SCITEpkg/output.cpp src/SCITEpkg/rand.cpp src/SCITEpkg/scoreBinTree.cpp src/SCITEpkg/scoreTree.cpp src/SCITEpkg/treelist.cpp src/SCITEpkg/trees.cpp -o src/scite`` ;;``esacThis is the ‘configure’ file in the package directory.

Mike Smith (15:52:27) (in thread): > I don’t think the system specific configure is a common approach (although I may be wrong). I don’t think it’s safe to assume a specific compiler based on the platform. I think typically the safer approach is to use the output from commands likeR CMD config CCto set environment variables that contain the settings used to build R itself. Then you don’t need any case statements, you can do the compilation along the lines of$CC $CLFAGS mysource.cpp -o outputYou can take a look athttps://github.com/grimbough/Rhdf5lib/blob/master/configure.ac#L17-L19for examples of the first part about finding the compiler etc.

Mike Smith (16:03:56) (in thread): > I did something slightly different inhttps://code.bioconductor.org/browse/rhdf5filters/tree/master/because I wasn’t very happy that in Rhdf5lib the configure script was also doing compiling. > > My alternative approach was to useconfigure.acin the same way as before, but to pass the settings tosrc/Makevarswhich manages the compilation of several external libraries. This might also be an appropriate strategy for you.

Mike Smith (16:23:20) (in thread): > I see@Hervé Pagèscomment now inhttps://community-bioc.slack.com/archives/CEQ04GKEC/p1625073664129100?thread_ts=1624908635.127500&cid=CEQ04GKECThe part about it “not being a real configure script” is the same sentiment I have about what should be handling the compilation. - Attachment: Attachment > I think this can be achieved by placing a Makefile or configure script in the top-level folder of the package. The former being probably the preferred option. For the latter, this wouldn’t be a “real” configure script, only a small handcrafted one that contains commands for compiling scite and placing the executable somewhere under the package installation folder. > I don’t have a good example of a Bioconductor package doing this, sorry. Maybe browse/search https://code.bioconductor.org/ for some inspiration? You could also ask on the #package-submission channel.

GuandongShang (21:14:12) (in thread): > Hi, MIke. I can reproduce this error in my 32.bit R. But I think it may not related my bigwig. > > I just download a data package on bioconductor. it also report a error > > BiocManager::install("derfinderData") > > > file <- system.file("extdata/AMY", "HSB126.bw", package = "derfinderData") > > rtracklayer::import(file, > + format = "Bigwig", > + as = "RleList" > + ) > Error in .local(con, format, text, ...) : UCSC library operation failed > In addition: Warning message: > In .local(con, format, text, ...) : Invalid argument > lseek(3, 465961, invalid 'whence' value (1822621639)) failed >

GuandongShang (21:15:29) (in thread): > And I also find a related issue:https://support.bioconductor.org/p/129446/

GuandongShang (21:20:51) (in thread): > Thanks for pointing out problem again, Mike ! I think it may be related with rtracklayer on windows according to the issues:https://github.com/lawremi/rtracklayer/issues/52

Peter Hickey (22:51:05): > From Description in?rtracklayer::BigWigFile > > These functions do not work on Windows

Peter Hickey (22:52:15): > so i think you’ll need to make the code in the vignette that works with BigWig files conditional on the operating system (the example in?rtracklayer::BigWigFilegives one way of achieving this)

GuandongShang (22:55:59) (in thread): > Thanks, I will fix it :)

2021-07-02

Hervé Pagès (02:39:07) (in thread): > Hi@Oliver Voogd, > Were you able to solve this? If so, would you mind sharing what you did on the bioc-devel mailing list? Davide Corso is facing a similar issue with his package and is asking for help there:https://stat.ethz.ch/pipermail/bioc-devel/2021-July/018258.htmlThanks!

Davide Corso (03:11:27): > Hi all, > In the last build report of my submission (https://github.com/Bioconductor/Contributions/issues/2168) there is the following warning to solve for Windows system > > Warning: file 'spatialDE/configure' did not have execute permissions: corrected > > but I’m not sure how to fix it because in my pc that file does have the right execute permissions > Does anyone have any tips to fix it? > > Best regards > Davide

Mike Smith (04:35:54) (in thread): > I don’t know of any solution to this, I’ve tried in the past to fix this for my packages and got nowhere. I assume it’s some Windows oddity. However I also don’t think it’s an barrier to getting the package included in Bioconductor. Here’s some examples of existing packages that also show the warning:Rhtslib,Rhdf5lib,BiocParallel

Davide Corso (05:04:00) (in thread): > Thank you@Mike Smithok so at this point I guess I just have to wait for the review to finish, to understand if they accept the package or not

Mike Smith (05:14:41) (in thread): > Looking at the build report for your package, it does seem strange that this is highlighted as a warning, where as it is not for packages like those above that are in the system. I wonder if this is an unintentional configuration difference between the submission checks and those run on accepted packages. > > I think it’s common for a review to only really start once all the badges have changed to “OK”, so it may be worth writing a comment in the Github issue to your reviewer, mentioning that that this seems to be the only warning. Otherwise they may assume there are other problems to fix before a review should start.

Davide Corso (08:56:18) (in thread): > I have already posted a comment in the submission issue, also with the tag for the designated reviewer but still have not received a response

Ben Story (11:45:33): > Any suggestions for my package that still fails the Windows build step? > > g++ -c -o bam2R_10x.o bam2R_10x.cpp > bam2R_10x.cpp:18:10: fatal error: htslib/sam.h: No such file or directory > #include "htslib/sam.h" > ^~~~~~~~~~~~~~~~~~~~~~~~~~ > compilation terminated. > make: ***** [<builtin>: bam2R_10x.o] Error 1 > ERROR: compilation failed for package 'mitoClone2' > > The code being compiled is modeled after bam2R from the deepSNV function which is already on BioC. I tried to test this myself on a Windows and it took me many hours to get the right libs working through (rtools –> rtools_packages) and ultimately it now compiles and builds fine on my local Windows machine (after installing openssl and curl). Either via install.packages(type=‘source’) or R CMD build. Is there something else that I could try? Can’t seem to replicate it on my end. Thanks.

Ben Story (11:47:02) (in thread): > The Makevars is essentially identical to that of deepSNV, i even added a Makevars.win with some extra params but the error didn’t change. Does it have something to do with the order of the commands maybe?https://github.com/benstory/mitoClone2/blob/main/src/Makevars

2021-07-03

Oliver Voogd (20:16:29) (in thread): > Usingchmod +x configuredid work. I’ll reply on the mailing list.

Oliver Voogd (20:21:19) (in thread): > I had the same issue with my package. What worked was usingchmod -x configureon Unix, then committing the change. Hopefully this works for your package as well.

Oliver Voogd (20:30:40): > Hi all, > I’m running into an error on the Windows build system I can’t seem to get rid of: > > Warning in file(con, "r") : > cannot open file 'D:/biocbuild/bbs-3.14-bioc/R/etc/x64/Makeconf': Permission denied > Error in file(con, "r") : cannot open the connection > * removing 'C:/Users/pkgbuild/AppData/Local/Temp/RtmpAVmUJQ/Rinst32ec72241ffa/FLAMES' > ----------------------------------- > ERROR: package installation failed > > Does anyone have any suggestions? The package passes all builds on Linux and macOS

2021-07-06

Oliver Voogd (04:15:07) (in thread): > It looks like this error is due tohtslib/sam.hnot being available on the windows build system. You could try usingRhtslibwhich provides htslib to all platforms. Hopefully that helps! - Attachment (Bioconductor): Rhtslib > This package provides version 1.7 of the ‘HTSlib’ C library for high-throughput sequence analysis. The package is primarily useful to developers of other R packages who wish to make use of HTSlib. Motivation and instructions for use of this package are in the vignette, vignette(package=

Ben Story (05:11:02) (in thread): > I have it previously set to import Rhtslib in the DESCRIPTION and in the NAMESPACE. I used the Makevars from other packages that import Rhtslib (e.g. deepSNV, diffHic) as a template. They all have a very minimal Markvars (they don’t even have Makevars.win) file. Each contains simply thisRHTSLIB_LIBS=$(shell "${R_HOME}/bin${R_ARCH_BIN}/Rscript" -e \`` 'Rhtslib::pkgconfig("PKG_LIBS")')``RHTSLIB_CPPFLAGS=$(shell "${R_HOME}/bin${R_ARCH_BIN}/Rscript" -e \`` 'Rhtslib::pkgconfig("PKG_CPPFLAGS")')``PKG_LIBS=$(RHTSLIB_LIBS)``PKG_CPPFLAGS=$(RHTSLIB_CPPFLAGS)"I’m wondering if for some reason the requirements have changed since then in terms of importing? Or if linking to htslib is different on Windows machines than Mac/Linux (where it works fine). There is a huge amount of configuration present in Make files of the actual Rhtslib package but I would be hard-pressed to figure out which ones would be needed on my end.

Mike Smith (05:11:27) (in thread): > mitoClone2 hasLinkingTo: Rhtslib (>= 1.13.1)in the DESCRIPTION file, so it should already be finding thehtslib/sma.hheader provided by Rhtslib. > > Indeed the compilation works fine on my Windows machine.

Mike Smith (05:15:15) (in thread): > I wonder if this is in someway related to the thecannot open file 'D:/biocbuild/bbs-3.14-bioc/R/etc/x64/Makeconf': Permission deniederror. I’ve never seen that before, and it doesn’t appear on my machine or the nightly builder. However it’s apparently present for (at least) two packages on the single-package builder used during submission.

Mike Smith (06:03:50) (in thread): > I can replicate this behaviour if I remove execute permissions to the equivalent Makeconf file on my machine (C:/Program Files/R/R-4.1.0/etc/x64/Makeconf). > > * installing **source** package 'mitoClone2' ... > **** using staged installation > **** libs > make: C:/PROGRA~1/R/R-41~1.0/etc/x64/Makeconf: Permission denied > g++ -D_FILE_OFFSET_BITS=64 SCITEpkg/*.cpp -o scite > SCITEpkg/findBestTrees.cpp:56:8: warning: built-in function 'gamma' declared as non-function [-Wbuiltin-declaration-mismatch] > double gamma = 1; > ^~~~~~~~~ > SCITEpkg/mcmcBinTreeMove.cpp: In function 'int pickNodeToMove(int*, int)': > SCITEpkg/mcmcBinTreeMove.cpp:75:1: warning: control reaches end of non-void function [-Wreturn-type] > } > ^ > mkdir -p "C:/RBuildTools/4.0/tmp/RtmpUHCxH7/Rinst20d47d38733/00LOCK-mitoClone2/00new/mitoClone2/libs/" > cp scite "C:/RBuildTools/4.0/tmp/RtmpUHCxH7/Rinst20d47d38733/00LOCK-mitoClone2/00new/mitoClone2/libs/" > rm scite > g++ -c -o bam2R_10x.o bam2R_10x.cpp > bam2R_10x.cpp:18:10: fatal error: htslib/sam.h: No such file or directory > #include "htslib/sam.h" > ^~~~~~~~~~~~~~~~~~~~~~~~~~ > compilation terminated. > > So this looks like a server configuration issue to me, rather than something that needs to be fixed in the package. We should bring this to the attention of@Hervé Pagèsand@Andres Wokaty(not sure who manages which machines).

Ben Story (06:04:55) (in thread): > Hi Mike thanks for your input. Yeah it’s very cryptic to me. Looking at the Rhtslib Makevars, I’m wondering if maybe copying the hts files a user lib folder would change anything:https://github.com/Bioconductor/Rhtslib/blob/master/src/Makevars.win

Andres Wokaty (09:53:30) (in thread): > @Mike SmithThanks for bring it to our attention. I don’t manage the window machines, but@Lori Shepherdis looking into it.

Mirko Brüggemann (10:35:51): > @Mirko Brüggemann has joined the channel

2021-07-08

Ben Story (10:24:16) (in thread): > Thanks for the help everyone. Compiles successfully now!

2021-07-12

Lori Shepherd (12:01:35): > Bioconductor is pleased to announce a call for community volunteers to > assist with Bioconductor Package Reviews. This is an excellent way to get > involved with and give back to the Bioconductor Community. The minimum > requirement to volunteer is to be actively maintaining an existing Bioconductor > package. Please readReviewers Expectationsfor full details and information.

2021-07-14

Lluís Revilla (03:29:42): > Not sure if this is the right place but the new forms for issues on GitHub might be helpful to fill the submission issue easier:https://github.blog/changelog/2021-06-23-issues-forms-beta-for-public-repositories/ - Attachment (The GitHub Blog): Issues forms beta for public repositories | GitHub Changelog > Issues forms beta for public repositories

2021-07-16

GuandongShang (02:56:49): > Hi, everyone. I have a package that has been marked as 3a. accept and the bot says my package will be added to the Bioconductor nightly builds . Now, I just have two question: > 1. I am waiting my package to be added to Bioconductor’s git repository. During this time, can I bump version and push to Bioconductor git repo as before ? > 2. In thehttps://bioconductor.org/developers/how-to/git/pull-upstream-changes/andhttps://bioconductor.org/developers/how-to/git/sync-existing-repositories/, it mentioned that Fetch changes from Bioconductor. I am curious what changes will be added to my code by Bioconductor. For now, I just know the version bump introduced byBioconductorteam. > Thanks for your reading :)

Hervé Pagès (04:27:25) (in thread): > Hi@GuandongShang, > 1. I think it’s ok to bump version and push changes togit.bioconductor.orgafter acceptance and before addition to the nightly builds. > 2. Besides the automatic version bumps that we do on all packages every 6 months as part of the release process, we might occasionally need to push some minor fixes to your package. This is very unusual and is most of the time cosmetic (e.g. we repair theDESCRIPTIONfile for you, or we add/fix a biocViews term to it). Or we need to add a.BBSoptionsfile to the package. Also sometimes we need to fix a problem introduced by a change in a low-level infrastructure package that we maintain and that is affecting your package. All these situations are very rare but they can happen. This is why we recommend to get into the habit of doing a sync of the 2 repos (git.bioconductor.organd GitHub) before pushing anything to avoid merge conflicts. > Hope this helps.

GuandongShang (04:31:03) (in thread): > Thanks,@Hervé Pagès. And I am wondering whether I can have some GUI options just like Github for seeing my package on Bioconductor git repo besides cloning into local.

Nitesh Turaga (08:32:43) (in thread): > https://code.bioconductor.org/browse/@GuandongShang - Attachment (code.bioconductor.org): Bioconductor Code: Browse > Browse the content of Bioconductor software packages.

GuandongShang (20:43:45) (in thread): > @Nitesh TuragaThanks!

2021-07-19

Leo Lahti (17:02:10): > @Leo Lahti has joined the channel

2021-07-21

Alan Murphy (04:09:39): > Hi, does anyone know the deadline for inclusion of package updates/new packages to Bioconductor 3.14? I can’t seem to find it in any documentation

Federico Marini (05:22:10): > You can expect that to be approximately +6 months after the deadline of the 3.13 release

Federico Marini (05:23:07): > this, at least, is a reasonable estimate. > Then: this can change also as we approach that time of the year, as these release cycles are often tightly related to the releases of the software R itself

Federico Marini (05:23:56): > If I would be forced to give a date now, I’d say around Mid October, to be safe:slightly_smiling_face:

Alan O’C (07:24:30): > New packages may be slightly tighter, as it seems there’s always a big rush to get new packages in before release, so the review team may be extremely busy close to the deadline:slightly_smiling_face:

Lori Shepherd (07:38:02): > if you shoot to have the package submitted by mid to late sept to make sure there is adequate time for a review – the last few fall releases have indeed been mid/late oct or first week in nov

2021-07-23

Batool Almarzouq (15:53:50): > @Batool Almarzouq has joined the channel

2021-07-24

rohitsatyam102 (06:21:40): > Sorry. Was posting in other slack channel!!

rohitsatyam102 (06:24:35): > But I wish to ask whom to tag in Bioconductor Forum if I have a query regarding package development!!

rohitsatyam102 (06:26:12) (in thread): > like there are Post Tag to tag Bioconductor Packages you are facing problem with.

Vince Carey (07:46:18) (in thread): > you can tag me@Vince Careyand i will forward if needed

2021-07-27

Haichao Wang (08:26:49): > Hello, when will the package have a landing page on bioconductor website after being accepted?

Haichao Wang (08:31:24): > also cannot see my codes in thehttps://code.bioconductor.org/browse/ - Attachment (code.bioconductor.org): Bioconductor Code: Browse > Browse the content of Bioconductor software packages.

Lori Shepherd (08:34:52): > Once the issue is processed after being accepted, they are added to the manifest and should have a devel landing page within 24-48 hours. A Bioconductor official landing page is not considered atcode.bioconductor.orgbut athttps://bioconductor.org/packages/ .@Mike Smithdo you know more details on how quicklycode.bioconductor.orgpicks up new packages added and if it includes devel packages or only release packages?

Mike Smith (08:43:08): > The code.bioconductor website syncs every 30 minutes with the main git repository. It will only included packages that have been added to the Bioconductor package manifest, but once once they’re added there it will included the develmasterbranch alongside all availableRELEASE_X_Ybranches. There’s a few more details onhttps://code.bioconductor.org/about.html

2021-08-05

Manojkumar Selvaraju (17:58:12): > @Manojkumar Selvaraju has joined the channel

2021-08-18

Aedin Culhane (09:41:34): > If you have developed a Bioconductor Package and learned the challenges along the way If you have tips and tricks for would-be developers. Please consider joining the new Bioconductor Mentorship program to help new would be developers get from R scripts to Bioconductor package. Expression of interest form athttps://forms.gle/fya5JEArTT5kNEGr9 - Attachment (Google Docs): Bioconductor Developer Mentorship Program - Expression of Interest > Please indicate your interest to learn more and potentially become a mentor in the Bioconductor Developer Mentorship program. The Bioconductor Developer Mentorship Program will form a part of the Bioconductor “welcome mat” that the Bioconductor Community Advisory Board are developing. It will be a group-mentorship/buddy program for would-be, new, or hesitant developers or for developers who wish to refresh their skills. The goal of the program is to welcome and onboard new developers, develop educational material to assist new developers, improve the quality of packages submitted to Bioconductor, and strengthen community and interactions between Bioconductor developers. Mentors should have at least 1 package either in the release or accepted in the development branch of Bioconductor. Each program cycle would run for 6 months (or the development cycle of Bioconductor package release). For more information about the program see the Bioconductor Website [link].. or Google doc [https://docs.google.com/document/d/1Q-Hxmy0ZcKzKSbB-dtg02gJRlZ0Vi6WNOTF-W3bwjmY/edit?usp=sharing]

2021-09-06

Eddie (08:23:09): > @Eddie has joined the channel

2021-09-11

Wes W (13:32:28): > @Wes W has joined the channel

2021-09-16

Henry Miller (18:35:01): > @Henry Miller has joined the channel

2021-10-06

Alan Murphy (04:26:36): > Hey, just to mention that I think the nightly builds didn’t run yesterday (see below). I’m just mentioning it as I made final changes to my packages ahead of the bioc 3.14 release and I want to make sure they pass checks before the deadline - File (PNG): image.png

Lori Shepherd (07:35:13): > Sorry for the inconvenience. Upon inspection we had some trouble with our mac builder that prevented the build report from posting@Andres Wokatycan confirm but I believe everything is all set and should see the updated report today.

Alan Murphy (07:35:58) (in thread): > No problem at all, thank you!!

Andres Wokaty (08:33:03) (in thread): > We’ll see the report today.

2021-10-11

Alan Murphy (06:06:20): > Hi, the check results site for the devel branch (3.14) appears to be down (Apologies for the repeated messages on this but I’ve made changes to a package which was failing checks and I want to make sure it is passing before the code freeze tomorrow). - File (PNG): image.png

Alan O’C (07:27:40) (in thread): > Aye, down for me also

Hervé Pagès (15:53:01) (in thread): > Is this about a package submission? If it’s about the daily builds, it would be better to use the#bioc-buildschannel. I think that what was down was the website. It’s back now and today’s 3.14 report is available.

Alan Murphy (17:49:09) (in thread): > Sorry yes, I’ll use that channel in future, thanks!

2021-10-13

Kayla Interdonato (11:25:09): > @Kayla Interdonato has joined the channel

2021-10-15

Yagmur Simsek (17:00:12): > @Yagmur Simsek has joined the channel

2021-11-23

Tyler Gorrie-Stone (09:31:22): > @Tyler Gorrie-Stone has joined the channel

2021-11-26

Francesc Català (06:47:05): > @Francesc Català has joined the channel

2021-12-01

Chris Vanderaa (06:12:29): > @Chris Vanderaa has left the channel

2022-01-03

Kurt Showmaker (17:04:55): > @Kurt Showmaker has joined the channel

2022-01-28

Megha Lal (11:14:02): > @Megha Lal has left the channel

2022-03-20

Sarvesh Nikumbh (21:41:23): > @Sarvesh Nikumbh has joined the channel

2022-03-23

Lukas Weber (09:18:52): > @Lukas Weber has joined the channel

Lukas Weber (09:30:11): > Hi all, just moving a discussion here that I started in the wrong channel, apologies > > I was wondering if the requirement to haveDepends: R (>= 4.2)inDESCRIPTIONfor new package submissions is overly restrictive, since it means that packages cannot easily be installed from GitHub any more (after submission to Bioc) by users who may be using a release version of R instead of R-devel (which returns an error in this case). > > I was thinking about this in the context of a new package I am working on, which I have tested on both R 4.1 and R 4.2, but adding the strict version dependencyR (>= 4.2)inDESCRIPTIONnow means it can’t be installed easily from GitHub any more. > > I think the consensus / suggestion is that we create some git branches and then provide current users with instructions to install fromref = branch_nameto install in R-release. But I worry that this is making things too complicated overall (especially for downstream users who may not be so familiar with either git branches or Bioc-devel), and I think maybe it would be better to simply removeR (>= 4.2)fromDESCRIPTION. I think this would most likely still work fine, since the package is still being tested in R 4.2 on the builders, so it will not be accepted / pass the build reports if it does not work correctly with R 4.2. > > For my package I will add branches for now, but just wondering if anyone else has any further suggestions / ideas / comments. Thank you!

Alan O’C (09:32:25) (in thread): > I also dislike this requirement; BiocManager already enforces R versions when installing from Bioconductor. I think it’s excessive to restrict installing manually

Federico Marini (11:14:13) (in thread): > IIRC this is some kind of recurring discussion. > I do understand both views, and respect them fully. But yes, somehow it is “overly restrictive”, but mostly for the casual/candidate potential new users

Kasper D. Hansen (11:36:39): > @Kasper D. Hansen has joined the channel

Kasper D. Hansen (11:37:02): > Wow, we have both#package-submissionand#package_submissionsPretty confusing

Lukas Weber (11:38:35) (in thread): > Yes, I am mostly concerned from the perspective of downstream users, since they can no longer simply doremotes::install_github()with default settings (in R-release). For developers it is all okay, but for new users I think it adds friction to explain e.g. branches andrefsetc

Kasper D. Hansen (11:38:54): > Anyway, I’ll add my comments to@Lukas Weberquestion. First I’ll bypass the DESCRIPTION file requirement and just say this: it is not only your package which has to be “new”, it also goes for all your dependencies. For example, could a user install and use your new packagewithoutthe latest and greatest SpatialExperiment. And what about the dependencies of SpatialExperiment?

Kasper D. Hansen (11:40:31): > Not to see this is done without any testing. Now, in very specific cases you know that your package can run under the release version of Bioc, with a devel installation “only of your package”. But frankly, I suspect that is rarer than you expect because of dependencies. And it also leaves the user’s machine in a state which “we” (Bioc) doesn’t want it to be in, with a mix of release and devel.

Kasper D. Hansen (11:41:13): > Now, this explains why you really shouldn’t encourage this. But ok, in some specific instances, the developer knows this will work (although I am not sure in this case … SpatialExperiment), so what could we do

Kasper D. Hansen (11:45:37): > 1. We could relax the dependency on R in DESCRIPTION. Historically, Bioc has been really lax about this and havefor surereleased packages which did NOT work under some R versions without a DESCRIPTION requirement. Ie. essentially making a wrong “promise”. That’s one issue. > 2. You are probably hosting your package on Github. One could take the point of view that you can tell people what to do (and how to mess up their machines, and provide support for this) on your github repository and leave Bioc git out of this. > 3. Finally, and this is by-passing the discussion, but perhaps we should decidenotreleasing Bioc at the same time as R, perhaps we should have a 1-2months lag. In the past we needed new features from R quickly, but I am not sure how often this is the case anymore. A delay might add some sanity to everyone

Kasper D. Hansen (11:46:44): > I must say that in the short term, I am tempted to say you should do 2. and deal with all these issues yourself. There is lots of potential confusion and problems with encouraging installations of devel packages in a release environment

Kasper D. Hansen (11:47:24): > Longer term, perhaps we should discuss what the benefits / drawbacks are of the simultaneous release.

Alan O’C (11:50:28): > If I’m not mistaken, the version requirement isn’t enforced for packages already on Bioconductor, though.

Lukas Weber (11:55:59): > Yes, these are good points re dependencies@Kasper D. Hansen. I would probably lean towards preferring option 1 above, and leaving it up to the developer to test on R-release (4.1) if they want to include this, since this makes things easiest for downstream users. > > As a specific example, here is how I previously provided installation instructions on the GitHub readme for a package I am working on right now (see screenshot). These instructions worked in both R 4.1 and 4.2. > > If I now changeDESCRIPTIONto includeDepends: R (>= 4.2)for the Bioc submission requirements, then these installation instructions return an error. I think the easiest option for me as developer will be to add a branch with lower R version dependency inDESCRIPTION, and update the GitHub installation instructions line toremotes::install_github("lmweber/nnSVG", ref = "4.1")or similar. Then people can still install the package until the Bioc-release date. I think the alternative of requiring downstream users to install R-devel to use new Bioc packages is too much, since this will create all sorts of problems on their laptops if they are unfamiliar with how R versions work and where library directories are saved etc. - File (PNG): Screen Shot 2022-03-23 at 11.53.23.png

Kasper D. Hansen (11:57:47): > You can just manually remove the R requirement when you push to github

Lukas Weber (11:58:31) (in thread): > True, I like to keep GitHubmainbranch and Bioc-develmasterin sync though, for easier maintenance

Kasper D. Hansen (11:58:33): > And you’re underestimating the potential problems you cause by mixing release and devel on the same machine, as you do with your instructions.

Kasper D. Hansen (11:59:56): > I also hope this instruction set only appears on your github and not in package documentation.

Lukas Weber (12:00:07) (in thread): > yep, github only

Lukas Weber (12:00:30) (in thread): > and will replace withBiocManageronce it is included in Bioc

Marcel Ramos Pérez (12:02:19) (in thread): > It depends on how tightly integrated your package is to the Bioconductor ecosystem. There are quite a number of bug fixes and updates that happen in devel which you may be developing on top of (directly or indirectly). You can still take a chance with Bioc release and the package may work in release but really, Bioc release users should be waiting for the next stable release or use Bioc devel themselves. Not having a version restriction in theDESCRIPTIONwould open you up to all sorts of issues, e.g., an R 3.6 user can come along and install your package and then you as the maintainer will have to field questions about why the package doesn’t work for R 3.6… With that restriction in place, they will more consciously choose to bypass it (e.g., checking the repo out and removing the restriction) and then they would know what went wrong and not necessarily contact you if there’s an issue.

Lukas Weber (12:04:36) (in thread): > Yes, that makes sense. Trying to install in a very old version e.g. R 3.6 would cause all sorts of problems, so the restriction avoids this. However I think “checking the repo out and removing the restriction” is probably not something we can expect downstream users to know how to do

Federico Marini (12:08:23) (in thread): > The only thing I can kinda expect them to do is theyremotes::install_githuba main-synced branch where the DESCRIPTION line is gone.

Federico Marini (12:08:50) (in thread): > and it is on our side to “curate” that

Marcel Ramos Pérez (12:23:39) (in thread): > Users do all sorts of unpredictable things. Yes, you can remove the line in theDESCRIPTIONbut would that work forR <= 4.0users?

Lukas Weber (12:25:02) (in thread): > Yes, in my case it would probably make sense to haveR (>= 4.1)on GitHub, but not removing the line entirely

Lukas Weber (13:45:20) (in thread): > Thinking more about this comment – maybe the underlying issue is that I am essentially treating GitHubmainbranch as a mirror of Bioc-devel gitmasterbranch. I have been assuming most package developers are working in this way, but maybe this is not the case

Kasper D. Hansen (13:50:22) (in thread): > That’s what I do, but you don’t have to do it this way

Lukas Weber (13:52:14) (in thread): > I also have a GitHub Actions setup (Linux builder only) on GitHub as a double-check, and then simultaneously push toorigin mainandupstream main:masterwhen I make any changes, which usually works well. So here for the divergingDESCRIPTION, I would just have an additional branch on GitHub/origin only

Spencer Nystrom (14:37:37): > @Spencer Nystrom has joined the channel

2022-03-24

Kozo Nishida (01:20:16): > @Kozo Nishida has joined the channel

Henrik Bengtsson (17:16:52): > @Henrik Bengtsson has joined the channel

Henrik Bengtsson (17:23:39): > Please don’t require dependency on an R version just because it makes it harder for people to do the wrong thing. It’s like using a hammer as a screwdriver. This makes Bioc distance itself more from the rest of the R community who does not breath and live Bioc. There are Bioc packages that works just fine with very old versions of R and outside of Bioc (I maintain many of them). With false requirements like this, there’s a great risk of even more “install from GitHub” instructions, which adds more chaos than it removes.

Martin Morgan (19:06:01) (in thread): > Is it helpful to ask what you would expect, for a Bioconductor package that has only been built and checked under R 4.2 (et seq., while the package is distributed by Bioconductor)?

Alan O’C (22:34:48) (in thread): > I can only speak for myself, but I think it goes without saying that people using non-standard Bioc/R versions can’t expect much in the way of support, and IME the first question you need to ask of any issue/bug report is “what version are you using?”

2022-04-07

Jianhai Zhang (03:14:24): > @Jianhai Zhang has joined the channel

Jianhai Zhang (03:39:55): > Hello, I have a warning from BiocCheck: WARNING: removeset.seedusage in R code. > My problem is described below: > My packagemypkghas functionFunAandFunB.FunBinternally callssample(),runUMAP(),runTSNE()(scater package). I want reproducible results fromFunB, so I needset.seed. SinceFunBis submitted to remote independent HPCC clusters, I need to callset.seedon each of clusters accordingly. If I placeset.seedinFunB, I am having the warning. What is the standard solution to callset.seedon remote clusters requested byBatchtoolsParam/slurm?FUNA <- function (n) {`` # Request 5 independent clusters.`` param <- BatchtoolsParam(workers=5, cluster="slurm", template=tmpl); register(param) `` FunB <- function(i, n) { set.seed(n); sample(); runUMAP(); runTSNE() } `` # FunB works on each of the 5 independent clusters.`` xx <- bplapply(1:5, FunB) ``}

Martin Morgan (06:20:03) (in thread): > See theRNGseed=argument of?BatchtoolsParamand the vignette ‘Random Numbers in BiocParallel’. Remember that for new packages you should be using the ‘devel’ version of Bioconductor (R-4.2; Bioconductor 3.15; this implementation reflects invaluable contributions from@JiefeiWang). You would not need toset.seeed()inFunB(). > > I am not 100% confident that this mechanism works via batchtools on a cluster, and I would appreciate hearing about your experience. > > Actually, I don’t really understand the value of the developer setting the seed here – I guess UMAP / tSNE produce different outputs depending on the random number seed, but this reflects the underlying uncertainty in the algorithm. By always returning the same result, you’re presenting a more optimistic interpretation than is warranted. It would be better to let the user (a) discover that the results differ depending on random number seed and (b) let the user provide, if the purpose is reproducibility of a particular analysis, their own BiocParallelParam and RNGseed via an argument to FUNB. > > Generally, the package should not be specifying a BiocParallelParam (e.g., because the user doesn’t have access to that type of job manager, or the resources specified intmpl); see theFor developerssection of the ‘Introduction to BiocParallel’ vignette, which suggests providing an argument in the user-facing functionBPPARAM = bpparam()).

Henrik Bengtsson (13:47:16) (in thread): > I fully agree with Martin comments and suggestions. > > I want reproducible results from FunB, so I need set.seed. > The word to challenge here is “need”; do you really need to do that? Here “reproducible results” means,numericallyreproducible results. To Martin’s points, you can targetstatisticallyreproducible results instead. There are valid reason for why some methods do not producenumericallyreproducible results. The most common one is that the estimator depends on randomization. A very simple example is: > > > rank(c(1,2,2,3), ties.method = "random") > [1] 1 2 3 4 > > rank(c(1,2,2,3), ties.method = "random") > [1] 1 2 3 4 > > rank(c(1,2,2,3), ties.method = "random") > [1] 1 3 2 4 > > Yet, therank()method still producesstatisticallyreproducible results, e.g. on average you’ll get the same results. This is not a problem; it’s just part of the nature of statistics. > > If we fix the random seed in the above example, we’ll miss out on some of outcomes and our results arebiased(e.g. you no longer get the “correct” results on average). > > BTW, if it’s about getting unit tests to pass, the one has to relax the assertions fromidentical()/all.equal()on all numbers in the results, to statistical summaries, e.g. comparingmean(),sd(), etc. Sometimes it also works by just relaxingall.equal(..., tolerance = ...). > > It’s better to expose the randomness to the end user and leave it to them to fix the random seed if they want to. By fixing the seed internally, we hide the fact that our method is actually depending on randomness. Personally, I think the best way to set a random seed in any analysis is for the end user to callset.seed()at the very top of the script. That makes it very clear that it’s done.

2022-04-08

Jianhai Zhang (23:20:25) (in thread): > Hello@Martin Morgan, I tested theRNGseedargument on clusters using slurm. I set the same seed at the beginning each time, and got identical results (identical()). > > Yes, in my real functionBatchtoolsParamis passed as an argument. I have removed allset.seedfrom inside my functions. Thank you all for these explanations!@Henrik Bengtsson

2022-04-09

Umar Ahmad (20:08:02): > @Umar Ahmad has joined the channel

2022-04-14

Nicole Ortogero (19:23:05): > @Nicole Ortogero has joined the channel

2022-04-15

Nicole Ortogero (15:25:16): > We have two new packages that were submitted by the 01Apr deadline. We haven’t seen reviewers assigned yet. Will we get reviewers before release or are our packages not making the release? Just looking to plan accordingly based on when we should expect reviewer comments. > > our two packages: > SpatialOmicsOverlay - creator@Maddy GriswoldNanoStringExperiment - creator me

Maddy Griswold (15:25:22): > @Maddy Griswold has joined the channel

Laurent Gatto (15:41:32): > Submission of a package before the 1 April deadline doesn’t give any guarantees for review and inclusion - it is a very busy time for reviewers. My only advise is to make sure that sure that the packages check fine to avoid delays.

Nicole Ortogero (15:44:19): > Thanks Laurent. We will do that.

2022-04-19

Maddy Griswold (17:00:15): > One of our packages timed out on a build and we noticed that there was a 40 minute build limit. A different package that I’m working on typically takes ~70 minutes to build while I’ve been testing due to working with large image files. Is this 40 minute build set in stone or is there some workaround for larger packages?

Alan O’C (18:17:07) (in thread): > Some of this may be relevant. If it’s literally “R CMD build/check”, rather than just tests, that takes that long due to large files, the large files could probably be on ExperimentHubhttps://bioconductor.org/developers/how-to/long-tests/

Lori Shepherd (21:15:55) (in thread): > Agreed with@Alan O’C; you should look at experiment hub to store files or partial results and then implement long tests to test functionality.And yes it’s a pretty set in stone because we need the capacity to build and check all packages nightly which wood be impossible if packages take that long.The only slight exception are workflow packages but they generally have little to no code of their own and are used to demonstrate workflows or pipelines or more advanced vignettes of a package as the name suggests. If there was a way to use smaller data sets for initial package you could potentially have an associated workflow packages for a larger, complete demonstration.

Maddy Griswold (21:18:36) (in thread): > That makes sense. The image file is already getting pulled in using BiocFileCache so I don’t know if the experiment hub would make it any faster. It’s the actual processing of the image that takes the longest. I will work on getting the example and test times cut down.

2022-04-28

Alexandru-Ioan Voda (05:33:02): > @Alexandru-Ioan Voda has joined the channel

2022-05-04

Alexandru-Ioan Voda (11:41:50): > Hi! I was wondering, for BiocFileCache package purposes, are Figshare-uploaded data alright, since it has a DOI?

Lori Shepherd (12:02:38) (in thread): > In the sense that it works or licensing or can you expand a little?

Alexandru-Ioan Voda (12:32:09) (in thread): > Hi! Thanks for replying! > > I meant in terms of data-package review gold-standards. > I know that Bioconductor data-package reviews usually request that data isn’t stored on some github page or some potentially-temporary page, but rather it be somewhere where it has a digital object identifier and commitment to long-term storage, like Zenodo or such, right? > > So in terms of best practices. Figshare should probably be similar to Zenodo?

Lori Shepherd (12:34:44) (in thread): > yes I would say that is fair and should be okay@Vince Careythoughts?

Vince Carey (12:39:16) (in thread): > seems ok to me. bring up at TAB to see if there are any gotchas known to that group.

Lori Shepherd (12:40:08) (in thread): > @Alexandru-Ioan Vodathe TAB meeting is tomorrow; we can let you know for sure tomorrow around this time.

Alexandru-Ioan Voda (12:44:18) (in thread): > Thank you both!

2022-05-05

Lori Shepherd (13:00:08) (in thread): > TAB had no reservations. I would say it would be okay. If you get a reviewer once submitted that has any issues please just tag me @lshep and I’ll step in to comment if need be

2022-05-16

Pedro Sanchez (07:04:06): > @Pedro Sanchez has joined the channel

2022-05-20

Simon Pearce (03:16:25): > @Simon Pearce has joined the channel

2022-05-25

Simon Pearce (08:56:40): > Hi, > To contribute a package to bioconductor, does it have to be on github or can I use gitlab instead?

Lori Shepherd (09:00:09): > currently it has to be a github for submission. We are investigating others but don’t have a time frame if we proceed with allowing other locations yet.

2022-05-27

Simon Pearce (02:34:58) (in thread): > Thanks. I’m happy with that, helps me get the package on github rather than my institute gitlab.

2022-05-28

Leo Lahti (12:51:15): > Gitlab is open source, which I like.

2022-07-28

Mervin Fansler (17:20:30): > @Mervin Fansler has joined the channel

2022-08-12

Kevin Rue-Albrecht (10:08:53): > @Kevin Rue-Albrecht has joined the channel

Kevin Rue-Albrecht (10:17:51): > Hi all > I just ran into a BiocCheck ERROR, which I can generally agree with, but would argue that my use case warrants a pass (just like theExperimentHubseems to have). > > So. BiocCheck throw an ERROR because I have a call toBiocManager::install()(which I agree is not ideal in many cases)https://github.com/kevinrue/iSEEhub/runs/7807369621?check_suite_focus=true#step:23:83 > > * ERROR: Remove install() calls (found 1 times) > > That said, I can see that the ExperimentHub also has a call toBiocManager::install()(when it installs packages that are required to handle a data set)https://github.com/Bioconductor/ExperimentHub/blob/261ece9f336e35d782d60a954c9c14e76184c8ed/R/ExperimentHub-class.R#L96My use case is exactly the same as the Ehub (I am working on an interactive shiny interface to the Ehub), and for the purposes of interactive notifications, I find it preferable to install the dependencies myself (at runtime, I know, bad) than letting Ehub do it, which has a couple of undesirable consequences described here:https://github.com/kevinrue/iSEEhub/issues/14Thoughts?

Hervé Pagès (14:28:50) (in thread): > Having an occurrence ofBiocManager::install()in your code should not be a problem. What needs to be avoided is thatBiocManager::install()gets called in your examples, vignettes, or unit tests. More generally speaking we don’t wantR CMD buildorR CMD checkto install packages. It would be very hard to detect that this actually happens with just some static code analysis likeBiocCheckis trying to do. So I think thatBiocCheckshould just emit a WARNING or a NOTE for that (with a message asking the developer to make sure that the call is not executed duringR CMD buildorR CMD check).

Marcel Ramos Pérez (15:46:55) (in thread): > Often the examples, vignettes, and unit tests will demonstrate / test said R code soBiocManager::installwill eventually be run atR CMD buildandR CMD check, no?

Hervé Pagès (17:07:15) (in thread): > They can demonstrate said R code but that code should not get evaluated e.g. they need to use things like\donttest,\dontrun,eval=FALSEetc…

Hervé Pagès (17:14:05) (in thread): > Or the call toBiocManager::install("toto", update=FALSE)can be evaluated as long astotois inSuggests:thenR CMD checkwill require that the package is already installed so won’t re-install it. > I’m just saying an occurrence ofBiocManager::installsomewhere in the code doesn’tnecessarilymean thatR CMD buildandR CMD checkwill install packages. If there’s a risk of FALSE positive (and I think the risk is pretty high) thenBiocCheckshould not make it an ERROR.

Hervé Pagès (17:17:33) (in thread): > oops, I meantBiocManager::install("toto", update=FALSE)above. Corrected.

2022-08-13

Kevin Rue-Albrecht (05:40:29) (in thread): > Thanks for the feedback. > I’ve added two layers of failsafe to myiSEEhubpackage in the meantime: > 1. The app uses the ExperimentHub metadata to identify required dependencies (preparerclassfield) and check whether those are currently missing, BEFORE attempting to load the data set. If so, a shiny modal prompts the user BEFOREBiocManager::install()is called, whether they consent to install those packages at runtime. > 2. The function that launches the app in the first place now has an argumentruntime_install=FALSEwhich controls whether the modal in [1] is shown at all. IfFALSE, data sets that do not have their dependencies installed simply cannot be loaded in the app (a modal is shown to the user, advising to contact the app maintainer).

Kevin Rue-Albrecht (05:45:55) (in thread): > AFAIC > 1. That makes the app elegantly decline to load data sets that the maintainer for which the maintainer hasn’t installed dependencies for yet, or is not willing to support, and forbids users of the app to install those packages through the app. > 2. Alternatively, the maintainer may opt for a ‘lazy-installing’ type of approach, installing only the minimal set of packages themselves, while allowing users to install dependencies as needed from the app, when they load certain data sets for the first time.

Kevin Rue-Albrecht (05:56:42) (in thread): > Just merged if you want to give it a go:https://github.com/kevinrue/iSEEhub

Kevin Rue-Albrecht (06:26:19) (in thread): > cases 1 and 2 - File (PNG): image.png - File (PNG): image.png

2022-08-16

Jared Andrews (17:31:27): > @Jared Andrews has joined the channel

2022-08-22

rodrigo arcoverde (07:35:13): > @rodrigo arcoverde has joined the channel

2022-09-04

Gurpreet Kaur (14:59:58): > @Gurpreet Kaur has joined the channel

2022-09-12

Nils Eling (11:32:11): > @Nils Eling has joined the channel

Samuel Gamboa (13:31:32): > @Samuel Gamboa has joined the channel

2022-09-27

Jennifer Holmes (16:15:09): > @Jennifer Holmes has joined the channel

2022-10-06

Garth Kong (19:35:50): > @Garth Kong has joined the channel

2022-10-28

Alan Murphy (07:50:14): > Hi all, I’m the maintainer of theEWCE package, while the package is currently passing our checks in github actions and passing bioc checks, a few students have told us they had issues installing it. I replicated these issues on mac with a fresh install of R 4.2 and bioconductor 3.15 with the below code: > > install.packages("BiocManager") > BiocManager::install("EWCE") > > The following dependencies fail to install: > > Warning messages: > 1: dependency 'Matrix.utils' is not available > 2: In install.packages(...) : > installation of package 'ps' had non-zero exit status > 3: In install.packages(...) : > installation of package 'GenomeInfoDbData' had non-zero exit status > 4: In install.packages(...) : > installation of package 'ewceData' had non-zero exit status > 5: In install.packages(...) : > installation of package 'processx' had non-zero exit status > > I tried to install ewceData which is our associated package which is again passing all checks but this fails to install withBiocManager::install('ewceData'). My question is whether we should expect dependencies to be installed without issues and whether there is anything we can do to the package to avoid this?

Lori Shepherd (08:19:51) (in thread): > Itlooks like matrix.utils was removed from CRAN on Oct 9. Should trackdown which dependency (or if it is your package directly) uses this package and try to avoid it…. Normally dependences can be installed without issues automatically but in this case it is removed and cannot be found. You can temporarilyinstall the package from the CRAN archive

Alan Murphy (08:27:42) (in thread): > That makes sense, we think the issue was withorthogeneand have pushed a fix to it so hopefully that will sort things

Alan Murphy (08:32:02) (in thread): > Thanks for the help!

Brian Schilder (08:37:14): > @Brian Schilder has joined the channel

Hervé Pagès (13:30:54) (in thread): > @Alan MurphyJust a note that with 207 dependencies (direct and indirect) forEWCE, these problems tend to happen. Does your package needs all that? What you really want to do is try to reduce the number of deps and also choose your deps carefully. This will help make your package more robust.

2022-10-31

Alan Murphy (04:06:32) (in thread): > Thank Herve, it’s worth having a discussion on this on our end!

Chenyue Lu (10:05:25): > @Chenyue Lu has joined the channel

2022-12-02

Atuhurira Kirabo Kakopo (15:58:15): > @Atuhurira Kirabo Kakopo has joined the channel

2022-12-12

Umran (17:58:10): > @Umran has joined the channel

2022-12-14

Lijia Yu (19:39:05): > @Lijia Yu has joined the channel

2022-12-19

Michael Lynch (06:35:17): > @Michael Lynch has joined the channel

2023-01-10

Nick R. (18:40:36): > @Nick R. has joined the channel

2023-01-21

Hien (16:03:48): > @Hien has joined the channel

2023-01-26

Yu Zhang (12:32:30): > @Yu Zhang has joined the channel

2023-01-31

Francesc Català-Moll (14:34:17): > @Francesc Català-Moll has joined the channel

2023-02-28

Krithika Bhuvanesh (16:54:03): > @Krithika Bhuvanesh has joined the channel

2023-03-10

Edel Aron (15:28:12): > @Edel Aron has joined the channel

2023-03-29

Matteo Tiberti (10:12:27): > @Matteo Tiberti has joined the channel

Noriaki Sato (22:12:19): > @Noriaki Sato has joined the channel

2023-03-30

Matteo Tiberti (05:14:38): > hi everyone, do we know what a hardware setup comparable to that of the automatic builders would be? We are trying to streamline a package so that it builds in <10 minutes, we got to ~11 now, but our test machine is ~7 years old so I wonder if it’s worth shaving that extra minute off or we could get away with it. For instance, it builds under 10 minutes on a MacBook Pro with M1

Lori Shepherd (07:45:29): > If you click on a builder on the daily build report page andview the long reportyou can click on one of the builder names you can see some information, this page should probably be expanded out to see more information. I’m not sure if dockers would be an option but might be helpfulhttps://bioconductor.org/help/docker/

Matteo Tiberti (07:47:18): > thank you!

Matteo Tiberti (07:49:52): > it doesn’t seem to say very much - just the OS and compiler versions for what I can tell. I am already using Docker as a development platform (actually a custom image derived from the official BioC devel image)

Vince Carey (07:54:46): > @Matteo Tibertiif it times out we will advise you on how to reduce the time consumed. there is also a longtests capacity in the build system. it sounds like you have done due diligence.

Matteo Tiberti (07:55:30): > thanks@Vince Carey- we’re trying our best:sweat_smile:

Lori Shepherd (08:10:57): > is the time constraint hit because of tests being run or can that contribute? If so there Seehttp://contributions.bioconductor.org/long-tests.htmlthat might be an option too that@Vince Careyreferenced above - Attachment (contributions.bioconductor.org): B Long Tests | Bioconductor Packages: Development, Maintenance, and Peer Review > B.1 What are they Code in the tests subdirectory of all Bioconductor software packages is run by R CMD check on a daily basis as part of the Bioconductor nightly builds. The maximum amount of time…

Matteo Tiberti (08:12:51): > yep, unfortunately this is without tests, so I don’t think it applies

Vince Carey (08:13:31): > Precomputing parts of vignettes can help cut times. You then verify that the precomputes are not stale in the longtests space

Matteo Tiberti (08:14:32): > oh that’s a cool idea@Vince Carey. I would first see if we actually need to go those lengths in review, I don’t think we’ll have time to restructure things now. We’re trying to hit the 3.17 deadline

Matteo Tiberti (12:54:32): > I’ve been trying to clean our GitHub repo (227 MB pack file to 5 MB…) using BFG, but uponpush --forceand recloning, the GitHub repo clones to the same size as before. I’m really not sure why. Any suggestion?

Lori Shepherd (13:23:53): > you committed changes before pushing?

Matteo Tiberti (13:34:32): > I don’t think so, it was a freshly cloned repo to be safe

Matteo Tiberti (13:35:06): > since I couldn’t find a solution, I have created a new repo to push master to, and will refer to the old repo for all the rest

Matteo Tiberti (13:35:22): > thanks anyhow@Lori Shepherd!

Lluís Revilla (16:58:32): > In the Contributors book there is a recommendation to usegit rev-list(this was initially reported here or in#bioc_git), Maybe it is helpful in your case too - Attachment (contributions.bioconductor.org): Chapter 21 Git Version Control | Bioconductor Packages: Development, Maintenance, and Peer Review > The Bioconductor project is maintained in a Git source control system. Package maintainers update their packages by pushing changes to their git repositories. This chapter contains several…

2023-03-31

Matteo Tiberti (03:17:26): > thanks@Lluís Revilla- I had tried that as well, but I couldn’t get a small pack file enough without removing files in myHEAD(whichbfgprotects instead)

2023-04-01

vedha (14:44:04): > @vedha has joined the channel

2023-04-03

Mengbo Li (20:45:31): > @Mengbo Li has joined the channel

2023-04-04

Jacques SERIZAY (05:02:24): > @Jacques SERIZAY has joined the channel

2023-04-05

Nick R. (01:12:22): > Hi, I’m trying to push a change to the BioC git but it seems my account doesn’t have the correct access. > Same is shown on BiocCredentials. But thenew packageI’m submitting does not have the correct rights. > > > ssh -T git@git.bioconductor.org | grep "spicyWorkflow" > R packages/spicyWorkflow > > I also double-checked and package description file contains the correct email in the maintainer role. - Attachment: #2967 spicyWorkflow > Update the following URL to point to the GitHub repository of
> the package you wish to submit to Bioconductor > > • Repository: https://github.com/SydneyBioX/spicyWorkflow > > Confirm the following by editing each check box to ‘[x]’ > > I understand that by submitting my package to Bioconductor,
> the package source and all review commentary are visible to the
> general public. > I have read the Bioconductor Package Submission
> instructions. My package is consistent with the Bioconductor
> Package Guidelines. > I understand Bioconductor <https://bioconductor.org/developers/package-submission/#naming|Package Naming Policy> and acknowledge
> Bioconductor may retain use of package name. > 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. > My package addresses statistical or bioinformatic issues related
> to the analysis and comprehension of high throughput genomic data. > 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. > 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: > > ☑︎ The ‘devel’ branch for new packages and features. > ☑︎ The stable ‘release’ branch, made available every six
> months, for bug fixes. > ☑︎ Bioconductor version control using Git
> (optionally via GitHub). > > 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.

Lori Shepherd (07:23:03): > sorry for the inconvenience. The issue should now be resolved

2023-04-14

Matteo Tiberti (02:18:05): > hi everyone, just a quick question - we submitted our Moonlight2R package as a contribution before the deadline for contributing for BioC 3.17. The package built OK on all builders early last week, wehaven’treceived a review so far and the deadline for acceptance draws near. I assume that if we don’t manage to receive a review and satisfy the reviewer by Monday the package just won’t be included in 3.17? Thank you!

Lori Shepherd (06:28:24): > I’ll follow up with your reviewers today. > The deadline to be added to the 3.17 manifest is Wednesday. After that date if accepted it would be released in 3.18 but still have Bioconductor links/landing page/and be able to be installed through Bioconductor

Matteo Tiberti (06:33:47): > Thank you@Lori Shepherd!

Jayaram Kancherla (10:55:23): > @Jayaram Kancherla has left the channel

2023-04-18

Jermiah Joseph (16:41:38): > @Jermiah Joseph has joined the channel

2023-04-19

Wes W (14:47:03): > Hey All, I am going to be doing a livestream tomorrow where I try and convert a cran package to a Bioconductor package in a day. I am putting together some links for people in the comments of the video as resources and would love to hear your thoughts on tutorials or links you found helpful in making your bioconductor packages. > > Currently I have the main information page:https://bioconductor.org/developers/how-to/buildingPackagesForBioc/and@Lori Shepherd’s workshop from BioC 2017 which has some nice best practices for general package development which I have over the last little while actually use for my students in house cause a lot of the best practices are just good advice for a making any package:https://www.bioconductor.org/help/course-materials/2017/BioC2017/DDay/Workshop/MakeAPackage.html

Lori Shepherd (14:56:14): > I’m honestly not sure when that buildingPackagesForBioc was updated. > Mentioning thecontributions.Bioconductor.orgwould be good. > Leo’s biocthis package and Kayla’s hubpub for packages with large data also good…

Wes W (16:01:50) (in thread): > awesome possum. thanks!

2023-04-21

Mikhael Manurung (08:42:44): > @Mikhael Manurung has joined the channel

2023-04-23

Michael Milton (21:13:55): > @Michael Milton has joined the channel

2023-04-25

Nick R. (19:39:11): > Got something weird happening withspicyWorkflow. The build status is unknown but the page is up. I think it might have something to do with the build time. I pushed an update increasing the number of cores to 5 on Monday but it’s still on unknown. - Attachment (Bioconductor): spicyWorkflow (development version) > We have developed an analytical framework for analysing data from high dimensional in situ cytometry assays including CODEX, CycIF, IMC and High Definition Spatial Transcriptomics. This framework makes use of functionality from our Bioconductor packages spicyR, lisaClust, scFeatures, FuseSOM, simpleSeg and ClassifyR and contains most of the key steps which are needed to interrogate the comprehensive spatial information generated by these exciting new technologies including cell segmentation, feature normalisation, cell type identification, micro-environment characterisation, spatial hypothesis testing and patient classification. Ultimately, our modular analysis framework provides a cohesive and accessible entry point into spatially resolved single cell data analysis for any R-based bioinformatician. - File (PNG): image.png

Peter Hickey (19:41:48) (in thread): > Side note: BioC asks that “a minimal number of cores (1 or 2) should be set as a default.” (https://contributions.bioconductor.org/r-code.html#parallel-recommendations) - Attachment (contributions.bioconductor.org): Chapter 15 R code | Bioconductor Packages: Development, Maintenance, and Peer Review > Everyone has their own coding style and formats. There are however some best practice guidelines that Bioconductor reviewers will look for. can be a robust, fast and efficient programming language…

Lori Shepherd (19:57:55) (in thread): > Yes please reduce to 1-2 instead of 5. Also the badges and like update after the builds but they might be a little off this week with the release

Nick R. (19:58:55) (in thread): > Ok, just to clarify, it was on one when the issue started occurring.

Nick R. (19:59:22) (in thread): > It’s not just the badge, the build report seems to be totally missing

Lori Shepherd (20:04:15) (in thread): > I can investigate more tomorrow morning

Nick R. (20:04:26) (in thread): > Thank you!

2023-04-26

Vince Carey (06:44:08) (in thread): > Thishttp://bioconductor.org/checkResults/devel/workflows-LATEST/spicyWorkflow/shows status “ok”. The badges on the landing page will be updated eventually. Bioconductor 3.17 is becoming the “release” version today, and a new “devel” branch is being established.

2023-05-06

Sarah Parker (14:03:38): > @Sarah Parker has joined the channel

2023-05-11

Krithika Bhuvanesh (16:29:45): > @Krithika Bhuvanesh has left the channel

2023-05-18

Oluwafemi Oyedele (05:53:51): > @Oluwafemi Oyedele has joined the channel

2023-05-19

Yuka Takemon (14:32:05): > @Yuka Takemon has joined the channel

2023-05-20

Franck RICHARD (06:14:56): > @Franck RICHARD has joined the channel

2023-05-31

Alyssa Obermayer (14:15:45): > @Alyssa Obermayer has joined the channel

2023-06-01

Louis Le Nézet (03:39:56): > @Louis Le Nézet has joined the channel

Louis Le Nézet (09:05:38): > Hi, > I’m part of a group where we develop shiny modules that we would like to share as a bioconductor package. > The structure for shiny app in bioconductor seems a bit tricky, but as we are working on smaller entity wouldn’t it be better for each module to be inside one file ?

2023-06-03

Vince Carey (18:02:35): > Hi@Louis Le Nézet– glad to have you aboard! Can you provide some more background on what is tricky? What can you show about what you have already developed, that can help us understand the module/file relationships you mention? Thanks

2023-06-06

Louis Le Nézet (04:16:00): > Hi ! > > I found the separation of observers, interface, outputs, utils in different files maybe a bit complicated for Shiny modules. > The aim of shiny modules is already to separate shiny apps in sub process with independent namespace. > Has anyone already published a bioconductor package with R shiny modules that we could use as example ? > > Thanks

Kevin Rue-Albrecht (17:23:20) (in thread): > I maintain a series of packages that create and extend a shiny app. See all the packages that start with “iSEE”. Unfortunately for your use case, wedon’tuse shiny modules.

Kevin Rue-Albrecht (17:25:22) (in thread): > Not for self-advertising, but if anything, some possible inspiration for how we manage shiny apps in Bioconductor packages

Vince Carey (22:01:31) (in thread): > Here’s one way to find Bioc packages that use moduleServer …https://code.bioconductor.org/search/search?q=moduleServer… there are quite a few. I never heard of it before today! It would be nice to see your examples to get a sense of the objective and value of the modules approach. - Attachment (code.bioconductor.org): Bioconductor Code: Search > Search source code across all Bioconductor packages

2023-06-07

rohitsatyam102 (01:59:01): > Hi everyone. I am planning to develop an R package and I have some python scripts and some tools that need to be compiled when building the package so that their correct path can be used when running them within functions. I wish to know where such custom python scripts should be kept and how can I use it (I know about reticulate but it creates conda environment and terminates if there is space in the path which will lead to the package build failing on windows so I am not sure whether to use it). Also, where the compiled tools will be kept and how to tell R to compile them when the package is being installed or build.

Davide Risso (04:59:57) (in thread): > Have you look at basilisk (https://www.bioconductor.org/packages/release/bioc/html/basilisk.html)? - Attachment (Bioconductor): basilisk > Installs a self-contained conda instance that is managed by the R/Bioconductor installation machinery. This aims to provide a consistent Python environment that can be used reliably by Bioconductor packages. Functions are also provided to enable smooth interoperability of multiple Python environments in a single R session.

Louis Le Nézet (05:06:53) (in thread): > Thanks@Kevin Rue-AlbrechtI will take a look at it.

Louis Le Nézet (05:10:49) (in thread): > @Vince Careythey is effectively plenty of package using module_server. > The problem is that most of them either use them to create an app inextdataor only export the big app generated using those modules. > You should be able to see our project here:https://github.com/stjude-biohackathon/KIDS23-Team13There is plenty of work to do, but we are improving little by little.

Laurent Gatto (06:31:13) (in thread): > I second Davide’s suggestion. I recently used basilisk and it is great. You can ship your python source code in your R package or, better IMHO, publish it as a python package and then let basilisk install your python package and its dependencies. It was a great incentive for me to learn how to write/publish a python package (which, compared to R packages, is a real mess:wink:).

rohitsatyam102 (07:30:09) (in thread): > Never heard of basilisk before..thanks will look into it. Besides, what about compiling a tool from source code? Say I have source code for a tool that I obtained from github (samtools for instance though I know rsamtools exists) and I need to build it and I wish to use the executable usingsystemfunction. Where do I give instructions for it’s compilation when the package is being installed for the first time.

Laurent Gatto (07:52:35) (in thread): > I would say that the first thing would be to identify the system dependencies, possibly even that tool if it is reasonably widely used, and report these in DESCRIPTION file. You need to make sure that any possible user will be able to install your package and get it to compile/install that tool automatically, which might not be straightforward on all OSes.

Laurent Gatto (07:54:27) (in thread): > MSGFplusused a java executable and simply downloaded it first time the package was used, and the only dependency was java, without need for local compilation. - Attachment (Bioconductor): MSGFplus > This package contains function to perform peptide identification using the MS-GF+ algorithm. The package contains functionality for building up a parameter set both in code and through a simple GUI, as well as running the algorithm in batches, potentially asynchronously.

Laurent Gatto (07:55:23) (in thread): > I can’t think of any example that does something similar with code that needs to be compiled locally, which suggest/confirms that isn’t the recommended way.

Vince Carey (08:10:40) (in thread): > Yes, I’ve looked at your package now. There’s a relationship to the interactiveDisplay package, which is fairly old and did not get much uptake.https://www.bioconductor.org/packages/release/bioc/html/interactiveDisplay.html, the vignette is nice and seems to have been ahead of its time. > I think your agenda looks good and I am not sure we have guidance on how to do this at this time. It would be interesting to see a client package > that uses the KIDS23 modules to build an integrative app. Then the guideline formulation for shiny modules would be directed at a) ensuring that > client package authors are well-informed on how the modules are used and how they add to the efficiency of app composition and b) ensuring that > module maintenance and testing procedures are clear and comprehensive. Is that sufficient to go forward? I think there is certainly a lot of reinvention of common > tasks in the apps that are being produced now, and a module library should be very useful. To give you a sense of a recently developed app from > my work,https://vjcitn.shinyapps.io/gwasCatSearch/is written from scratch. Its long term development would surely be aided by modules for > stacked manhattan plots of identified GWAS, interactive/customizable network visualization … probably would be a good idea to form a working > group of your developers and potential users, maybe a dedicated slack channel too. - Attachment (Bioconductor): interactiveDisplay > The interactiveDisplay package contains the methods needed to generate interactive Shiny based display methods for Bioconductor objects.

Kasper D. Hansen (08:57:47) (in thread): > What you’re (@rohitsatyam102) is suggesting sounds simple, but is in reality somewhere between difficult and impossible

Kasper D. Hansen (08:59:28) (in thread): > This is because you know (as a developer) take responsibility for getting the code compiled on ANY PLATFORM. This is “easy” (read: “only difficult”) for code which is extremely portable with a great configure script but can become next to impossible if the dependency is not very portable (and many bioinformatics tools are not written by people who are great at portability, which is a very hard task).

Kasper D. Hansen (09:00:37) (in thread): > But the way you compile your code (your original question) is by writing aconfigure/configure.winscript. This script needs to detect the user’s system tools and set all paths and compiler flags in the correct way.

Kasper D. Hansen (09:02:15) (in thread): > Writing a configure script is actually pretty hard because it needs to be super portable, which is extremely hard to achieve. For this reason, the best way (in my opinion) is to use the autoconf tool chain, where you write a meta-script (configure.acor - older convention -configure.in) which then gets “compiled” intoconfigure.

Kasper D. Hansen (09:02:39) (in thread): > An example of this isRgraphvizalthough this compiles a library and not an executable

rohitsatyam102 (09:09:32) (in thread): > This is indeed overwhelming. I will try looking at Rgraphviz package for sure to get some idea.

Kasper D. Hansen (09:11:11) (in thread): > An easier way is to say “it is up to the user to install the dependency”. Then you write a scripty which checks if the dependency is indeed installed and fucntioning and then you’re done

Kasper D. Hansen (09:11:31) (in thread): > The major drawback is that this makes it much harder for the user.

Kasper D. Hansen (09:12:15) (in thread): > Philosophically, I would say that R packages generally does a lot of work for the user which is why they are widely used, whereas other languages / repositories makes the user work a tot, which is why they can be so hard to use

Kasper D. Hansen (09:12:29) (in thread): > So you’re trading off developer time for user time.

Kasper D. Hansen (09:12:54) (in thread): > with the idea that (with many users) 10 hours of developer time translates into 1000s of hours of user time saved

Kasper D. Hansen (09:13:38) (in thread): > But the crux of the matter is that saying “I have a good pipeline with all the tools installed, and then I can do this great script” is really, really hard to deploy on other people’s systems

Louis Le Nézet (09:14:12) (in thread): > That would be really nice indeed. > We already have a slack channel where we currently discuss on. > As it is a package effectively aimed for reuse by other, a lot of documentation would indeed be needed. > We are open to contribution and as no one of us has already published in bioconductor, we would be really greatfull for help from an experienced contributor.

rohitsatyam102 (09:14:51) (in thread): > Yeah the whole point of developing the package is to make User’s life easier. I had difficulty usingDECIPHERpackage on windows that usesOligoArrayAuxan external dependency so I was never able to use it.

Vince Carey (09:20:27) (in thread): > For now do you want to invite me stvjc to your slack channel? Do you have an example independent client package? Once it gets rolling maybe we should have a slack channel in community-bioc

Louis Le Nézet (09:26:22) (in thread): > I’ve asked my collegues how we would like to proceed. > Most of them are in the USA so we might need a bit of time before they answer. > > We don’t have for the moment a client package as we just started a few month ago writing everything. > > I also think that a dedicated channel on community-bioc would be nice:slightly_smiling_face:

Kasper D. Hansen (10:52:21) (in thread): > Sure. I am a big proponent of making life easy and I think that is a key contribution of Bioc. I am just saying in practice it is super hard and that is why you see so many external dependencies - because it is just too hard to bundle them.

Hervé Pagès (12:22:35) (in thread): > I agree with Kasper that having your package automatically download/install/compile external software can be extremely difficult to get right. The general consensus is that it’s not your package business to take care of that. The standard approach is to list these external tools inSystemRequirementsand to quickly explain the process of getting that software installed on the user machine in anINSTALLfile placed in the top-level directory of the package. It’s also highly recommended to have the code in your package detect the presence of the external tools on the user machine as early as possible (e.g. at load-time) and fail with an informative error message if the tools are missing.

Kayla Jackson (13:52:56): > @Kayla Jackson has joined the channel

Alyssa Obermayer (18:30:11): > @Alyssa Obermayer has joined the channel

2023-06-15

Leo Lahti (05:59:12): > I was looking into Bioconductor online books:https://bioconductor.org/books/release/Two questions: > 1) are there instructions on how to contribute a book (I did not find from the site) > 2) does the current setup support Quarto books?

Laurent Gatto (07:18:39) (in thread): > These are very good questions I would be interested in too. Especially for the 1st one - OSCA is very involved, and comes with functionality (and complexity) that isn’t always needed. It would be useful if interested parties could get together to discuss the requirements for Bioc books. Do we need a book working group? > (cc@Vince Carey- we touched upon this earlier this week)

Vince Carey (07:25:52): > @Leo Lahti@Laurent GattoI would like to put some guidelines together on the book topic. I know about the mass spec book, but would you both provide links to your repos of book material and we will see what kinds of support we can provide. Build cadence, validity checking, maintenance, distribution, are all topics that may need technical attention. If by chance you are using github actions to manage book production, considerhttps://github.com/marketplace/actions/workflow-telemetryto develop information on production resources used.

Laurent Gatto (07:31:44): > R for Mass Spectrometry book > * Repo:https://github.com/rformassspectrometry/docs > * Build locally, pushed to github, rendered as a github pagehttps://rformassspectrometry.github.io/docs/ > * Uses Mike’ msmb style > * Mostly based on release, except when there’s a new important feature I need to teaching. In such a case, I update the installation instructions to point to the package repo on github. > * No validity checks as part of the book. > * Installation of packages and data:https://gist.github.com/lgatto/b1875458ed4e478ff6e87ce3b346352e > * This book has been around for a couple of years, but it is still work in development. - Attachment (rformassspectrometry.github.io): Chapter 1 Preamble | R for Mass Spectrometry > Chapter 1 Preamble | R for Mass Spectrometry

Jacques SERIZAY (12:05:11): > I’ll chime in, since I also have written a book, focusing on Hi-C analysis in R. How the book is developed: > * Book website:js2264.github.io/OHCA/ > * Repo:https://github.com/js2264/OHCA/ > * Quarto-based book > * Served by GitHub Pages (rendered ingh-pagesbranch) > * Shipped as an R package, with DESCRIPTION used to manage dependencies > * Dockerfile + Makefile + GHA to handle dependencies & automate rendering and upload togh-pages > * Automated rendering @ every push / daily (cron) > * Checking is not strictly ensured, but daily rendering status can be used to monitor that it went ok/not ok, including dependencies (listed in DESCRIPTION) > * Automateddockerimage release @ each rendering (push/daily):https://github.com/js2264/OHCA/pkgs/container/ohca > This book has been up and running for ~ 4 months now. > > Following up on@Leo Lahtiquestion: is there any way this type of books can be advertised by Bioconductor? I find my setup works remarkably well, but I’d love to see the book listed inBioconductor’s Bookspage.

Jacques SERIZAY (12:07:39): > @Vince CareyI’ll try and includetelemetryin my workflow

Vince Carey (12:08:52): > @Jacques SERIZAYwe will get back to you on linking info to the web page. thanks!

Hervé Pagès (12:30:11): > @Jacques SERIZAYLooks like the link you provided is for the devel version of the book (BioC 3.18). Do you have a release version? I could add the link tohttps://bioconductor.org/books/release/

2023-06-19

Vince Carey (13:16:31) (in thread): > The#shinychannel does not get much traffic, so let’s put the discussion of shiny modules there, OK?@Louis Le Nézet

2023-06-20

Louis Le Nézet (04:12:56) (in thread): > Okay I will do so !

2023-06-29

Leo Lahti (03:42:42) (in thread): > Perhaps something for TAB / CAB meeting?

Laurent Gatto (03:54:43) (in thread): > This has been a recurring topic, but I don’t think there have been any concrete outcomes yet.

Leo Lahti (05:00:26) (in thread): > Right, that’s true. I am wondering who might know answers to the above questions..?

Leo Lahti (05:00:42) (in thread): > i.e. how to contribute a new book, and whether Quarto is supported.

Vince Carey (17:28:37) (in thread): > We are discussing in the core and will try to have some guidance next week.

2023-06-30

Leo Lahti (06:53:48) (in thread): > ah, great. Thanks a lot Vince.

2023-07-01

Ludwig Geistlinger (13:08:19): > @Ludwig Geistlinger has joined the channel

2023-07-28

Konstantinos Daniilidis (13:47:51): > @Konstantinos Daniilidis has joined the channel

2023-08-03

Ritika Giri (15:58:49): > @Ritika Giri has joined the channel

2023-08-07

Jiaji George Chen (11:22:02): > @Jiaji George Chen has joined the channel

2023-08-24

Lachlan Baer (01:21:29): > @Lachlan Baer has joined the channel

2023-09-18

Louis Le Nézet (03:45:50): > Hi ! > > I’m nearly ready to submit my pedigree package (https://github.com/LouisLeNezet/kinship2/tree/dev_newclass). > I would like to know where to submit it (CRAN or Bioconductor). > This package is an upgraded version of a previous CRAN package and the previous maintainer is passing the maintenance to me. > Bioconductor community helped me a lot in the process and I was thinking on submitting it for the next release. > The package as greatly change in architecture, so I was thinking of changing the version (1.9 -> 2.0), maybe a name change ? > > What would be the best course of action ? > Thanks

Pedro Sanchez (03:56:37): > Hi Louis! I had a similar situation, since I wanted to improve my package released at CRAN. It was not super easy to move it to BioC (because of not having two packages existing with the same name at both repositories). My particular recommendation is that if you feel the package’s architecture has changed enough, submit it as a new one in Bioconductor as yourPackageName2

Louis Le Nézet (04:50:54) (in thread): > So the easiest would be to update the package on CRAN to tell the new one is on bioconductor and submit on bioconductor with a new name ?

Lluís Revilla (04:53:18) (in thread): > I wouldn’t update the package on CRAN. You can leave it as is or request to archive itandtell them that the next update is as PackageName2 in Bioconductor (Make sure that first it is accepted in Bioconductor:slightly_smiling_face:

Louis Le Nézet (09:20:15) (in thread): > CRAN people told me it would be best to keep the name and submit it with a new version number. > I will go for that I think:slightly_smiling_face:

2023-09-19

Louis Le Nézet (06:18:50): > Hi, > I’ve open the a issue for the package andbioc-issue-botis telling me that my version number ‘2.1.0’ is not formatted correctly. > As it it a first release on Bioconductor, it should be ‘0.99.0’, but this package was previously on CRAN and I was thinking on keeping the name so that the person using the old package could follow to this new version while keeping the history. > Is it possible to keep the version number ?

Lluís Revilla (06:46:14) (in thread): > Yes you will be able to keep that version number (or one higher). This is the default reply to any submission. I don’t think the bot is ready to recognize a package that is moving from CRAN to Bioconductor.

Spencer Nystrom (06:53:43) (in thread): > If you’re migrating to bioc from cran, that is (potentially) a bit of a breaking change for a lot of workflows. It would probably be a good idea to either release apkgName2on bioc or at least provide some advance warning to users about the deprecation (with release in Oct, that’s not a very long notice period…). For example, they’d no longer be able to install.packages() and installing bioc packages outside of the supported R version is not very straightforward.

Lori Shepherd (07:08:22) (in thread): > You should use 2.99.0 so that the first Bioconductor release would be 3.0.0 then

Lori Shepherd (07:08:46) (in thread): > it is designed to recognize a CRAN submission or previous submission but expects x.99.z

Lori Shepherd (07:11:35) (in thread): > You will likely get an ERROR saying the package is already in CRAN when running check or BIocCheck – you can explain in a separate comment that it is moving – and make sure that once it is released in Bioconductor that it comes off of CRAN by contacting them

Hervé Pagès (13:26:33) (in thread): > pedigree2is almost certainly the easiest way to go as it will make the transition much much smoother

2023-09-22

Francesc Català-Moll (04:02:31): > Hello everyone! > > I am in the process of submitting an R package to Bioconductor and I came across a warning that I would like to discuss. When running R CMD CHECK on Linux, I receive the following warning: WARNING: R CMD check exceeded 10 min requirement. I only encounter this error during the check on Linux but not on macOS. > > I would like to know if this maximum 10-minute requirement is strictly mandatory before reducing the number of tests and examples of the code? I would also like to ask if anyone knows of a way to obtain the exact time it takes for R CMD CHECK to run because I have information that it takes more than 10 minutes but not the exact value. > > I appreciate any guidance or advice you can provide. Thank you in advance!

Matteo Tiberti (04:21:05) (in thread): > hi, not a BioC team member and just another developer, but maybe I can give you some ideas since I recently went through the same: > * yes - to my best understanding, you should solve that WARNING - but bear in mind that BioC runners might have different performance (and so different build times) than your local machine, so I wouldn’t stress too much if you’re close to the 10 minutes. Your package will be built on BioC runners, that will give you your “official” timing > * if your tests take a long time you can use the long test set up for them (see BioC docs) and so keep them. I would prioritise this over reducing the number of tests (which are very useful) > * it might be useful to runR CMD checkwith option--timingsthat give you the running time for each part of the check. In our case for instance running examples took longer than running tests so we had to work on those instead

Mike Smith (04:32:51) (in thread): > You haven’t mentioned a package name, but if my quick look at the Contributions page is correct, I think you’ve already submitted your package. > > If that’s correct you can view the complete build report athttps://bioconductor.org/spb_reports/dar_buildreport_20230922033742.htmlit’s also linked from the GitHub issue. > > The timing for the check on Linux is reported at 10mins 7seconds, so you’re pretty close to the required timing. That report also include the--timingsinformation mentioned above, so you can maybe see what to prioritise to reduce that test time. > > Edit: actually some of those example runtimes look pretty weird, where the elapsed time is significantly longer than the user+system time. Not sure what’s happening there, but it might be worth investigating.

Francesc Català-Moll (05:28:34) (in thread): > Thank you very much@Mike Smith! Since it’s only 7 seconds, I’ll try to remove or reduce some tests. Regarding the final comment about execution times, could it be related to some tests running in parallel or to the utilization of metaprogramming?

Alan O’C (05:43:11) (in thread): > I think when elapsed > user+system, it’s a sign that something else is using CPU time as your tests run

Francesc Català-Moll (06:49:20) (in thread): > Confirmed, the execution times are due to some tests running functions with parallel = TRUE. Setting the parallel parameter to FALSE returns normal runtimes.

Hervé Pagès (13:44:42) (in thread): > @Louis Le NézetNote that keeping the name means that there’s a strong expectation that the package does not break existing code that relies on it. Preserving backward compatibility requires being very cautious and implementing a 2 x 6-month transition plan that involves a lot of.Deprecated()calls for the 1st 6-month period followed by a lot of.Defunct()calls for the 2nd 6-month period, finally followed by the removal of all the obsolete stuff. This is a lot more work than just using a new name for the BioC package and deprecating the CRAN package.

2023-09-24

Jared Andrews (14:50:25): > How crazy do I need to get trying to address BiocCheck formatting notes?

Jared Andrews (14:51:17): > I’m trying my best, but the package is largely a Shiny app, so getting some elements in the line width guidelines is proving a real challenge.

Spencer Nystrom (16:39:50) (in thread): > Can you not run something likestylerto auto format the code?

Jared Andrews (16:42:31) (in thread): > I can and have, which actually made it worse.

Jared Andrews (16:43:15) (in thread): > Shiny UI elements can end up deeply nested, and there’s not always a sensible way around it.

Peter Hickey (17:28:32): > As a reviewer, I don’t much care about cosmetic things like 2-space vs 4-space indentation. The line width guideline and function length is something I prefer for my own code, but I’m not the one who’ll frequently have to re-read the code of the package I’m reviewing, so I leave it to the author’s preference. If the package I’m reviewing doesn’t stick to one general style then it gets a bit tedious and I might (strongly) suggest making it consistent. And I’m less likely to be able to help with package code I find harder to read because it takes more time and effort.

Martin Morgan (17:45:43) (in thread): > I guess the package ishttps://github.com/j-andrews7/CRISPRball. The code looks basically well-formatted and easy to parse, except for the deep nesting. > > These lineshttps://github.com/j-andrews7/CRISPRball/blob/28e4bb99002a0c475ca0ec98c5f664aaf9f4b079/R/UI_QC.R#L49-L57might be put into a functiontipifyCheckbox()that takes the variable text but encapsulates the styling; this would ensure consistency and simplify the nesting a little, across a lot of the interface. Perhaps there are other encapsulations, (e.g.,crisprballCheckbox()) that are simple wrappers (e.g., aroundprettyCheckbox()) but with consistent styling) that help? > > Extending this idea a little, perhaps something likehttps://github.com/j-andrews7/CRISPRball/blob/28e4bb99002a0c475ca0ec98c5f664aaf9f4b079/R/UI_sgrna.R#L27-L64could be encapsulated insgrnaSidebarPanel(), reducing nesting and increasing modularity (though without the prospect for re-use). > > Maybe these suggestions aren’t really in line with shiny practice, in which case they should be ignored:wink:

Jared Andrews (17:52:51) (in thread): > This is indeed the package - I appreciate you taking a look.

Jared Andrews (17:57:45) (in thread): > I consider this an opportunity to develop more comprehensive Bioconductor-specific Shiny guidelines for package development, as the existing guidance is relatively vague. I have largely followed@Kevin Rue-Albrecht’s advice and tried to style things after@Federico Marini’s excellent packages (along with iSEE). > > Perhaps one (or both?) of them would be willing to review my package to nail down additional guidelines?

Jared Andrews (18:01:44) (in thread): > The tipify encapsulation is an interesting idea that is likely worth thinking about, thanks for the suggestion. I still have numerous features I’d like to add, but I’m keen to get this into Bioconductor given its relative maturity and the positive feedback I’ve received internally about it.

2023-09-25

Kevin Rue-Albrecht (03:40:13) (in thread): > I’mreally tight on time the next few weeks with my fingers in many small pies , but also quite curious. I must admit that Ihaven’tlooked at the shiny guidelines from Bioconductor recently, asI’mlargely on autopilot. It would do me some good to kill two birds with one stone (any less graphic expression out there?) helping you while updating myself.

Kevin Rue-Albrecht (03:42:56) (in thread): > On a separatenote I’vealso started a new iSEE book that takes it « all » from the top, from a description of the UI from the perspective of an end user to key information for developers of iSEE extensions

Jared Andrews (03:43:40) (in thread): > I think you added the existing guidelines when I asked if Bioconductor had any for Shiny packages quite a while ago. They were helpful. I think the main thing lacking is guidelines for reviewers.

Kevin Rue-Albrecht (03:44:09) (in thread): > I’monly half way (optimistically) through chapter two, sodon’thold your breath for expert advice on shiny:sweat_smile:

Jared Andrews (03:44:32) (in thread): > I’d be quite interested in the iSEE book. I’ve contemplated extensions, but the codebase seemed complicated enough that I never took the dive.

Jared Andrews (03:45:28) (in thread): > tbf, I learned a ton just making this app. Federico’s apps and iSEE were super helpful references.

Jared Andrews (03:46:49) (in thread): > I am sure whoever reviews will be great, and I am sure I’ve made some mistakes or oversights, as this is my first contribution as maintainer.

Kevin Rue-Albrecht (03:48:08) (in thread): > ISEE has been largely rushing forward to break new ground but I’m hoping to find funding (and thus, time) to consolidate and clean up after ourselves. I’ve got a shopping list of quality-of-life updates that would make the life of developers (myself included) easier. I need to properly write it down.

Kevin Rue-Albrecht (03:50:39) (in thread): > We’ve had several wannabe contributors who got caught in the reefs of iSEE panel classes and methods. I always put things in place by iterations…looking at errors in the console and the live app to remind myself of the next bits to put in place:sweat_smile:

Jared Andrews (03:53:09) (in thread): > I rather regret not making some custom classes and methods for this app, but I couldn’t really think of ways to do so that would make the code more clear or even easier to maintain (though that is likely due to my inexperience with implementing such things in R).

Kevin Rue-Albrecht (03:53:10) (in thread): > I also hard code so many things initially, basically making non-interactive dummy panels that I progressively tweak to swap in the input of interactive UI elements . Impossible (rephrase: insanely long and potentially confusing) to illustrate in written documentation , and I’m afraid boring to watch in a 2+ hour YouTube video tutorial I imagine:stuck_out_tongue_winking_eye:

Jared Andrews (03:55:03) (in thread): > We had a hackathon project aimed at making modules for various generic plots/inputs that I thought had good legs. May aim to get a proof of principle for it in to Bioconductor next cycle.

Kevin Rue-Albrecht (03:55:28) (in thread): > It basically know-how more than best practices that I would have to teach, andI’mafraid some of it is largely specific to how we arranged iSEE internals

Kevin Rue-Albrecht (03:57:16) (in thread): > I’malso keeping an eye on tidyomics as it may eventually moot some of the data wrangling happening in iSEE to turn SummarizedExperiment components into ggplot2-friendly data

Jared Andrews (03:58:50) (in thread): > I haven’t taken much of a look at it, but good to keep in mind. I suck at (d)plyr manipulations at the best of times, would probably be a good opportunity to reacquaint myself with the basics.

Kevin Rue-Albrecht (04:00:40) (in thread): > At the moment, the familiar stability of doing things ourselves remains reassuring.

Kevin Rue-Albrecht (04:08:33) (in thread): > Coming back to “shiny elements deeply nested” I think we indirectly addressed that by refactoring a lot of internal code in a lot of functions. Makes the logic of the code a bit harder to track across a functions, but each function then reads a bit more easily as shorter and less indented

Jared Andrews (04:13:59) (in thread): > I think it’s mostly the UI functions that are my most egregious offenses. I broke each tab into a function, but I guess I could break them up further.

Kevin Rue-Albrecht (04:17:55) (in thread): > Yeah.. we definitely took that to new extremes:joy:

Louis Le Nézet (06:19:51) (in thread): > Ah, I understand. > I tried to maintain the compatibility but changing the name may be easier to do. > To do so I just need to change the package name and reopen an issue ?

Kevin Rue-Albrecht (07:29:25) (in thread): > i’ll share the link to the new book in this obscure corner as I don’t mind sharing it but I also don’t want to encourage requests from the wider public just yethttps://isee.github.io/iSEETheBook/intro.html

Hervé Pagès (13:57:57) (in thread): > I think so. Please post a message in the current issue to explain the situation. Thanks

Peter Hickey (17:46:21): > > I’m also keeping an eye on tidyomics as it may eventually moot some of the data wrangling happening in iSEE to turn SummarizedExperiment components into ggplot2-friendly data > @Kevin Rue-Albrechthave you seenscater::ggcells()/scater::ggfeatures()andscuttle::makePerCellDF()/scuttle::makePerFeatureDF(). They do most of what I’ve ever needed for going from aSCEto ggplot2-friendly data

2023-09-26

Kevin Rue-Albrecht (04:41:10) (in thread): > I’ve been in my bubble recently and didn’t see those yet.

Kevin Rue-Albrecht (08:06:40) (in thread): > Aside from not being at the top of my priority list (“if it ain’t broke…”), I guess there’s an argument for the iSEE tracking script to keep using the “basic” functions as a sort of tutorial for users who may be new to SummarizedExperiment. > That being said, we might consider an option in iSEE that lets users switch between the current behaviour and one that uses scater/scuttle “wrapper functions”

Kevin Rue-Albrecht (08:09:25) (in thread): > It may also be more complicated than it sounds, as iSEE renames columns in the outputdata.tableto its own standard column names to makes things easier at the time of mapping ggplot2 aesthetics

2023-10-02

Matteo Tiberti (04:59:02): > hi, just a quick question - our Moonlight2R package has been accepted in BioC on the 24th of September (which is great news!), I just wanted to ask for confirmation that we don’t need to do anything else at present time except wait for it to appear in thedevelbuilds for future release in 3.18. Thanks!

Lori Shepherd (07:05:10): > Yes I process packages normally once (sometimes twice a week). I will be processing later today and it should appear in the daily builds by mid week

Matteo Tiberti (08:52:15) (in thread): > amazing, thank you!

2023-10-03

Louis Le Nézet (11:12:18): > Hi, > I’ve changed my package name from “kinship2” to “Pedigree” but I’ve just saw that the “Pedigree” package name is already taken on CRAN. > I’m a bit lost to find another name, I was thinking to change to : “PedigreeKin”, “PedigreeInsights”, “PedigreeToolbox”. > What do you think ? > Will it still be possible to submit for this october build as I will need to create another issue ? > Thanks a lot !

Lori Shepherd (11:27:48): > Since it was already submitted before the deadline we can still start the review process to try and have it submitted once you decide on a name

kent riemondy (12:39:26): > @kent riemondy has joined the channel

2023-10-04

Amanda Hiser (09:44:26): > @Amanda Hiser has joined the channel

Louis Le Nézet (10:50:53) (in thread): > Hi, > I’ve changed the name to “Pedixplorer” as we will have a Shiny app at the end. > The PR ishttps://github.com/Bioconductor/Contributions/issues/3203Thanks again !

2023-10-27

vedha (05:06:47): > Hello BioC team, > We were hoping for the current BioC release to contain our packageshiny.goslingbut it looks like it will only be included in the next release. We understand that reviewing the packages takes time and we appreciate the reviewers for reviewing our package. > Despite submitting the package before the deadline we were unable to make it. In retrospect we wanted to understand was there something we could have done to make sure that our package would have been released in this version of BioC? It would help us make sure we do them in the future. Thank you. - Attachment: #2907 shiny.gosling > Update the following URL to point to the GitHub repository of
> the package you wish to submit to Bioconductor > > • Repository: https://github.com/Appsilon/shiny.gosling > > Confirm the following by editing each check box to ‘[x]’ > > I understand that by submitting my package to Bioconductor,
> the package source and all review commentary are visible to the
> general public. > I have read the Bioconductor Package Submission
> instructions. My package is consistent with the Bioconductor
> Package Guidelines. > I understand Bioconductor <https://bioconductor.org/developers/package-submission/#naming|Package Naming Policy> and acknowledge
> Bioconductor may retain use of package name. > 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. > My package addresses statistical or bioinformatic issues related
> to the analysis and comprehension of high throughput genomic data. > 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. > 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: > > ☑︎ The ‘devel’ branch for new packages and features. > ☑︎ The stable ‘release’ branch, made available every six
> months, for bug fixes. > ☑︎ Bioconductor version control using Git
> (optionally via GitHub). > > 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.

Lori Shepherd (07:18:16) (in thread): > It seems like there was a gap in time where the issue was closed to allow you to work on reviewer comments and adaptions to Bioconductor requirements. Making sure your package is compatible with existing Bioconductor classes and following package guidelines will help easy the process.http://contributions.bioconductor.org/goes through in detail what Bioconductor will look for and a dedicated section on important Biocondudctor specific requirements lists some things not always caught on a R CMD build or R CMD checkhttp://contributions.bioconductor.org/important-bioconductor-package-development-features.html. Making sure BiocCheck works without ERROR would be a big one too.

Lori Shepherd (07:20:03) (in thread): > Generally we have said if it is submitted before 5-6 weeks out the reviewer should have enough time to do at least one review of the package. We did however receive an extremely large number of last minute package submissions; almost double of what we normally see. We do our best to accommodate but package reviewers are volunteer and the core team has other tasks besides package reviews esp around release time so the sooner it can be submitted regardless of a release deadline the better.

vedha (07:22:29) (in thread): > Thank you Lori, this is very helpful:raised_hands:It’s also nice to hear that lot of new packages are coming to BioC:muscle:

2023-11-02

Kevin Rue-Albrecht (18:32:33) (in thread): > I’ll also quickly add that being in bioc devel rather than release for a cycle is actually a pretty nice on-ramp. Users can still install it if they wish, and other developers can start building on top of it, while youdon’thave as much pretty from the high(er) visibility of the release branch thateveryonehas naturally access to :)

2023-11-07

Jacques SERIZAY (12:58:28): > Hi BioC team, I’m trying to submitjs2264/OHCAfor submission, and this is a book (developed using BiocBook) (latest attempt here:https://github.com/Bioconductor/Contributions/issues/3231). It does not comply with some preliminary checks performed by the bioc bot (e.g. at least onebiocViewsis required, but because this is a book it does not have any appropriate views, and more annoying, the bot complains about the size of the individual files being over 5mb (namely 1 extdata of 17Mb and 1 png being 5.1 Mb). I thought the size limit would not necessarily cover books, is this incorrect ? Do I absolutely need to be < 5Mb, or is there a way around this? Thanks! - Attachment: #3231 (inactive) OHCA

Hervé Pagès (13:06:26) (in thread): > We should relax the requirement w.r.t. biocViews (until we define a vocabulary for books). Is that something you could look at@Lori Shepherd? > However books, like workflows, should not contain data or anR/folder. Any R function or data the book uses should come from existing software or data packages. In particular the data should be made available separately as a data package, typically an ExperimentHub- or AnnotationHub-based data package.

Hervé Pagès (13:10:43) (in thread): > For your big png file, is there a way you could reduce its size by slightly reducing its resolution?

Lori Shepherd (13:18:27) (in thread): > I don’t want to relax for all types as it should be strict for the others (software, workflows, etc) – In the SPB code we already look forBiocTypein the DESCRIPTION to increase the build time limit – I could relax the biocViews check based on that value. ie. addingBiocType: bookto the DESCRIPTION

Hervé Pagès (13:19:05) (in thread): > I meant for books only of course

Lori Shepherd (13:19:27) (in thread): > that would be the easiest way for me to implement the exception.

Lori Shepherd (13:45:46) (in thread): > this should be implemented nowBiocType: bookin Description will skip biocViews check

Hervé Pagès (13:48:02) (in thread): > Thanks Lori!

2023-11-09

Jacques SERIZAY (16:32:49) (in thread): > FYI@Lori Shepherdand@Hervé Pagès, I have followed your recommandations and the pre-checks from the bioc bot were ok. Thanks for your help!

Hervé Pagès (16:43:24) (in thread): > Awesome! Glad it worked.

2023-11-12

Hechen Li (11:53:46): > @Hechen Li has joined the channel

Hechen Li (12:10:21): > Hi BioC team! I’m currently attempting to submit my package scMultiSim(https://github.com/Bioconductor/Contributions/issues/3068). There were some build errors in the previous stage of my package submission, and unfortunately, due to personal situation, I couldn’t address it until recently. I fixed all build errors a week ago but haven’t received a response from the reviewer Oliver Crook. May I ask if my package’s reviewing process is still active and when I can anticipate the next steps? Thanks a lot! - Attachment: #3068 scMultiSim > Update the following URL to point to the GitHub repository of
> the package you wish to submit to Bioconductor > > • Repository: https://github.com/ZhangLabGT/scMultiSim > > Confirm the following by editing each check box to ‘[x]’ > > I understand that by submitting my package to Bioconductor,
> the package source and all review commentary are visible to the
> general public. > I have read the Bioconductor Package Submission
> instructions. My package is consistent with the Bioconductor
> Package Guidelines. > I understand Bioconductor <https://bioconductor.org/developers/package-submission/#naming|Package Naming Policy> and acknowledge
> Bioconductor may retain use of package name. > 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. > My package addresses statistical or bioinformatic issues related
> to the analysis and comprehension of high throughput genomic data. > 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. > 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: > > ☑︎ The ‘devel’ branch for new packages and features. > ☑︎ The stable ‘release’ branch, made available every six
> months, for bug fixes. > ☑︎ Bioconductor version control using Git
> (optionally via GitHub). > > 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.

Lori Shepherd (12:42:36) (in thread): > Reviewers are volunteer; please allow 2-3 weeks for review as this is generally in addition to other workloads.

Hechen Li (12:43:06) (in thread): > Got it, thanks a lot!

2023-11-29

Jacob Krol (16:29:44): > @Jacob Krol has joined the channel

2023-12-28

David Rach (09:19:09): > @David Rach has joined the channel

2024-01-10

Hechen Li (14:23:00): > Hi BioC team, sorry to bother you again. After pushing some changes, my unit tests consistently fail on the BioC build server. The strange part is that it works well locally on my Mac and Linux machines. > > Does anyone have similar experiences? Any suggestions would be greatly appreciated. I especially need tips on how to debug this problem because I can’t reproduce it locally. > > More details can be found here:https://github.com/Bioconductor/Contributions/issues/3068#issuecomment-1859220635 - Attachment: Comment on #3068 scMultiSim > The problem this time was not the timeout…… My unit test failed on BioConductor’s build server after I pushed the new changes. > > > Running the tests in tests/testthat.R failed. > Last 20 lines of output: > > `actual[3:15]`: 18 33 88 0 2 0 24 72 6 7 and 3 more... > `expected[3:15]`: 18 33 88 5 4 0 8 96 0 18 ... > Failure ('test-1_main.R:151:3'): simulates spatial data with discrete population and HGE > res$counts[selectedIndicies] (`actual`) not equal to c(...) (`expected`). > > actual | expected > [1] 116.691 - 109.069 [1] > [2] 59.994 - 60.415 [2] > [3] 85.398 - 91.912 [3] > [4] 1.082 - 0.582 [4] > [5] 172.034 - 177.674 [5] > [6] 202.649 - 197.066 [6] > [7] 95.052 - 102.315 [7] > [8] 56.943 - 65.998 [8] > [9] 96.683 - 89.161 [9] > [10] 2.693 - 3.173 [10] > ... ... ... and 7 more ... > > [ FAIL 7 | WARN 0 | SKIP 0 | PASS 5 ] > Error: Test failures > > > This is really strange since these tests successfully pass on my macOS and Linux machines. I’m still trying to figure it out; do you have any thoughts?

2024-01-11

Vince Carey (10:00:51): > can you use docker? this docker container should allow you to replicate events on the build system:ghcr.io/bioconductor/bioconductor_salt:22.04-bioc-3.19-r-development

2024-01-12

Hechen Li (10:41:46): > Thanks! That would be very helpful.

2024-01-29

Amanda Hiser (10:13:40): > Hello! Is there a release schedule for 3.19 available on the Bioc website? All I’m able to easily find is this page, but it’s for 3.18:https://www.bioconductor.org/developers/release-schedule/ - Attachment (bioconductor.org): Bioconductor - Release: Schedule > The Bioconductor project aims to develop and share open source software for precise and repeatable analysis of biological data. We foster an inclusive and collaborative community of developers and data scientists.

Lori Shepherd (10:15:06) (in thread): > We do not have a schedule yet as we have not finalized a date for the release; it will be dependent on CRAN release of 4.4. Based on past releases it will likely be mid-late April and can base the timelines around that.

Amanda Hiser (10:15:19) (in thread): > Thank you!

2024-01-31

Clemens Kohl (07:20:42): > @Clemens Kohl has joined the channel

2024-03-06

Caitlin Page (00:00:41): > @Caitlin Page has joined the channel

2024-03-12

Simon Pearce (16:34:09): > How complete does the package documentation need to be in order to begin the submission process? > I’m still working on my vignettes and function examples, but would like to get the ball rolling sooner rather than later.

Peter Hickey (16:54:51): > I understand your desire, but as a reviewer I don’t want to spend time reviewing a knowingly/intentionally incomplete package.

2024-03-22

Daniel Mullen (16:44:41): > @Daniel Mullen has joined the channel

2024-03-25

Dania Machlab (03:30:58): > @Dania Machlab has joined the channel

Helen Lindsay (06:28:02): > @Helen Lindsay has joined the channel

Kevin Stachelek (13:17:56): > @Kevin Stachelek has joined the channel

2024-03-27

Jovana Maksimovic (00:39:05): > @Jovana Maksimovic has joined the channel

Rishi (10:38:19): > @Rishi has joined the channel

2024-04-04

Alexandru Mizeranschi (09:38:00): > @Alexandru Mizeranschi has joined the channel

2024-04-12

Calandra Grima (03:12:38): > @Calandra Grima has joined the channel

2024-04-16

Arshi Arora (13:32:09): > @Arshi Arora has joined the channel

Arshi Arora (13:42:00): > Hi, I am restarting my package submission after maternity leave and need help to jog my memory for how to push togit@git.bioconductor.
> > I triedpush upstreambutI don’tremember what to put here -Enter passphrase for key ‘users/blah/.ssh/id_blah’After couple of failed attempts - I get error -git@git.bioconductor.org: Permission denied (public key) > Fatal: could not read from remote repository > Please make sure you have the correct access rights and the repository exists >I can log in to my gut bioconductor account and see the long SSH key. > Issue was reopened last week so that I can trigger build. > > Can I reset this? Or is there any default?

Lori Shepherd (13:49:08): > the passphrase for your key is something you would have generated and set yourself when creating it. We cannot help you retrieve that. If you don’t remember your passphrase, you can generate a new ssh key and add it to your BiocCredentials account and then you should have access

2024-04-18

Suhn Rhie (16:13:27): > @Suhn Rhie has joined the channel

2024-04-28

Danielle Callan (08:35:15): > @Danielle Callan has joined the channel

2024-05-03

Rishi (05:57:25): > Hi, my package is in “indepth review” for last three weeks. How long usually it takes?

Lori Shepherd (07:24:20): > what is the name of your package? we like feedback to happen within 2-3 weeks

Kasper D. Hansen (07:55:59): > Submitting right during a release preparation (which you did) is the worst time to do it, because most people are busy getting everything to work.So those 2 times each year you should expect everything to take (much) longer.

Rishi (08:23:05): > My package name is “broadSeq”https://github.com/Bioconductor/Contributions/issues/3381 - Attachment: #3381 broadSeq resubmission > Update the following URL to point to the GitHub repository of
> the package you wish to submit to Bioconductor > > • Repository: https://github.com/dasroy/broadSeq > > Confirm the following by editing each check box to ‘[x]’ > > I understand that by submitting my package to Bioconductor,
> the package source and all review commentary are visible to the
> general public. > I have read the Bioconductor Package Submission
> instructions. My package is consistent with the Bioconductor
> Package Guidelines. > I understand Bioconductor <https://bioconductor.org/developers/package-submission/#naming|Package Naming Policy> and acknowledge
> Bioconductor may retain use of package name. > 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. > My package addresses statistical or bioinformatic issues related
> to the analysis and comprehension of high throughput genomic data. > 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. > 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: > > ☑︎ The ‘devel’ branch for new packages and features. > ☑︎ The stable ‘release’ branch, made available every six
> months, for bug fixes. > ☑︎ Bioconductor version control using Git
> (optionally via GitHub). > > 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.

Helena L. Crowell (08:25:57) (in thread): > Yes, so as Kasper mentioned, this was submitted close to the last release and tagged “post deadline” - in other words, it was ignored by reviewers until after the release (or in case anyone had too much time on their hands ;)…it should be reviewed within the next couple weeks, hopefully:hand_with_index_and_middle_fingers_crossed:

2024-05-14

Kayleigh Ann (19:37:12): > @Kayleigh Ann has joined the channel

2024-05-20

Rishi (10:21:49): > Hi, is it possible to check the code of newly submitted package which is under review in the sitehttps://code.bioconductor.org/browse/? - Attachment (code.bioconductor.org): Bioconductor Code: Browse > Browse the content of Bioconductor software packages.

Lori Shepherd (10:26:44): > no.code.bioconductor.orgis only for accepted packages.

Lori Shepherd (10:33:18): > was there something in particular you were looking for or looking to do by means of the browser?

Rishi (10:34:31) (in thread): > I am not sure my github repository is same as bioconductor?

Lori Shepherd (10:36:25) (in thread): > Have you tried syncing togit.bioconductor.orgusing the instructions?

Hervé Pagès (13:57:16) (in thread): > @RishiOne way to compare the 2 repos is to clone both of them on your machine and dodiff -r --brief path/to/repo1 path/to/repo2.

2024-05-23

Lori Shepherd (14:21:06): > Due to unforeseen circumstances, our daily builders and new submission builders are currently offline. We are sorry for the inconvenience and will restore as soon as possible

2024-06-05

Adrian Hirt (05:47:00): > @Adrian Hirt has joined the channel

2024-06-20

Dima Lvovs (07:52:27): > @Dima Lvovs has joined the channel

Lucio Queiroz (08:59:03): > @Lucio Queiroz has joined the channel

2024-07-16

Ahmad Al Ajami (12:11:24): > @Ahmad Al Ajami has joined the channel

Hiru (12:19:39): > @Hiru has joined the channel

2024-07-26

Qiwen Octavia Huang (19:51:47): > @Qiwen Octavia Huang has joined the channel

2024-08-07

Hiru (05:05:37): > Hi Bioc team, > > My package, MotifPeeker, has just passed pre-check but is now encountering build errors due to a missing system dependency or environment path related to the MEME suite. > > Could you provide guidance on resolving this issue? > > Thank you.

Hiru (05:06:22): > MEME suite is an essential requirement and also required for the vignettes.

Lori Shepherd (07:08:08): > We will install the required system dependency. Once this is done I’ll kick off a manual rebuild. Thanks!@Andres Wokaty

Hiru (09:42:47): > Thank you!

Andres Wokaty (11:30:57): > @Hiru, Can you write anINSTALL filefor MEME suite for MotifPeeker? I will also comment this on the issue as I like to make a paper trail. - Attachment (contributions.bioconductor.org): Chapter 11 The INSTALL file | Bioconductor Packages: Development, Maintenance, and Peer Review > An INSTALL file does not have to be included with the package. An INSTALL file is utilized for specifying external system requirements needed. It should be used in combination with the…

Hiru (11:36:55) (in thread): > Sure. Is there any particular format to follow for the INSTALL file, or should I just include the shell commands?

Andres Wokaty (11:44:19) (in thread): > Shell commands are great if you can do it. I would break it down into how to install for each operating system. We also prefer trusted (safe), stable methods that help us manage a lot of dependencies where possible (for exampleapt,pip). The instructions are not just for me but potential MotifPeeker users.

Hiru (12:08:08) (in thread): > Thank you for your guidance. I have pushed an INSTALL file with the installation instructions for the system dependency. > > I think it may also be useful to include this note on Bioconductor’s documentation for the INSTALL file.

2024-08-19

Rema Gesaka (09:37:29): > @Rema Gesaka has joined the channel

2024-09-02

Mireia Ramos-Rodríguez (06:40:44): > @Mireia Ramos-Rodríguez has joined the channel

2024-09-03

Kevin Stachelek (20:18:39): > Hi, I am struggling to get R CMD check under 10 min in github actions. My local R CMD check is < 10min. I understand that there are many steps I could take to reduce the time for R CMD check but I can’t tell how far off I am from 10 min. Is there a way to reproduce the packagebuilder R CMD check or get more detailed logs?

Kevin Stachelek (20:30:18) (in thread): > I now see that this has been addressed on slack already to some extent herehttps://community-bioc.slack.com/archives/C0207H5QC3X/p1695369751083619 - Attachment: Attachment > Hello everyone! > > I am in the process of submitting an R package to Bioconductor and I came across a warning that I would like to discuss. When running R CMD CHECK on Linux, I receive the following warning: WARNING: R CMD check exceeded 10 min requirement. I only encounter this error during the check on Linux but not on macOS. > > I would like to know if this maximum 10-minute requirement is strictly mandatory before reducing the number of tests and examples of the code? I would also like to ask if anyone knows of a way to obtain the exact time it takes for R CMD CHECK to run because I have information that it takes more than 10 minutes but not the exact value. > > I appreciate any guidance or advice you can provide. Thank you in advance!

Vince Carey (21:47:22) (in thread): > what package is this about?

2024-09-04

Lluís Revilla (13:19:21) (in thread): > There are docker images with the same settings as used in Bioconductor that you can use to see if it takes longer or nothttps://www.bioconductor.org/help/docker/. But Bioconductor machines are usually very busy.

Kevin Stachelek (18:55:02) (in thread): > Thanks for the response. The submitted package is herehttps://github.com/Bioconductor/Contributions/issues/3332Thanks for the link to the docker documentation. In the end, I dramatically reduced the size of data used for examples and tests and that was sufficient. I had hoped to use experimenthub data but that was seemingly not possible given CMD check time limits. - Attachment: #3332 chevreul > Update the following URL to point to the GitHub repository of
> the package you wish to submit to Bioconductor > > • Repository: https://github.com/whtns/chevreul/ > > Confirm the following by editing each check box to ‘[x]’ > > • I understand that by submitting my package to Bioconductor,
> the package source and all review commentary are visible to the
> general public. > • I have read the Bioconductor Package Submission
> instructions. My package is consistent with the Bioconductor
> Package Guidelines. > • I understand Bioconductor <https://bioconductor.org/developers/package-submission/#naming|Package Naming Policy> and acknowledge
> Bioconductor may retain use of package name. > • 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. > • My package addresses statistical or bioinformatic issues related
> to the analysis and comprehension of high throughput genomic data. > • 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. > • 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: > > • The ‘devel’ branch for new packages and features. > • The stable ‘release’ branch, made available every six
> months, for bug fixes. > • Bioconductor version control using Git
> (optionally via GitHub). > > 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.

2024-09-07

Tyler Sagendorf (14:36:51): > @Tyler Sagendorf has joined the channel

2024-09-18

Philippa Doherty (14:42:33): > @Philippa Doherty has joined the channel

Philippa Doherty (14:44:19): > Hi, I’m looking for documentation on how/where to submit a package for review. Any quick links? Thanks in advance!

Helena L. Crowell (14:49:23) (in thread): > See here -https://contributions.bioconductor.org/bioconductor-package-submissions.html#submission - Attachment (contributions.bioconductor.org): Chapter 1 Bioconductor Package Submissions | Bioconductor Packages: Development, Maintenance, and Peer Review > Introduction Types of Packages Package Naming Policy Author/Maintainer Expectations Submission Experiment data package Annotation package Workflow package Review Process Following Acceptance…

Philippa Doherty (14:50:24) (in thread): > Thank you!

Lori Shepherd (14:55:43): > And for anyone that is currently in review – we are testing new builders , for now you can ignore the results of nebbiolo2 and use teran2 report for fixing relevant ERROR/Warning/Notes

2024-10-02

Eva Hamrud (19:07:18): > @Eva Hamrud has joined the channel

2024-10-12

Jonathan Carroll (02:16:06): > @Jonathan Carroll has joined the channel

2024-10-16

Hiru (10:07:30): > Hi Bioconductor team, I wanted to follow up regarding my package submission, which has not received any updates for over two months since a reviewer was assigned. I reached out to the assigned reviewer two weeks ago but haven’t received a response. > I understand that everyone is busy, but I would greatly appreciate any assistance you could provide in expediting the review process. I am eager to have my package accepted so I can proceed with my publication. > > Submission:https://github.com/Bioconductor/Contributions/issues/3483

Lori Shepherd (10:11:24) (in thread): > @Marcel Ramos Pérezcan you get to this today?

Marcel Ramos Pérez (10:12:24) (in thread): > Hi Hiru, sorry for the delay. We have a long list of packages to review. I will get to it by the end of today.

Hiru (10:14:43) (in thread): > Thank you for the update! Please take your time; it doesn’t have to be today—later this week works as well. I was just concerned that my package might have been overlooked.

2024-10-22

Liyang Fei (00:09:58): > @Liyang Fei has joined the channel

2024-10-24

Hiru (11:44:29): > Hello@Lori Shepherdand@Andres Wokaty, I hope your day is going well. Looks like the MEME suite is bugged on teran2, my build is failing with the following error: > > Error in `.check_valid_command_path(validPathHierarchy[[1]]): Command: /home/pkgbuild/meme/bin, does not exist. > > Full Build Report

2024-10-25

Andres Wokaty (15:11:22) (in thread): > @HiruIt seemed there was a problem with the initial installation. I’ve reinstalled it, but couldn’t runR CMD checkon your package because the builds just started. Maybe you could bump your version and push to see if it still emits the same error at a later time?

2024-10-26

Hiru (11:21:53) (in thread): > Thank you Jen, I will confirm build status with you soon.

2024-10-28

Hiru (12:18:47) (in thread): > Hello@Andres Wokaty, I can confirm that the MEME suite functions correctly with the latest push. However, the build completes with a WARNING status, even though there are no warnings mentioned in the build logs. Could this be related to another teran2 issue?Build Report

Lori Shepherd (12:21:28) (in thread): > the warning tag with no warning in report is an SPB issue – I can look into it

2024-11-04

Kevin Stachelek (12:47:56): > Hello, I am attempting to submit a package with a new url after a change in ownership on github but my submission issue is being automatically closed. Can you let me know how to proceed?https://github.com/Bioconductor/Contributions/issues/3332#issuecomment-2450805966 - Attachment: Comment on #3332 (inactive) chevreul > Hi @LiNk-NY and @lshep, when I attempted to add packages with the new urls this issue was closed. Can you let me know how to proceed?

Andres Wokaty (13:15:45) (in thread): > @Lori Shepherdprobably knows best but she is OOO.@Marcel Ramos PérezDo you happen to know what’s the best action?

Kevin Stachelek (14:56:50) (in thread): > I appreciate the help

Marcel Ramos Pérez (17:09:13) (in thread): > Good question, I will defer to Lori for the answer as she works with the SPB code. Thanks!

Lori Shepherd (19:29:04) (in thread): > I’ll be back on Thursday and can assist with this

2024-11-07

Michael Nakai (22:07:41): > @Michael Nakai has joined the channel

Shila Ghazanfar (22:07:49): > @Shila Ghazanfar has joined the channel

Malvika Kharbanda (22:11:07): > @Malvika Kharbanda has joined the channel

2024-11-09

Melody Jin (00:30:20): > @Melody Jin has joined the channel

2024-11-11

Hiru (07:05:50) (in thread): > Hello@Lori Shepherd, are there any updates on the phantom WARNING?

Lori Shepherd (07:26:47) (in thread): > we pushed what we thought would fix the erroneous warnings on Friday

Hiru (07:27:36) (in thread): > Ah okay, should I bump the package version for a build re-run in that case?

Lori Shepherd (07:30:28) (in thread): > if you like that would be great

Hiru (09:26:17) (in thread): > Can confirm the issue is solved. Thank you, Lori!

2024-11-12

Tim Triche (08:28:16): > @Tim Triche has joined the channel

Tim Triche (08:28:36): > Is this where reviewers go?

Lori Shepherd (08:42:05) (in thread): > there is a closed reviewers channel so reviewers can discuss any issues freely. I can invite after we meet for an on-boarding session

Tim Triche (08:42:27) (in thread): > Right on, I was just following links

2024-11-25

Haichao Wang (07:14:48): > Hi can I ask a question:

Haichao Wang (07:16:51): > At the moment my bioconductor package is linked with my own github account repository , I need to change the ownership of my github repo, is there a way to do this without affecting the bioconductorworkflow?

Lori Shepherd (07:21:41) (in thread): > is the package already ongit.bioconductor.org?

Haichao Wang (07:25:57) (in thread): > @Lori Shepherdyes, it is already on

Lori Shepherd (07:29:29) (in thread): > Thegit.bioconductor.orgversion of the package is not linked to any github repository. The Bioconductor version only will build, check, propagate pushes togit.bioconducto.organd not your github. So you shouldn’t need to do anything and the Bioconductor workflow should remain the same. > > If the change of ownership also means a change of maintainer, that can be requested. A change of maintainer would be changed in the DESCRIPTION by yourself, and then if necessary a new BiocCredentials account can be created by the core team, and make sure registration of the support site and mailing list for new maintainer.

2025-02-02

Sarah Choi (18:33:27): > @Sarah Choi has joined the channel

Sarah Choi (18:35:10): > Hello, I am currently aiding in the development of an R package that is to be submitted to Bioconductor, and am wondering whether unit tests are a requirement for the submission, and if so, how comprehensive they are expected to be. For example, some of the package methods are simply meant to return a plot or figure, etc.

Kasper D. Hansen (22:21:03): > The package will be reviewed assuming it is complete and ready for public consumption

Kasper D. Hansen (22:21:42): > So lack of unit tests is a negative and you will be asked to do something about it.

Kasper D. Hansen (22:22:06): > That being said, not all functions need unit tests and for example it is still hard to unit test a plot.

2025-02-14

Grace Kenney (15:41:23): > @Grace Kenney has joined the channel

2025-02-20

James Nemesh (10:14:35): > @James Nemesh has joined the channel

2025-03-08

Lluís Revilla (06:58:22): > Hi! I’m a member of the BiocClasses working group. I’m looking for feedback from package reviewers and package developers about the confusions and challenges with Bioconductor classes (S4, R6, S3, S7) in order to see how we can help and improve the situation. Feel free to reply or send a direct message with your comments. > For packagedevelopers: what classes do you used, and why, what were the challenges implementing them, or what was easier to do it.. > Or if you are areviewer:what confusion you see more often, what classes are more reused, why do you recommend some classes and not others… > I’d like to see how we can help improve Bioconductor on how we approach object classes. > Thanks!

2025-03-10

Tim Triche (10:39:29) (in thread): > S4: I’m used to it but tidy-ish workflows are rough > S3: it’s there > R6: is this allowed anymore? > S7: how to use it within BioC? > > Also: when constructing something like a *Experiment that uses SE/SCE semantics, how best to migrate to S7? Or whether to ever migrate? Will this happen or is it just too heavy a lift given Herve’s many responsibilities? etc.

Kasper D. Hansen (11:19:48) (in thread): > I would like to see some description oh what R6 / R7 brings to the table wrt. data representation. The data representation is for sure what is most important in our project. Most of our usage of methods is (with some exceptions like GenomicRanges) pretty mild

Tim Triche (11:20:41) (in thread): > R6 was nice but when Wanding submitted a package using it he was requested not to, so

Kasper D. Hansen (11:22:08) (in thread): > Yeah, so I am out of the loop on that. I would like to know what the advantage are

Kasper D. Hansen (11:24:32) (in thread): > I (personally, but I also think it is true for many other developers) have a pretty good understanding of the advantages of R4 compared to R3 when it comes having data representation models.

Kasper D. Hansen (11:24:56) (in thread): > (sorry messing up with R3 and S3 etc but intention should be clear)

Lluís Revilla (11:30:05) (in thread): > I take that some advice on what and how is needed (what I thought). But I note that so far there aren’t specific comments about classes but about object orienting paradigm used.

Lluís Revilla (11:31:11) (in thread): > @Tim TricheCould you please link to the issue? I’d like to know the reasoning on why R6 was not allowed.

Tim Triche (11:31:25) (in thread): > @Lluís Revillayou’d have to ask Lori

Lluís Revilla (11:31:26) (in thread): > As far as I know, there is nothing against it on the documentation.

Tim Triche (11:31:39) (in thread): > or whoever reviewed sesame

Lluís Revilla (11:33:48) (in thread): > Got it:https://github.com/Bioconductor/Contributions/issues/716#issuecomment-379496748I’ll read the discussions.

Lluís Revilla (11:35:06) (in thread): > About migrating from one OOP to a different one (S4 to S7) this is something someone else was interested to work on on the#biocclasses.

Lluís Revilla (11:44:15) (in thread): > The burden of Bioconductor maintainers is big, and I am not sure how to contribute to lift that burden. I don’t see what I/we can pick it up. For example, the classes recommendation was written without engaging with the community, while this could be done by concerned developers.

2025-03-13

Mihai Todor (06:59:46): > @Mihai Todor has joined the channel

2025-03-24

Tim Triche (11:01:58) (in thread): > I’m wondering if an LLM can be finetuned to handle the first pass of review

Tim Triche (11:02:34) (in thread): > I signed up to review packages and realized why it consumes 140% of Lori’s time

2025-03-25

Lluís Revilla (05:05:15) (in thread): > What would be the “first pass of review”? From what I observed many comments are already covered by BiocCheck and the feedback from the bot …

Tim Triche (08:20:48) (in thread): > sure, I meant more subtle bits like “vignette is actually compiled,” “uses some foundational classes for foundational tasks,” etc.

Tim Triche (08:22:48) (in thread): > it occurred to me while starting to review that > 1. getting parallelreleaseanddevelenvironments set up and maintained is a pain > 2. going through the checklist is a pain (would like to distill the process to “only check the bits that are outside normal ranges”) > 3. coordinating feedback is a pain > and if there are more class/object systems with possible pitfalls, this may get exponentially worse

Tim Triche (08:23:29) (in thread): > e.g. per last week’s discussion, if I wanted to wrap aSummarizedExperiment-like object withS7, I now know that I am asking for pain

Lluís Revilla (10:13:33) (in thread): > vignette compiled it can be checked, by exploring the R file generated with them. About “foundational classes” I’m not sure we agree on what those are. When I first proposed to document them I didn’t expect the Bioconductor core team to unilaterally decide them. > The rest of the points. > 1. rig and remotes make that much easier than it used to be, and docker is great too > 2. To run some checks and report what it is missing doesn’t need a LLM > 3. Can’t comment much on this, but also not sure how LLM would help.

2025-03-28

Tim Triche (15:35:47) (in thread): > good points, maybe I need to look into rig more! Regarding classes, I think I figured out how to start to decouple SummarizedExperiment from some of its S4 moorings in a way that might make S7Experiment-type stuff feasible. Will try and get back in the saddle next weke

2025-04-30

Sarah Choi (10:31:16): > Hi. I accidentally submitted a package for review using the wrong GitHub account.This submissionmade with the GitHub handlesarahmccxvwas supposed to be submitted with the GitHib accountcrossexpressionmaintenance. I tried closing the issue andresubmitting with the correct accountand ran into some trouble. Is there anywhere where I can get some technical assistance on this?

Lori Shepherd (10:33:36) (in thread): > yes I can assist. Give me a a few minutes and I’ll reset the submission queue. Once I give the okay you will be able to resubmit to make sure everything is registered correctly

Lori Shepherd (10:35:29) (in thread): > okay. It should be okay to resubmit a new issue now