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

Thu Sep 24 19:54:04 CEST 2015

Well, I guess, Dan, that basically means that breaking cannot happen
within Bioc (as broken packages do not propagate to the repository) and
such cases are exclusively due to breaking of external dependencies such
as observed with KEGGREST and KEGG (where we can hardly do much about it).

Thus, it remains to clarify on the purpose of the â€šbuildâ€˜ shield as
Wolfgang pointed out.
While it is surely helpful for the developer to grasp what is going on at
a glance, this might be misleading for users and reviewers as described
earlier.

Ludwig

> Am 24.09.2015 um 19:31 schrieb Dan Tenenbaum <dtenenba at fredhutch.org>:
>
>
>
> ----- Original Message -----
>> From: "Andrzej OleÅ›" <andrzej.oles at gmail.com>
>> To: "Dan Tenenbaum" <dtenenba at fredhutch.org>
>> Cc: bioc-devel at r-project.org, "Wolfgang Huber" <whuber at embl.de>
>> Sent: Thursday, September 24, 2015 10:28:14 AM
>> Subject: Re: [Bioc-devel] Shouldn't we distinguish between
package-specific and dependency errors?
>>
>>
>>
>>
>>
>> Hi Dan,
>>
>> thank you for clarifying! I had this impression after looking at
>>
>> http://bioconductor.org/checkResults/devel/bioc-LATEST/flowcatchR/
>> and
>> http://bioconductor.org/checkResults/devel/bioc-LATEST/GenomicInteractions/
>>
>> which both produce errors during R CMD check, nevertheless, these
>> problematic versions are available on the corresponding package
>> landing pages. Probably that's because the package started failing
>> check only sometime after the update...
>>
>
> Yes, that is probably what happened. Also, a maintainer can change a
package without bumping the version number. In this case, even if the
package builds and checks, it will not be propagated since there was no
version bump.
>
> Dan
>
>
>
>> Best,
>> Andrzej
>>
>>
>>
>> On Thu, Sep 24, 2015 at 6:12 PM, Dan Tenenbaum <
>> dtenenba at fredhutch.org > wrote:
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: "Andrzej OleÅ›" < andrzej.oles at gmail.com >
>>> To: "Wolfgang Huber" < whuber at embl.de >
>>> Cc: bioc-devel at r-project.org
>>> Sent: Thursday, September 24, 2015 5:56:20 AM
>>> Subject: Re: [Bioc-devel] Shouldn't we distinguish between
>>> package-specific and dependency errors?
>>>
>>> Hi,
>>>
>>> we need to distinguish here between build/install and check errors.
>>> The
>>> first ones hold the package update (instead, the last working
>>> version
>>> is
>>> used). On the other hand, check errors do not hold the package from
>>> propagating into the repository causing collateral damage (at least
>>> that's
>>> what I observe in the devel branch).
>>>
>>
>> If a package does not pass R CMD check, it does not propagate into
>> the repository.
>>
>> Dan
>>
>>
>>
>>
>>> A good example is EBImage which is currently broken for all
>>> architectures
>>> but Linux (see:
>>> http://bioconductor.org/checkResults/devel/bioc-LATEST/EBImage/ ).
>>> It
>>> doesn't affect it's downstream dependencies because the error
>>> occurs
>>> at
>>> build stage, see for example imageHTS (
>>> http://bioconductor.org/packages/3.2/bioc/html/imageHTS.html ).
>>> Fair
>>> enough,
>>> EBImage has a red badge, whereas imageHTS has a green one.
>>>
>>> So the issue raised by Ludwig occurs only with packages which fail
>>> during
>>> check. Maybe changing the publication policy in such cases, i.e.
>>> hold
>>> the
>>> updated package from going into the repository when it fails 'R CMD
>>> check'
>>> would help to address the problem, at least for BioC packages?
>>>
>>> Best,
>>> Andrzej
>>>
>>> On Thu, Sep 24, 2015 at 2:22 PM, Wolfgang Huber < whuber at embl.de >
>>> wrote:
>>>
>>>> It seems that the â€œbuildâ€ shield on the package landing page
>>>> conflates
>>>> things that happen in the package, and in its dependencies.
>>>> Do we have a clear spec of what the purpose of that shield is?
>>>>
>>>> Something to avoid IMHO is creating incentives for package
>>>> developers to
>>>> reduce dependencies to make their package â€œlook" more robust, at
>>>> the cost
>>>> of duplication or functionality.
>>>>
>>>> Wolfgang
>>>>
>>>>
>>>>> On 24 Sep 2015, at 14:13, Ludwig Geistlinger <
>>>> Ludwig.Geistlinger at bio.ifi.lmu.de > wrote:
>>>>>
>>>>>> Do you have any information on how often this kind of breakage
>>>>>> occurs?
>>>>>
>>>>> Having my package ~1 year in, I would say that happened roughly
>>>>> 5
>>>>> times
>>>> to
>>>>> me.
>>>>>
>>>>> I wonder whether other developers could comment on their
>>>>> experience with
>>>>> that as well.
>>>>>
>>>>>
>>>>>> On Thu, Sep 24, 2015 at 4:35 AM, Ludwig Geistlinger <
>>>>>> Ludwig.Geistlinger at bio.ifi.lmu.de > 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: 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
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Bioc-devel at r-project.org mailing list
>>>>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> Bioc-devel at r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>
>>>> _______________________________________________
>>>> Bioc-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>
>>>
>>> [[alternative HTML version deleted]]
>>
>>
>>>
>>> _______________________________________________
>>> Bioc-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>>
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

-- 
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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: untitled-[2].html
URL: <https://stat.ethz.ch/pipermail/bioc-devel/attachments/20150924/06edbe65/attachment-0001.pl>