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
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
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
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
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
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
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