Re: [Bioc-devel] Maintaining package with already modified fork repository from github.

[Kern, Lori]

I'm not a git expert by any means and someone may have better advice but my 
plan of attack would be the following:

If the repository with the changes is a fork, they should be able to request a 
Pull Request to your original repo. I would start there. You can access the 
changes on a separate branch of the original repository that is closest in sync 
with Bioconductor.

Then before merging that branch/PR request,

I would clone the original repo, make sure the remotes are set with an upstream 
for Bioconductor. do a git fetch --all and a git pull upstream to merge any 
Bioconductor changes.  Resolve any conflicts with that.

Then I would switch/checkout to the PR branch, merge the main/master branch 
into the PR branch, and resolve any merge conflicts there.
Then checkout/switch back to the main/master branch and merge the PR branch.

Do the version bump separate and lastly after all merge conflicts are resolved. 
 If its a major release, you can not bump the x of version x.y.z yourself.  If 
you would like it to be 2.0.0 in the april release,  please bump the y to 99 
and then continue to do routine maintenance by bumping z as normal.
eg.  if the version was 1.23.0, you would bump to 1.99.0 or 1.99.1 -- .

And as you described, you would only do all of this on the master branch that 
is associated with devel and have the changes in the april release.

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 Jean-Philippe 
Villemin 
Sent: Friday, November 25, 2022 3:40 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Maintaining package with already modified fork repository 
from github.

I have a few questions about managing a bioconductor package. Of course I
have been through the doc for package maintenance here
.
I Just want to check that my forklow is ok.

We have a bioconductor package.
We want to move its github source account to our github account lab. I'm
not sure what should be my starting point.

One collaborator did somes changes on a fork from the github (not
bioconductor) in its github account . He shared access with us  (~100
commits without bumbling x.y.z+1 each commit). I want to reuse that but I
don't know if i still need to fetch also from Bioconductor (before/after)

1 - Access and modify BiocCredientials

freely.
(I'm not a maintainer, a colleague is, so he will add me. I need that to
fetch from biocond right ?)
2 - On local, clone the fork from my colleague. (or bioconductor first ? )
3 - Should I fetch from Bioconductor ? (pretty sure this part will create
troubles)
4 - Create an empty remote with the same name as on bioconductor, push the
cloned repo

5 - Configure upstream bioconductor...
6 - git push to remote bioconductor.
7 - In April changes will be added to release.

Specific question for 3 : How do we handle the bumble version thing ?
For the push, it will be a major release . (S4 code refactoring) (so should
I push something like 2.0.0)

Thanks.



--
*Jean-Philippe Villemin   *- Bioinformatics, PhD -

Cancer Bioinformatics and Systems Biology

Institut de Recherche en Canc�rologie de Montpellier

Inserm U1194


*jpville...@gmail.com *

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/17UXw2q576Fok_ALQpFnh-fJLNZJmdpG2vVlAO_XikXowEf9_OXtKa60jQDDUuHKd8bymoYqcV5KHRV4omHUuVjC3DW_-LXsDosT8LLzvhQunyGAzb09G6gwz3oJPsY4nLvFZvJBK4FxsLRyg9-uzVCTCTlPdxfZzQGCiT_exv_aaVIEObs1B3gFuUOsLwQeU-J9svS0MMgKmVe30Mml40thzv7oQNrvpO5LBX6t0KgTSXsTgxh-mY_EVzTKRySb-WLXILLXDAB3kvels2FDBeiPgefB1tzsHcJ_isgti1pxQgym5mh-vJYRqeZrMeE7E/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 not

Re: [Bioc-devel] Flexibility for submitting a new ExperimentData-package

[Vincent Carey]

Thank you for this note.  We cannot modify the system to accept this
package.  If we can help with aspects
of compatibility problems related to ExperimentHub let us know.

On Thu, Nov 24, 2022 at 1:58 AM Daniel Laajala  wrote:

