[Bioc-devel] bioc pkgs depending on packages that are only in github?

[Michael Lawrence]

On Sat, Nov 8, 2014 at 12:22 PM, Martin Morgan <mtmorgan at fredhutch.org>
wrote:

> On 11/08/2014 08:53 AM, Michael Lawrence wrote:
>
>> On Sat, Nov 8, 2014 at 8:01 AM, Vincent Carey <stvjc at channing.harvard.edu
>> >
>> wrote:
>>
>>  our guidelines state
>>>
>>> Packages you depend on must be available via Bioconductor or CRAN; users
>>> and the automated build system have no way to install packages from other
>>> sources.
>>>
>>> with increased utility of devtools/install_github perhaps we can relax
>>> this?
>>>
>>> is it a can of worms we don't want to open?
>>>
>>>
>>>  Gabe Becker is finishing up a framework that generalizes the notion of
>> package repositories such that packages can be distributed over multiple
>> sources, including traditional repositories and SCM systems like Github.
>> If
>> Bioconductor were to maintain a manifest, then our generalized
>> installation
>>
>
> Probably you mean a manifest in a different sense, but in case not I'll
> mention
>
>   https://hedgehog.fhcrc.org/bioconductor/trunk/madman/
> Rpacks/bioc_3.1.manifest
>
> and friends.
>
>
Gabe's manifest is a list of packages, but it also points to package
locations and, optionally, versions.


>  machinery would be able to install everything in a dependency-aware manner
>> (install_github can only resolve dependencies located in repositories).
>>
>
>
> Managing dependencies seems like an important and necessary advance, but I
> don't think sufficient for Bioc purposes? E.g., both CRAN and Bioconductor
> at some level take control of package sources, so the source is available
> even after the developer has (usually casually) lost interest in the useful
> resource they are providing. Likewise the 'quality assurance' provided by
> build and check (on change for CRAN, nightly for Bioc) across platforms and
> against current versions, and the manual maintenance activities of both the
> CRAN and Bioc teams (e.g., identifying the root cause of problems exhibited
> by package A as a change or deficiency in package B).
>
>
There is a tension between the desire for validation and the pace of
science. Our goal is to enable the user to choose his or her comfort zone.
Gabe's switchr/GRAN framework makes it relatively easy to deploy a manifest
as a traditional, validated repository. It will even pull from github or
other SCM with each build (I think it just checks for a version bump, but
that might be configurable). Of course, this means the user has the skills
and resources necessary to deploy such a repository. The Bioconductor
project certainly would though, so some sort of validated approach would
definitely be preferable.



> Certainly it will be interesting to see Gabe's mature product.
>
> Martin
>
>
>  BiocInstaller could wrap it. The manifest system is a prototype for
>> something that could end up in R itself.
>>
>>
>>           [[alternative HTML version deleted]]
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
>

	[[alternative HTML version deleted]]