Re: [Bioc-devel] Dependency on devtools in biocLite()

[Martin Morgan]

On 01/17/2017 07:15 AM, Andrzej Oleś wrote:

Thanks Martin!

I see your point - then I suggest that at least the call to
`devtools::install` is guarded by a customized more informative error
massage, something along the lines:

Package 'devtools' missing: please install it (e.g., by a call to
`install.packages('devtools')`) and re-run your biocLite command.


I've updated the error message in 1.25.3; thanks for the suggestion.

Martin




Cheers,
Andrzej

On Sat, Jan 14, 2017 at 9:43 AM, Martin Morgan
>
wrote:

On 01/13/2017 06:29 PM, Andrzej Oleś wrote:

Dear all,

it's great that for some time now `biocLite()` also resolves package
dependencies for GitHub hosted packages. However, as this
functionality
depends on devtools, an attempt to install a GitHub package when
devtools
is not installed results in an error

library(BiocInstaller)
biocLite("aoles/RBioFormats")

BioC_mirror: https://bioconductor.org
Using Bioconductor 3.4 (BiocInstaller 1.24.0), R 3.3.2 (2016-10-31).
Error: package 'devtools' not available: there is no package called
‘devtools’

If this is the case, one would typically need to first install
devtools,
and rerun the biocLite command. I was wondering whether it would
make sense
to modify the behavior such that before attempting to call
`devtools::install` in

https://github.com/Bioconductor-mirror/BiocInstaller/blob/

9965cc72d009bfcae6776a02e5abb94cbd5dd109/R/biocLite.R#L48

first check for devtools availability and try to automatically
install it
if missing (maybe by prompting the user). What do you think?


I'm not a fan of automatic package installation, e.g., because a
user (e.g., me) might have a configuration of library paths that
they are trying to maintain. This leads me down the slippery slope
of not wanting to offer to install a package, either, because again
the offer would be too narrow, some users (again, e.g., me) will
reject it and prefer to have control, and so why not have a standard
work flow -- user fixes package installation to their satisfaction
and tries again -- rather than a conditional work flow.

On the other hand the error message "package 'devtools' not
available: there is no package called 'devtools'" seems to be poorly
worded -- there is a package devtools, and it is available, just not
in the current installation. One could try to provide a better
message, but one would rather the message were improved upstream so
all similar situations were handled the same; at least this way the
user has to learn only once what the message means.

Martin


Cheers,
Andrzej

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org 
mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel




This email message may contain legally privileged and/or
confidential information.  If you are not the intended recipient(s),
or the employee or agent responsible for the delivery of this
message to the intended recipient(s), you are hereby notified that
any disclosure, copying, distribution, or use of this email message
is prohibited.  If you have received this message in error, please
notify the sender immediately by e-mail and delete this email
message from your computer. Thank you.





This email message may contain legally privileged and/or...{{dropped:2}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Code quality and bug reports

[Obenchain, Valerie]

Hi,

On 01/14/2017 03:01 AM, Lluís Revilla wrote:
> Dear Valerie and all,
>
> If I understood the page you kindly linked correctly, a package is deprecated:
> 1) When it fails to build and check (unless it is fixed).
> 2) When the maintainer asks for it.
> 3) If the maintainer is unresponsive (I assume when a mail is not
> delivered) and(/or?) doesn't answers questions about the package (How
> is this tracked? Which is the threshold for unanswered questions, 1
> year? )
We contact maintainers when a package fails on the build system. There
isn't a set rule on the number of times contacted with no response
because there are so many exceptions, e.g., transferred maintainer ship,
away from email due to travel, etc. I'd say the average number of
contacts is 3 before getting the final 2 week notice.

>
> In some packages, it seems the maintainers receive the mails, and the
> packages build and past the daily checks of Bioconductor, but there
> are bugs and issues with those packages that are left unanswered and
> unsolved in support.bioconductor.org. Those packages that are still
> functional and used but don't receive maintenance are then kept ? How
> should the community help to solve those issues?
A primary motivation for implementing badges on the landing pages was to
provide the "maintenance status" you mention below. The badge stats give
an idea of how active the maintainer is (posts, commits, coverage) as
well as the level of use by others (downloads). The 'posts' badge shows
support site activity over that past 6 months in terms of 4 fields:
tagged questions / average answers per question / average comments per
question / accepted answers.

The CorMut package has no tagged questions:

  http://www.bioconductor.org/packages/3.5/bioc/html/CorMut.html