> Dear Bioconductor devs,
>
> thanks for all the hard work. Regarding if there's any leeway in how
> ExperimentData-packages are structured:
>
> We started working a few years back on a "curatedPCaData" R-package for
> curating prostate cancer multi-'omics datasets. We followed the structure
> of a family of similar packages, e.g. readily on bioc:
>
> https://bioconductor.org/packages/release/data/experiment/html/curatedBreastData.html
>
> https://bioconductor.org/packages/release/data/experiment/html/curatedOvarianData.html
>
> With the data in a satisfactory form, we were now hoping to submit the
> package to Bioconductor. However, due to the size of
> MultiAssayExperiment-objects, the package is auto-rejected:
> https://github.com/Bioconductor/Contributions/issues/2804
>
> The data-raw/-files we can discard, as we provided these just for extra
> user convenience.
> However, the mae_*.rda files are essential MultiAssayExperiment objects
> (as a standard format for multi-'omics in Bioc), but these are right now
> too large for the bot.
>
> Reading the package structure instructions, we were under the impression
> that this old structure for ExperimentData would still be ok for
> Bioconductor; the package passed checks (R CMD check and BiocCheck) with
> minor NOTEs. Our current GitHub is at:
> https://github.com/Syksy/curatedPCaData
>
> Our package already has citations (with code provided there-in for
> extracting and processing relevant data from the package), has been forked,
> has collaborators using it as-is, etc, so revamping it to e.g.
> ExperimentHub-structure would most likely cause quite major compatibility
> issues.
>
>
> Would there be any chance of approaching Bioconductor with the package
> roughly in its current format inspired by these older curated-packages,
> even if it is not in the updated ideal ExperimentData-format?
>
> Kind regards,
> Teemu Daniel Laajala
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Flexibility for submitting a new ExperimentData-package

[Marcel Ramos]

Hi Teemu Daniel,

Those packages were developed before ExperimentHub.

Please follow the current standard for experiment data packages at

https://bioconductor.org/packages/release/bioc/vignettes/ExperimentHub/inst/doc/ExperimentHub.html

You may want to take a look at curatedTCGAData as an example 
(disclaimer: I developed the package).
It is advisable to split the resources into more modular components, 
e.g., colData, sampleMap, data assays
rather than distribute serialized MultiAssayExperiment objects.

IMO, there should be no compatibility issues as the changes would only 
affect the underlying code and
not the user interface.

Best regards,

Marcel


On 11/24/22 1:57 AM, Daniel Laajala wrote:
> Dear Bioconductor devs,
>
> thanks for all the hard work. Regarding if there's any leeway in how 
> ExperimentData-packages are structured:
>
> We started working a few years back on a "curatedPCaData" R-package for 
> curating prostate cancer multi-'omics datasets. We followed the structure of 
> a family of similar packages, e.g. readily on bioc:
> https://bioconductor.org/packages/release/data/experiment/html/curatedBreastData.html
> https://bioconductor.org/packages/release/data/experiment/html/curatedOvarianData.html
>
> With the data in a satisfactory form, we were now hoping to submit the 
> package to Bioconductor. However, due to the size of 
> MultiAssayExperiment-objects, the package is auto-rejected:
> https://github.com/Bioconductor/Contributions/issues/2804
>
> The data-raw/-files we can discard, as we provided these just for extra user 
> convenience.
> However, the mae_*.rda files are essential MultiAssayExperiment objects (as a 
> standard format for multi-'omics in Bioc), but these are right now too large 
> for the bot.
>
> Reading the package structure instructions, we were under the impression that 
> this old structure for ExperimentData would still be ok for Bioconductor; the 
> package passed checks (R CMD check and BiocCheck) with minor NOTEs. Our 
> current GitHub is at:
> https://github.com/Syksy/curatedPCaData
>
> Our package already has citations (with code provided there-in for extracting 
> and processing relevant data from the package), has been forked, has 
> collaborators using it as-is, etc, so revamping it to e.g. 
> ExperimentHub-structure would most likely cause quite major compatibility 
> issues.
>
>
> Would there be any chance of approaching Bioconductor with the package 
> roughly in its current format inspired by these older curated-packages, even 
> if it is not in the updated ideal ExperimentData-format?
>
> Kind regards,
> Teemu Daniel Laajala
>
>
>   [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org  mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

This email message may contain legally privileged and/or...{{dropped:4}}

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

Re: [Bioc-devel] Flexibility for submitting a new ExperimentData-package

[Marcel Ramos]

Hi Teemu Daniel,

Those packages were developed before ExperimentHub.

Please follow the current standard for experiment data packages at

https://bioconductor.org/packages/release/bioc/vignettes/ExperimentHub/inst/doc/ExperimentHub.html

You may want to take a look at curatedTCGAData as an example 
(disclaimer: I developed the package).
It is advisable to split the resources into more modular components, 
e.g., colData, sampleMap, data assays
rather than distribute serialized MultiAssayExperiment objects.

IMO, there should be no compatibility issues as the changes would only 
affect the underlying code and
not the user interface.

Best regards,

Marcel


On 11/24/22 1:57 AM, Daniel Laajala wrote:
> Dear Bioconductor devs,
>
> thanks for all the hard work. Regarding if there's any leeway in how 
> ExperimentData-packages are structured:
>
> We started working a few years back on a "curatedPCaData" R-package for 
> curating prostate cancer multi-'omics datasets. We followed the structure of 
> a family of similar packages, e.g. readily on bioc:
> https://bioconductor.org/packages/release/data/experiment/html/curatedBreastData.html
> https://bioconductor.org/packages/release/data/experiment/html/curatedOvarianData.html
>
> With the data in a satisfactory form, we were now hoping to submit the 
> package to Bioconductor. However, due to the size of 
> MultiAssayExperiment-objects, the package is auto-rejected:
> https://github.com/Bioconductor/Contributions/issues/2804
>
> The data-raw/-files we can discard, as we provided these just for extra user 
> convenience.
> However, the mae_*.rda files are essential MultiAssayExperiment objects (as a 
> standard format for multi-'omics in Bioc), but these are right now too large 
> for the bot.
>
> Reading the package structure instructions, we were under the impression that 
> this old structure for ExperimentData would still be ok for Bioconductor; the 
> package passed checks (R CMD check and BiocCheck) with minor NOTEs. Our 
> current GitHub is at:
> https://github.com/Syksy/curatedPCaData
>
> Our package already has citations (with code provided there-in for extracting 
> and processing relevant data from the package), has been forked, has 
> collaborators using it as-is, etc, so revamping it to e.g. 
> ExperimentHub-structure would most likely cause quite major compatibility 
> issues.
>
>
> Would there be any chance of approaching Bioconductor with the package 
> roughly in its current format inspired by these older curated-packages, even 
> if it is not in the updated ideal ExperimentData-format?
>
> Kind regards,
> Teemu Daniel Laajala
>
>
>   [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org  mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

This email message may contain legally privileged and/or...{{dropped:4}}

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

Re: [Bioc-devel] Failed to locate 'texi2pdf' - Windows build error

[Jennifer Wokaty]

Hi Pedro,

I don't see these issues on today's build report, so they may have been 
resolved. If you see the issue again, let us know.

Jennifer Wokaty (they/them)

Waldron Lab at CUNY SPS
Bioconductor Core Team

From: Bioc-devel  on behalf of Pedro Madrigal 

Sent: Friday, November 25, 2022 4:09 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Failed to locate 'texi2pdf' - Windows build error

***ATTENTION: This email came from an external source. Do not open attachments 
or click on links from unknown senders or unexpected emails.***

Dear Bioc-Devel

I have a couple of packages (CexoR, fCCAC) failing the Windows-build due to

Warning in system(paste(shQuote(texi2dvi), "--version"), intern = TRUE) :
  running command '"C:\PROGRA~1\MiKTeX\miktex\bin\x64\texify.exe" --version' 
had status 1033
Warning in system(paste(shQuote(texi2dvi), if (quiet) "--quiet" else "",  :
  running command '"C:\PROGRA~1\MiKTeX\miktex\bin\x64\texify.exe" --quiet --pdf 
"CexoR.tex" ' had status 1033
Error: processing vignette 'CexoR.Rnw' failed with diagnostics:
Failed to locate 'texi2pdf' output file 'CexoR.pdf' for vignette with name 
'CexoR' and engine 'utils::Sweave'. The following files exist in working 
directory 
'F:\biocbuild\bbs-3.16-bioc\tmpdir\Rtmpkf5YYz\Rbuild42143e2f6b79\CexoR\vignettes':
 'CexoR.Rnw' (6938 bytes), 'CexoR.tex' (14846 bytes)
--- failed re-building 'CexoR.Rnw'
I think this is happening in other packages as well. Could please provide 
advice?

Best wishes,
Pedro

--
Dr Pedro Madrigal
Senior Bioinformatician, Gene Expression Team
European Bioinformatics Institute (EMBL-EBI)
European Molecular Biology Laboratory
Wellcome Trust Genome Campus
Hinxton, Cambridge
CB10 1SD, United Kingdom



[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=mRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY&r=FKSqKXkUOES-D4VQb2jSn9QK7Vz5lE18rLcyn73CPhA&m=-FclmDt0uLHmAGUyQ2qFlSCNHEss7xxExR__ih3WtQ-vrQgJo-UMIfJE-sWPsIir&s=vlTkawNFotVv7kwME8ZtWVxqEpYGFN8R1AzFRIelo-w&e=

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] S4 Methods Documentation Convention Triggers Warnings

[Deepayan Sarkar]

On Sun, Nov 27, 2022 at 12:30 PM Dario Strbenac via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Good day,
>
> For a long time, it has been a convention to document S4 methods in the
> format:
>
> \section{Displaying}{
>   In the code snippets below, \code{x} is a GRanges object.
>   \describe{
> \item{}{
>   \code{show(x)}:
>   Displays the first five and last five elements.
> }
>   }
> }
>
> In R Under Development, this is now a warning:
>
> * checking Rd files ... WARNING
> checkRd: (5) GRanges-class.Rd:115-165: \item in \describe must have
> non-empty label.
>

> This affects my own package as well as the core Bioconductor packages
> which I used as inspiration for designing my pacakge documentation seven
> years ago. What should the new convention be? Or could R developers be
> convinced to get rid of this check before this prototype is released?
>

The warning is primarily meant for \items inside \arguments, as in HTML
output these now have an id that can be used to link to specific arguments.
The code is shared with \describe, which is why the warning is showing up
here.

So I guess it might be possible to fine-tune the warning to accept this
kind of usage inside \describe. But I think this is a horrible
"convention", and unless this is really widespread that wouldn't be my
first choice.

An alternative to Henrik's suggestion is to just use \itemize instead of
\describe and drop  the first {} after \item.

Best,
-Deepayan



>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] package PloGO2 error on Windows build advice

[Jennifer Wokaty]

Hi Dana,

Hope you had a great holiday. I updated MiKTex and was able to build PloGO2 
manually on palomino4. Let's check the build report tomorrow and see if the 
error is cleared up.

Jennifer Wokaty (they/them)

Waldron Lab at CUNY SPS
Bioconductor Core Team

From: Bioc-devel  on behalf of Dana Pascovici 

Sent: Thursday, November 24, 2022 11:05 PM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] package PloGO2 error on Windows build advice

***ATTENTION: This email came from an external source. Do not open attachments 
or click on links from unknown senders or unexpected emails.***

Hi,

I was wondering if you can offer any advice for fixing a current error for our 
package PloGO2 - it is there only on Windows release build and has not been 
there before.

https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_release_bioc-2DLATEST_PloGO2_palomino4-2Dbuildsrc.html&d=DwICAg&c=mRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY&r=FKSqKXkUOES-D4VQb2jSn9QK7Vz5lE18rLcyn73CPhA&m=XpIJlU-quMrtDr3lXRBshZrZ0oRayN3AUzBSIMqnpFqcm3ghGLwcNxI6rpf8wprZ&s=2EybUrneevAGrVW5eV4990cnYCTrCBnoYqGuJtFBcFU&e=

The first issue seems to be as below:

texify: major issue: So far, you have not checked for updates as a MiKTeX user.

Any advice would be appreciate - and happy Thanksgiving btw, don't expect any 
responses for a while!

Kind regards,
Dana




[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=mRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY&r=FKSqKXkUOES-D4VQb2jSn9QK7Vz5lE18rLcyn73CPhA&m=XpIJlU-quMrtDr3lXRBshZrZ0oRayN3AUzBSIMqnpFqcm3ghGLwcNxI6rpf8wprZ&s=pSfwLfE7rS7WiLJM4psAJAyv-J-38y6vTXk87sW7zsQ&e=

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] S4 Methods Documentation Convention Triggers Warnings

[Michael Lawrence (MICHAFLA) via Bioc-devel]

It may be worth revisiting why we arrived at this convention in the first
place and see whether the Rd system can be enhanced somehow so that we can
achieve the same effect with a more natural syntax.

Michael

On Mon, Nov 28, 2022 at 11:25 AM Deepayan Sarkar 
wrote:

> On Sun, Nov 27, 2022 at 12:30 PM Dario Strbenac via Bioc-devel <
> bioc-devel@r-project.org> wrote:
>
> > Good day,
> >
> > For a long time, it has been a convention to document S4 methods in the
> > format:
> >
> > \section{Displaying}{
> >   In the code snippets below, \code{x} is a GRanges object.
> >   \describe{
> > \item{}{
> >   \code{show(x)}:
> >   Displays the first five and last five elements.
> > }
> >   }
> > }
> >
> > In R Under Development, this is now a warning:
> >
> > * checking Rd files ... WARNING
> > checkRd: (5) GRanges-class.Rd:115-165: \item in \describe must have
> > non-empty label.
> >
>
> > This affects my own package as well as the core Bioconductor packages
> > which I used as inspiration for designing my pacakge documentation seven
> > years ago. What should the new convention be? Or could R developers be
> > convinced to get rid of this check before this prototype is released?
> >
>
> The warning is primarily meant for \items inside \arguments, as in HTML
> output these now have an id that can be used to link to specific arguments.
> The code is shared with \describe, which is why the warning is showing up
> here.
>
> So I guess it might be possible to fine-tune the warning to accept this
> kind of usage inside \describe. But I think this is a horrible
> "convention", and unless this is really widespread that wouldn't be my
> first choice.
>
> An alternative to Henrik's suggestion is to just use \itemize instead of
> \describe and drop  the first {} after \item.
>
> Best,
> -Deepayan
>
>
>
> >
> > --
> > Dario Strbenac
> > University of Sydney
> > Camperdown NSW 2050
> > Australia
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Michael Lawrence
Senior Principal Scientist, Director of Data Science and Statistical
Computing
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

[[alternative HTML version deleted]]

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

[Bioc-devel] Give commit access to new author

[Lambda Moses]

Hi,

I would like to add a new author to the packages Voyager and SFEData, of 
which I'm an original author, and give her git commit access to the 
repos on Bioconductor. Her email is kayla...@caltech.edu


Thanks,

Lambda

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

[Bioc-devel] Give commit access to new author

[Lambda Moses]

Hi,

I would like to add a new author to the packages Voyager and SFEData, of 
which I'm an original author, and give her git commit access to the 
repos on Bioconductor. Her email is kayla...@caltech.edu


Thanks,

Lambda

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