[Bioc-devel] required force push to bioconductor

[Rheinnecker, Marco]

Dear all,


Unfortunately, I caused problems on the devel branch of my ZygosityPredictor 
packages, which I could only solve by resetting to a previous commit.

I now have to force push the changes to the bioconductor devel. Unfortunately, 
I can't do this myself, so I would like to ask if this could be arranged?

If further information or help is needed on my part, I am happy to provide it.

Thank you very much!
Marco Rheinnecker

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Important Bioconductor Release Deadlines

[Henrik Bengtsson]

> ... I'm on Mac OS 12.5.

I've heard good things about 'rig' (The R Installation Manager;
https://github.com/r-lib/rig). It can install multiple R versions in
parallel on macOS, Windows, and Linux, without the different versions
conflicting with each other.  I recommend trying it out, because being
able to run different versions of R is always useful, even if you're
not a package maintainer.

/Henrik

On Thu, Apr 4, 2024 at 8:08 PM Anatoly Sorokin  wrote:
>
> Hi Henrik,
>
> thank you for the prompt reply. I'm on Mac OS 12.5.
>
> And regarding the linking version of Bioconductor and R my major complaint is 
> the timing, if R 4.4 hasn't been released yet, why not postpone this 
> dependency to the October release of Bioconductor?
>
> And it is also true that we have a lot of complaints from people working on 
> centrally maintained machines or HPC clusters, that they have no access to 
> the latest R versions. So sometimes even for demonstration purposes, we had 
> to install the package from the GitHub source, rather than from BiocManager.
>
> Cheers,
> Anatoly
>
> On Fri, Apr 5, 2024 at 11:57 AM Henrik Bengtsson  
> wrote:
>>
>> Hello,
>>
>> these days, it's quite straight forward to have multiple versions of R
>> installed in parallel without them conflicting with each other. I know
>> it works out of the box on MS Windows (just install all versions you'd
>> like), and I know there are various tools to achieve the same on
>> macOS.  I'm on Linux, and I build R from source, so that solves it for
>> me.  What's platform are you working on?  If you share that, I think
>> you'll get 1-2-3 instructions for how to install R 4.4 pre-release
>> from users on that operating system.
>>
>> Regarding Bioc versions being tied to specific R versions: That is a
>> design decision that goes back to day one of the Bioconductor project.
>> It's a rather big thing to change.  That said, I've always been in the
>> camp that thinks we should move away from that model for many reasons;
>> one is the friction added to developers, another is the friction added
>> to end-users, and some people may be stuck with older versions of R
>> and in no control of updating.
>>
>> Hope this helps,
>>
>> Henrik
>>
>> On Thu, Apr 4, 2024 at 7:29 PM Anatoly Sorokin  wrote:
>> >
>> > Hi all,
>> >
>> > I'm sorry for the complaint, but do you really think it is wise to make the
>> > new release dependent on the R version which has not released yet?
>> >
>> > I have a lot of R-related projects going on apart from maintaining the
>> > Bioconductor package and I'm not comfortable installing the unreleased
>> > version of R on my machine and spending time debugging it in the case of
>> > possible problems.
>> >
>> > At the same time, I have an error, possibly caused by a new version of
>> > GO.db package, which BioNAR is dependent upon and I can not fix it
>> > until the R 4.4 release on the 24th of April when I would have less than a
>> > day to fix the possible problem and fit into R CMD build and R CMD check by
>> > the Friday April 26th. Don't you think this is a rather tight time frame?
>> >
>> >
>> > Sorry once again, for the complaint.
>> >
>> > Cheers,
>> > Anatoly
>> >
>> > On Tue, Mar 26, 2024 at 11:06 PM Kern, Lori via Bioc-devel <
>> > bioc-devel@r-project.org> wrote:
>> >
>> > > Import update:  The Bioconductor Release will be May 1 following the
>> > > release of R 4.4 on April 24.
>> > >
>> > > The Bioconductor 3.18 branch will be frozen Monday April 15th. After that
>> > > date, no changes will be permitted ever on that branch.
>> > >
>> > > The deadline for devel Bioconductor 3.19 for packages to pass R CMD build
>> > > and R CMD check is Friday April 26th. While you will still be able to 
>> > > make
>> > > commits past this date, This ensures any changes pushed to
>> > > git.bioconductor.org are reflected in at least one build report before
>> > > the devel branch will be copied to a release 3.19 branch.
>> > >
>> > > Cheers,
>> > >
>> > >
>> > >
>> > > Lori Shepherd - Kern
>> > >
>> > > Bioconductor Core Team
>> > >
>> > > Roswell Park Comprehensive Cancer Center
>> > >
>> > > Department of Biostatistics & Bioinformatics
>> > >
>> > > Elm & Carlton Streets
>> > >
>> > > Buffalo, New York 14263
>> > >
>> > >
>> > > This email message may contain legally privileged and/or confidential
>> > > information.  If you are not the intended recipient(s), or the employee 
>> > > or
>> > > agent responsible for the delivery of this message to the intended
>> > > recipient(s), you are hereby notified that any disclosure, copying,
>> > > distribution, or use of this email message is prohibited.  If you have
>> > > received this message in error, please notify the sender immediately by
>> > > e-mail and delete this email message from your computer. Thank you.
>> > > [[alternative HTML version deleted]]
>> > >
>> > > ___
>> > > Bioc-devel@r-project.org mailing list
>> > > 