If Guangchuang had asked questions on the support site instead of
posting comments in a gist there would be a number of tagged questions
with no answers. This would give other users some data to go on - an
unresponsive maintainer of a package with no unit tests. In contrast, a
package like edgeR has an average of 1 answer and 3 comments for every
question asked:

  http://www.bioconductor.org/packages/3.5/bioc/html/edgeR.html

We don't have a system in place to remove packages from the repo based
on unanswered questions or bug reports. Ideally the combination of badge
stats and input from others on the support site (i.e., 'what package
would you recommend for ...') is sufficient to get direction on actively
maintained and well-thought-of packages.

If there are suggestions for improving the badges please let us know.
There may also be parts of the package review process that could be
improved such as requiring unit tests instead of suggesting them. But
again, having unit tests does not guarantee that all (or the most
important) aspects of the package are tested.

Valerie

> Thanks,
>
> Lluís
>
> On 6 January 2017 at 18:56, Obenchain, Valerie
>  wrote:
>> On 01/04/2017 07:53 AM, Lluís Revilla wrote:
>>> Dear Guangchuang and all,
>>>
>>> Quality of the packages has been a preoccupation of the project from
>>> the  beginning  (see
>>> https://stat.ethz.ch/pipermail/bioc-devel/2014-May/005810.html for
>>> more references and other discussions about bug reports.) Despite not
>>> being in a goal of the project, it is necessary to do a reproducible
>>> research, which it is a goal: "To further scientific understanding by
>>> producing high-quality documentation and reproducible research.".
>>> Although it seems that this discussion appears periodically
>>> Bioconductor I don't know any solution in the project.
>>>
>>> I have never submitted a package to Bioconductor or CRAN, and I am
>>> quite new to R (and is my first mail to the list), but one thing that
>>> I keep thinking (before publishing a package) is the maintainability
>>> of it. I don't know how much time/desires will I have to dedicate to a
>>> package (if it is accepted) in the future, but at the same time I want
>>> to make useful code to be used in further research beyond my own
>>> project.
>>>
>>> However the Bioconductor core team may be already too busy to deal
>>> with the issues of all packages. Maybe it would be better to bring
>>> CRAN's policy to orphan packages (see:
>>> https://cran.r-project.org/src/contrib/Orphaned/README):
>> Bioconductor does have a system for dealing with orphaned packages
>> called End of Life:
>>
>>   http://www.bioconductor.org/developers/package-end-of-life/
>>
>> Deprecated packages have a strikethrough the name on the build reports,
>> e.g., the saps package,
>>
>>   http://www.bioconductor.org/checkResults/devel/bioc-LATEST/
>>
>>
>> Valerie
>>
>>> "Possible reasons for orphanizing a package:
>>>
>>> 1) The current maintainer actively wants to orphanize the package,
>>>e.g., due to no longer having time or interest to act as package
>>>maintainer.
>>>
>>> 2) Emails sent to the current maintainer by the CRAN admins 

Re: [Bioc-devel] Alternative Hypothesis Specification For edgeR

[Aaron Lun]

Ah - sorry - upon re-reading your message, I realized I misunderstood 
your question. So basically you want to make your LRT p-value one-sided; 
I can see how that would be useful, e.g., when comparing to negative 
controls in ChIP-seq or other technologies.

I've been doing it fairly simply, exploiting the asymptotic independence 
of the test result from the sign of the log-fold change:

is.up <- result$table$logFC > 0
os.p <- result$table$PValue/2
os.p[!is.up] <- 1 - os.p[!is.up]

... which seemed short enough to do manually. I suppose we could add 
this as an option to glmLRT, if it seems useful.

Cheers,

Aaron

On 16/01/17 04:00, Dario Strbenac wrote:
> Good day,
>
> In a future release, could the user be allowed to specify an alternative 
> hypothesis such as the coefficient being positive? DESeq2 provides an 
> altHypothesis parameter for such a purpose.
>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Alternative Hypothesis Specification For edgeR

[Aaron Lun]

Hi Dario,

I guess so - it would be a fairly easy extension of glmLRT - but why? I 
can't think of many situations where a non-zero log-fold change is 
expected under the null hypothesis. Mixture experiments, or correcting 
for gene dosage due to copy number variants, perhaps.

Cheers,

Aaron

On 16/01/17 04:00, Dario Strbenac wrote:
> Good day,
>
> In a future release, could the user be allowed to specify an alternative 
> hypothesis such as the coefficient being positive? DESeq2 provides an 
> altHypothesis parameter for such a purpose.
>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel