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

[Gabe Becker]

Hey all,

A package manifest is essentially a decentralized PACKAGES file (this is
what defines what is in a package repository, for those who don't know). As
Michael pointed out, manifests can point to remote or local files (e.g.
those in an actual repository or the CRAN Archive), but it also understands
SCM systems (currently Git and SVN) and can point directly to those sources.

Note that the only thing necessary for a manifest to define a validated,
guarantee-providing cohort of packages is for it to point to a set of
packages which define such a cohort. If, after completion of Bioc's build
and testing process, a package manifest were generated and published to the
Web, packages installed using that manifest would provide all the same
guarantees that those from the Bioc repositories do now.

Finally, Martin, I didn't know about the Bioc manifests. Thanks for the
heads up on that.

~G


On Sun, Nov 9, 2014 at 4:35 PM, Michael Lawrence <lawrence.michael at gene.com>
wrote:

> 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]]
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
Computational Biologist
Genentech Research

	[[alternative HTML version deleted]]