Re: [Bioc-devel] Important Bioconductor Release Deadlines

[Henrik Bengtsson]

> Henrik, if Bioconductor releases weren’t tied to R releases, how could 
> Bioconductor test them? I guess like CRAN where as long as a package says it 
> depends on R >= 2.0 then you’re free to try installing on 2.0 even though the 
> combination has never been tested? Maybe I worry too much about such testing 
> since CRAN seems OK anyways, as far as we know?

TL;DR: I think Bioconductor could say: "We have only tested Bioc
release on R version x.y. There is no guarantee it will work with
another version of R."

Here is my view:

The Bioconductor Project guarantees that R packages part of the the
Bioc release version and the Bioc development version are well tested
and work well together.  That is the agreed upon objective.

Then there's the objective that Bioconductor wants to protect
end-users from shooting themselves in the foot. This is done by
preventing users from mix-and-match installing Bioc release and
development packages, which is the main role of the BiocManager
package.

Half of the year, it's easy to implement this protection, because the
Bioc release runs on R release and Bioc devel on R devel. I see that
as an obvious first approach, because R itself takes care of
everything for us and Bioc release and devel are nicely separated on
the users computer.  This model worked really well when R had two
releases per year.  However, even since R moved to one release per
year and Bioc kept two, the above model cannot be used six months of
the year.  Instead, for those months, we have to manually manage our
own R package library if we would like to swiftly move between Bioc
release and Bioc devel versions.  I'm pretty sure, few users and
developers actually bothers with that.

I would like to see a model where you can instantaneously switch
between Bioconductor versions for a given R version when you launch R,
e.g. BiocManager::use("release"), BiocManager::use("devel"), and
BiocManager::use("3.16"). Under the hood, this would just reconfigure
.libPaths() and the R 'repos' option.

Now, imagine we had the latter in place, how would we look at the
dependency between Bioc version and R version?  I suspect it's the
technical problems that keep us stuck with the above half-broken model
rather than what we ideally want.


To address "how could Bioconductor test them?": I think this question
has two parts to it.

The first one is practical/financial. If we had sufficient compute
resources, we could of course test Bioc release and Bioc devel on R
oldrel, R release, and R devel. Those are the version that CRAN
guarantees all CRAN packages support. If a CRAN package fail on one of
those, it will be archived on CRAN, unless you clearly state and argue
for a give R version requirement.

On the other hand, by promising to support multiple R versions, you
constrain what new R features an R package might use. So, if
Bioconductor wants to make life easy for package developers so that
they don't have to worry about backward compatibility, then
Bioconductor might want to be more conservation and say, we only
guarantee support for R release and R devel.  Which is basically what
we have today (or at least half of the year).

