Two comments
1) I would not consider a package breaking in level a big deal. This is
why we have devel.
2) Technically, Bioc packages should break extremely rarely in release,
because of the rules regarding committing changes to the release branch.
Unfortunately, there is often a lot of updates i
> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Michael Lawrence
> Sent: Thursday, September 24, 2015 2:51 PM
> To: Ludwig Geistlinger
> Cc: bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Shouldn't we distinguish between package-specifi
I agree with Michael. External dependencies are not avoidable in our field,
but they do put the user in a bad situation with respect to trusting their
software (and performing reproducible analyses).
If I have KEGGREST version x,y,z installed, and it was passing all it's
tests when it was deployed
The important question is whether the package actually works, as
distributed. if not, it's a user matter. If a build is failing because
there is a problem with the "next" version of the package, or something
specific to the build machine, it's a developer/admin matter. I'm guessing
we don't routine
Dan, thanks for clarifying.
With 'we can hardly do much about it', I meant that we cannot prevent that
for external dependencies in the way we can prevent it for dependendencies
within Bioc.
Question remains whether the landing page for the USER of the package is
the right place to alert the DEVEL
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
- Original Message -
> From: "Andrzej Oleś"
> To: "Dan Tenenbaum"
> Cc: bioc-devel@r-project.org, "Wolfgang Huber"
> Sent: Thursday, September 24, 2015 10:28:14 AM
> Subject: Re: [Bioc-devel] Shouldn't we distinguish between package-specific
> and dependency errors?
>
>
>
>
>
> H
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
problemati
- Original Message -
> From: "Andrzej Oleś"
> To: "Wolfgang Huber"
> Cc: bioc-devel@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
It would be good to know how these dependency breakages actually arise. Is
it the case that the culprit usually fails check (with a warning or
error?). It could just be a bug that gets by the tests in the dependency.
Those would be virtually impossible for the build system to figure out.
This unde
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
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 t
> 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 <
On Thu, Sep 24, 2015 at 4:35 AM, Ludwig Geistlinger <
ludwig.geistlin...@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 act
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, g
15 matches
Mail list logo
