[Bioc-devel] Shouldn't we distinguish between package-specific and dependency errors?

Ludwig Geistlinger Ludwig.Geistlinger at bio.ifi.lmu.de
Thu Sep 24 10:35:47 CEST 2015


Dear Bioc-Team,

I would like to make this point brought up by Weijun more general.
He reported a considerable number of packages to be broken by
(recursively) depending on KEGGREST - which actually broke due to KEGG
itself (however, this seems to be resolved by the current build).

Nevertheless, given that a dependency can break your package at any time,
it is currently hard to device a robust and stable software product even
within the semi-annual release.
Thus, I wonder whether Bioc packages in release (at least those having
other packages depending on them) shouldn't always be rolled back to the
last version that passed build and check without error, in order to ensure
functioning of packages down the hierarchy.

Based on these considerations, I also wonder whether the shield on the
package landing page indicating the result of the package building
(ok/warning/error) shouldn't distinguish between errors caused by
dependencies and errors caused by the package itself.

Imagine the not too unrealistic case of a new Bioc package presented in a
Software article under review.
Without doubt, a reviewer will be negatively influenced by the 'error'
shield indicating that the package has not been properly worked out.
This is fair enough if the package's own code produces these bugs, but the
opposite it true if that is due to a broken dependency.

In the worst case, the package will run fine the whole time the article is
prepared, but breaks due to a broken dependency the day the reviewer
starts to evaluate the manuscript.

I know that this does not resolves problems of dependencies outside of
BioC such as for KEGGREST with KEGG.
But at least for dependencies within BioC, I wonder whether this is a
point worth considering.

Thanks & Best,
Ludwig


-- 
Dipl.-Bioinf. Ludwig Geistlinger

Lehr- und Forschungseinheit für Bioinformatik
Institut für Informatik
Ludwig-Maximilians-Universität München
Amalienstrasse 17, 2. Stock, Büro A201
80333 München

Tel.: 089-2180-4067
eMail: Ludwig.Geistlinger at bio.ifi.lmu.de


> Hi Weijun,
>
> ----- Original Message -----
>> From: "Luo Weijun" <luo_weijun at yahoo.com>
>> To: maintainer at bioconductor.org, dtenenba at fredhutch.org
>> Cc: "Martin Morgan" <mtmorgan at fredhutch.org>, Bioc-devel at r-project.org
>> Sent: Wednesday, September 23, 2015 9:44:13 AM
>> Subject: KEGG REST issue
>>
>> Dear BioC team,
>> I noticed some problem with keggLink() function of KEGGREST package,
>> and it can be traced back to KEGG REST API Linked entries. Some of
>> this API function is broken. For example, the following line used to
>> get all gene-pathway mapping for human, but retrieves nothing now.
>> path.hsa= KEGGREST::keggLink("pathway", "hsa")
>>
>> In fact, these two bulk queries with the rest api don’t work anymore.
>> http://rest.kegg.jp/link/pathway/hsa
>> http://rest.kegg.jp/link/hsa/pathway
>> but smaller queries on Linked entries seem to be fine. not sure
>> whether other REST API functions are affected or not. As a
>> consequence, KEGGREST and many dependent packages had build error.
>> http://bioconductor.org/checkResults/release/bioc-LATEST/KEGGREST/morelia-buildsrc.html
>>
>> anway, just want you know about this, see if you can do anything on
>> this.
>
> Yes, I am aware of this. It's an issue on the KEGG side and I have
> contacted the KEGG team. I have not heard back yet.
>
> Dan
>
>
>> Weijun
>>
>>
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



More information about the Bioc-devel mailing list