To address "I guess like CRAN where as long as a package says it
depends on R >= 2.0 then you’re free to try installing on 2.0 even
though the combination has never been tested?": Yes, CRAN only tests
on R oldrel, release, and devel version.  Anything beyond that is "Use
at your own risk". I think that's perfectly fine. Some package
managers test against old versions (e.g. via GitHub Actions) and
maintain a "Depends: R (>= 2.0)" specification. There are also lots of
packages that are no longer updated and just keep working regardless
of new R releases, meaning their code is never changes, meaning if
they passed CRAN's checks on R 2.0.0 back in the days, they will still
pass those checks.  I argue that it adds unnecessary friction to users
(and developers) by going extra miles trying to prevent them from
running a Bioc devel package on an older version of R just because
"Bioconductor hasn't tested it, so we cannot guarantee it works, so we
will not allow you to install it".  My opinion is that Bioconductor
should only use on the built-in "Depends: R (>= x.y)" feature to deal
with dependencies and rely on maintainers to keep them up-to-date. But
if they don't, it's not a big deal, because the overall expectation
should be that the Bioconductor Project only guarantees things to work
for a specific R version.

I think the biggest difference between Bioconductor and CRAN is the
decision how to deal with broken package dependencies. CRAN takes the
freedom to kick packages out within two weeks. They don't have to
think about maintaining a stable "CRAN release" bundle for six months.
In contrast, Bioconductor promises to maintain "Bioc release" for six
months. OTH, I don't know how this works in practice. I know broken
packages will not make it to the next Bioc release version if they're
not fixed, but 

Re: [Bioc-devel] plyranges maintainer update

[Kern, Lori via Bioc-devel]

We have updated the configurations on our end.  Michael should push changes to 
the description to update the maintainer on the landing pages and to receive 
any notifications from us.

Cheers,


Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Stuart Lee 

Sent: Friday, April 5, 2024 10:58 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] plyranges maintainer update

Hi bioc-devel,

I would like to request for me to removed as maintainer of the plyranges
package 

and for > to be added as
maintainer.

Thank you for your help.

Kind regards,
Stuart


Stuart Lee
stuart.andrew@gmail.com

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1ydKOV6wYbNclMneCuJkpCtifOmz6Xx4zaTd_xx7am--r7wj-JJOrvLH-QhuI1oqTPk2YjYbdJqsWLJxuPa2ts9KeokyrxeVaOuBBEo3b8zZ9pS4pkM_KBsvcPFnv8RGBJZicJplKgHdlEwR7k2wHYCaMqCWscGtUj6T6AAYYwYkcz5A64GedlLZebH06ZC6TJBZGSoM08XMcRlPYhEyocymDHhpgsezXfZD91zgYKC3LHVGUjuIBhcgpspL1m6QMgZ6Ajz2mp86Fz0QFDJx50LKT8PYxaRT38bZrBd0D_38I34a5vHiuZn_1YJGFnASz/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Moderately large files in an Experiment Data package?

[Kern, Lori via Bioc-devel]

Yes we would recommend using ExperimentHub.  Which is a database with pointers 
to the data files; so files are only downloaded when necessary to keep the 
package lightweight for end users.

You have some options to where the data is stored.  We encourage the use of 
zenodo or other well trusted data storage sites,  but a Bioconductor provided 
Microsoft data lake is also an option.

More documentation can be found at
https://bioconductor.org/packages/release/bioc/vignettes/HubPub/inst/doc/CreateAHubPackage.html

If you already have a data package, really the only changes would be to remove 
the data from that package and use a trusted remote location.  Create a 
required inst/extdata/metadata.csv that has the information to add to the 
experimenthub database.  And add the required biocViews to the description.

Cheers,



Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Barry, Timothy 
P 
Sent: Friday, April 5, 2024 4:22 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Moderately large files in an Experiment Data package?

Hello all,

I have initiated the submission of three packages to Bioconductor: 
sceptre
 (an R package for perturb-seq analysis), 
