Hi,
On Fri, 2018-05-18 at 10:00 -0400, Martin Morgan wrote:
>
> > ...
> > i.e. a package from a given BioC release, or a specific version
> > of a package, regardless from which release it comes.
>
> I guess there are so many ways to shoot oneself in the foot that it
> is a wonder that we still
On 05/18/2018 03:28 AM, Neumann, Steffen wrote:
Hi,
On Wed, 2018-05-09 at 18:11 -0400, Martin Morgan wrote:
...
- version() version of Bioconductor in use
- valid() are all Bioconductor packages from the same
Bioconductor
version?
I'd like to challenge the concept of the release
and
On Fri, May 18, 2018 at 3:28 AM, Neumann, Steffen
wrote:
> Hi,
>
> On Wed, 2018-05-09 at 18:11 -0400, Martin Morgan wrote:
> >
> > ...
> >- version() version of Bioconductor in use
> >- valid() are all Bioconductor packages from the same
> > Bioconductor
> > version?
>
> I'd like to chall
Hi,
On Wed, 2018-05-09 at 18:11 -0400, Martin Morgan wrote:
>
> ...
>- version() version of Bioconductor in use
>- valid() are all Bioconductor packages from the same
> Bioconductor
> version?
I'd like to challenge the concept of the release
and the pretty strong term valid(). I think
On 05/16/2018 10:23 AM, Nicolas Descostes wrote:
Dear Martin,
I am starting using BiocInstaller. Regarding the BiocManager::valid(),
would it be possible to retrieve a list with one element being a vector of
the packages to update? or to run BiocManager() as we do with biocLite()?
Running i
perfect! thanks a lot
2018-05-16 10:32 GMT-04:00 Martin Morgan :
>
>
> On 05/16/2018 10:23 AM, Nicolas Descostes wrote:
>
>> Dear Martin,
>>
>> I am starting using BiocInstaller. Regarding the BiocManager::valid(),
>> would it be possible to retrieve a list with one element being a vector of
>> t
Thanks for the feedback so far. If you're interested in trying out the
new package, please
remotes::install_github("Bioconductor/BiocManager")
and then
BiocManager::install(version = "devel") # or 3.7 or 3.8
The essential functionality is
BiocManager::install()
BiocManager::version()
On 05/11/2018 03:33 AM, Lluís Revilla wrote:
Dear Bioconductor team,
Bioconductor packages can be installed via install.packages when they
are a dependency of another package if there is in the DESCRIPTION file
a "biocViews:" section (see
https://github.com/r-lib/devtools/issues/700#issueco
Good day,
The features of the proposed package seem a lot like BiocInstaller. Once I have
upgraded R and have the newest BiocInstaller installed using the bootstrapping
technique of source("https://bioconductor.org/biocLite.R";), I typically do
library(BiocInstaller)
biocLite("GenomicAlignments
Dear Bioconductor team,
Bioconductor packages can be installed via install.packages when they are a
dependency of another package if there is in the DESCRIPTION file a
"biocViews:" section (see https://github.com/r-lib/devtools/issues/700#
issuecomment-235127291) .
I don't know how install.package
On 05/10/2018 01:37 AM, Pariksheet Nanda wrote:
Hi Henrik,
On Thu, May 10, 2018 at 1:21 AM, Henrik Bengtsson <
henrik.bengts...@gmail.com> wrote:
May I suggest the package name:
* Bioconductor
The potential downside would be possible confusions between the version of
this package versus t
Hi Henrik,
On Thu, May 10, 2018 at 1:21 AM, Henrik Bengtsson <
henrik.bengts...@gmail.com> wrote:
>
>
> May I suggest the package name:
>
> * Bioconductor
>
> The potential downside would be possible confusions between the version of
> this package versus the actual Bioconductor repository. Could
On Thu, May 10, 2018, 00:29 Martin Morgan
wrote:
> Developers --
>
> A preliminary heads-up and request for comments.
>
> Almost since project inception, we've used the commands
>
>source("https://bioconductor.org/biocLite.R";)
>biocLite(pkgs)
>
> to install packages. This poses security
On 05/09/2018 07:05 PM, Aaron Lun wrote:
This all sounds pretty reasonable to me. The ability to choose the
version in install() is nice, especially if we can easily flip between
versions in different install locations. I presume that
version="release" will be the default?
I actually have som
On 05/09/2018 06:39 PM, Ryan Thompson wrote:
Hi Martin,
Is the intent that the BiocManager package should never be loaded via
library, but functions in the package should always be called as
BiocManager::FUN()? If not, I would consider prefixing the functions
with "bioc".
I would rather t
This all sounds pretty reasonable to me. The ability to choose the
version in install() is nice, especially if we can easily flip between
versions in different install locations. I presume that
version="release" will be the default?
As for the names - BiocManager seems the most sober of the lot. A
Hi Martin,
Is the intent that the BiocManager package should never be loaded via
library, but functions in the package should always be called as
BiocManager::FUN()? If not, I would consider prefixing the functions with
"bioc".
Also, I assume that once this BiocManager package is on CRAN, the
bio
17 matches
Mail list logo
