On Thu, Sep 24, 2015 at 4:35 AM, Ludwig Geistlinger < [email protected]> wrote:
> 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. > Do you have any information on how often this kind of breakage occurs? > 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. > > Recent developments at the Volkswagen company should help raise general awareness that software development and maintenance is a fraught process. If software S depends on software T and T is unreliable then so is S. The negative influence of events of the sort you describe has potential value. I believe there are ways of using containers so that software can be distributed in a verified working state, perhaps suitable for a fully predictable review, but I doubt this is a real solution to the actual problem. > 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: [email protected] > > > > Hi Weijun, > > > > ----- Original Message ----- > >> From: "Luo Weijun" <[email protected]> > >> To: [email protected], [email protected] > >> Cc: "Martin Morgan" <[email protected]>, [email protected] > >> 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 > >> > >> > > > > _______________________________________________ > > [email protected] mailing list > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > > _______________________________________________ > [email protected] mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] _______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