ondisc
 (a companion R package to sceptre that implements new data structures for 
large-scale single-cell data), and 
sceptredata
 (an experiment data package that provides example data for sceptre and 
ondisc). ondisc depends on sceptredata, and sceptre in turn depends on both 
ondisc and sceptredata. Our updated user 
manual
 describes how all three of these packages interface with one another.

In accordance with the Bioconductor submission instructions, I submitted the 
data package (i.e., sceptredata) 
first.
 However, I received the following error message: "The package contains 
individual files over 5Mb in size. This is currently not allowed.� Indeed, 
sceptredata contains two files that are 11MB and one file that is 6MB. The 
package stores example data in both the `data` directory and the `inst/extdata` 
directory.

I thought that experiment data packages were allowed to have larger files? If 
not, does anyone have a recommendation for how I should proceed? Kasper Hansen 
suggested ExperimentHub as a solution. Might that the way to go?

Thank you greatly for the help!
Tim


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list

Re: [Bioc-devel] Moderately large files in an Experiment Data package?

[Barry, Timothy P]

Hi Lori,

Thank you for the speedy and detailed reply. I will take a crack at the 
ExperimentHub option and resubmit.

Cheers,
Tim

On Apr 8, 2024, at 8:34 AM, Kern, Lori  wrote:

Yes we would recommend using ExperimentHub.  Which is a database with pointers 
to the data files; so files are only downloaded when necessary to keep the 
package lightweight for end users.

You have some options to where the data is stored.  We encourage the use of 
zenodo or other well trusted data storage sites,  but a Bioconductor provided 
Microsoft data lake is also an option.

More documentation can be found at
https://bioconductor.org/packages/release/bioc/vignettes/HubPub/inst/doc/CreateAHubPackage.html

If you already have a data package, really the only changes would be to remove 
the data from that package and use a trusted remote location.  Create a 
required inst/extdata/metadata.csv that has the information to add to the 
experimenthub database.  And add the required biocViews to the description.

Cheers,


Lori Shepherd - Kern
Bioconductor Core Team
Roswell Park Comprehensive Cancer Center
Department of Biostatistics & Bioinformatics
Elm & Carlton Streets
Buffalo, New York 14263

From: Bioc-devel 
mailto:bioc-devel-boun...@r-project.org>> on 
behalf of Barry, Timothy P 
mailto:tba...@hsph.harvard.edu>>
Sent: Friday, April 5, 2024 4:22 PM
To: bioc-devel@r-project.org 
mailto:bioc-devel@r-project.org>>
Subject: [Bioc-devel] Moderately large files in an Experiment Data package?

Hello all,

I have initiated the submission of three packages to Bioconductor: 
sceptre>
 (an R package for perturb-seq analysis), 
ondisc>
 (a companion R package to sceptre that implements new data structures for 
large-scale single-cell data), and 

[Bioc-devel] Moderately large files in an Experiment Data package?

[Barry, Timothy P]

Hello all,

I have initiated the submission of three packages to Bioconductor: 
sceptre (an R package for perturb-seq 
analysis), ondisc (a companion R 
package to sceptre that implements new data structures for large-scale 
single-cell data), and 
sceptredata (an experiment data 
package that provides example data for sceptre and ondisc). ondisc depends on 
sceptredata, and sceptre in turn depends on both ondisc and sceptredata. Our 
updated user manual describes 
how all three of these packages interface with one another.

In accordance with the Bioconductor submission instructions, I submitted the 
data package (i.e., sceptredata) 
first. However, I 
received the following error message: "The package contains individual files 
over 5Mb in size. This is currently not allowed.” Indeed, sceptredata contains 
two files that are 11MB and one file that is 6MB. The package stores example 
data in both the `data` directory and the `inst/extdata` directory.

I thought that experiment data packages were allowed to have larger files? If 
not, does anyone have a recommendation for how I should proceed? Kasper Hansen 
suggested ExperimentHub as a solution. Might that the way to go?

Thank you greatly for the help!
Tim


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel