Re: [Bioc-devel] Distinction between release and devel package websites
On 07/22/2014 06:17 PM, Vincent Carey wrote: On Tue, Jul 22, 2014 at 7:10 PM, Andrzej OleÅ› wrote: Hi Dan, Michael, Julian, Thank's for keeping the links to the tarballs! I don't argue that mixing release and devel is a good idea in general. Rather, that for some users this might be the best compromise between the following two objectives: 1. a stable working environment 2. the possibility to use or just quickly check a specific new feature available in the devel version of package X IMHO this is the road to ruin. Switching entirely to devel is quite often a no-no for them because of the unstable nature of the devel branch. And maintaining both release I personally have never done the homework required to have both branches on hand with convenient updating. It is surely feasible and I would imagine a number of folks reading this have done it for themselves. It is probably not trivial to do it portably but a doc with suggestions for key platforms would be a nice contribution. I used to have Rrel and Rdev scripts that made it work and that is easily worked out but it is not very elegant and transitioning to new releases of R is laborious. FWIW one approach _is_ (well ok, sufficiently obscure to be not) documented at http://bioconductor.org/developers/how-to/useDevel/ but it is commented out so only appears in the source version of the page; apparently it was more confusing than helpful, and the approach changes depending on whether Bioc devel is on R devel or not. Martin and devel only adds to their frustration. As a developer I would like to have the freedom to advise people on using the latest devel version of my package regardless of whether they are running release or devel if I think that this is safe for them, which is typically the case for many upstream packages without (many) reverse dependencies. I don't see the point of unnecessary obstructing this approach and I'm not sure I understand why there is such an outrage about mixing release and devel. In contrary, quite often this can be much safer than Depends on your definition of safety. I think that we have gained much from the clean separation, in terms of user support effort and freedom to experiment in devel. "Experts" can do what they like and deal with the consequences themselves, but the general approach to the user community should be principled and it should be: 1) in general, use release branch and report bugs and see that they are fixed in a timely way; if they are not, let the core know -- 2) if you expect help, do all package installations via biocLite() -- 3) we like seeing mileage on the devel branch and encourage its use for novel features, but it needs to be used with the appropriate version of R and the devel package set. switching between BioC branches. I personally do not want to find myself in a position when I advice a user to switch to BioC devel because of some new function from my package he/she would like to give This is an engineering commitment to a stable release branch. No new features, only bug fixes. We have benefited from this immensely. a try only to learn that this broke his/hers scripts (due to the changes in some other packages). To sum up, I believe that mixing release and devel might be beneficial in some specific cases similar to the above described one and it's important that the infrastructure allows leveraging this approach, e.g. by providing direct access to devel tarballs. Cheers, Andrzej On Tue, Jul 22, 2014 at 11:12 PM, Julian Gehring wrote: Hi Andzrej, thank you, I see your point but I'm afraid I must disagree with you. I've had this situation numerous times that I have added/fixed something in the devel branch of a package and had to advice the users to use this latest version. Needless to say, they were typically using the release branch, and it was a relatively painless procedure for them to pick the tarball from the devel landing page and proceed with manual installation. Of course, this could be also achieved by installing from the svn, however, this is not very welcome from the user's perspective. I'm not sure I understand to need to mix devel and release. If there is a bug in the release branch, it should be also patched there. And if users need the features of the devel branch, they would have to switch to devel anyway. Best Julian ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] ___ Bioc-devel@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 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch
Re: [Bioc-devel] Distinction between release and devel package websites
On Tue, Jul 22, 2014 at 7:10 PM, Andrzej OleÅ wrote: > Hi Dan, Michael, Julian, > > Thank's for keeping the links to the tarballs! > > I don't argue that mixing release and devel is a good idea in general. > Rather, that for some users this might be the best compromise between > the following two objectives: > 1. a stable working environment > 2. the possibility to use or just quickly check a specific new feature > available in the devel version of package X > > IMHO this is the road to ruin. > Switching entirely to devel is quite often a no-no for them because of > the unstable nature of the devel branch. And maintaining both release > I personally have never done the homework required to have both branches on hand with convenient updating. It is surely feasible and I would imagine a number of folks reading this have done it for themselves. It is probably not trivial to do it portably but a doc with suggestions for key platforms would be a nice contribution. I used to have Rrel and Rdev scripts that made it work and that is easily worked out but it is not very elegant and transitioning to new releases of R is laborious. > and devel only adds to their frustration. As a developer I would like > to have the freedom to advise people on using the latest devel version > of my package regardless of whether they are running release or devel > if I think that this is safe for them, which is typically the case for > many upstream packages without (many) reverse dependencies. I don't > see the point of unnecessary obstructing this approach and I'm not > sure I understand why there is such an outrage about mixing release > and devel. In contrary, quite often this can be much safer than > Depends on your definition of safety. I think that we have gained much from the clean separation, in terms of user support effort and freedom to experiment in devel. "Experts" can do what they like and deal with the consequences themselves, but the general approach to the user community should be principled and it should be: 1) in general, use release branch and report bugs and see that they are fixed in a timely way; if they are not, let the core know -- 2) if you expect help, do all package installations via biocLite() -- 3) we like seeing mileage on the devel branch and encourage its use for novel features, but it needs to be used with the appropriate version of R and the devel package set. > switching between BioC branches. I personally do not want to find > myself in a position when I advice a user to switch to BioC devel > because of some new function from my package he/she would like to give > This is an engineering commitment to a stable release branch. No new features, only bug fixes. We have benefited from this immensely. > a try only to learn that this broke his/hers scripts (due to the > changes in some other packages). > > To sum up, I believe that mixing release and devel might be beneficial > in some specific cases similar to the above described one and it's > important that the infrastructure allows leveraging this approach, > e.g. by providing direct access to devel tarballs. > > Cheers, > Andrzej > > > On Tue, Jul 22, 2014 at 11:12 PM, Julian Gehring > wrote: > > Hi Andzrej, > > > > thank you, I see your point but I'm afraid I must disagree with you. > > I've had this situation numerous times that I have added/fixed > > something in the devel branch of a package and had to advice the users > > to use this latest version. Needless to say, they were typically using > > the release branch, and it was a relatively painless procedure for > > them to pick the tarball from the devel landing page and proceed with > > manual installation. Of course, this could be also achieved by > > installing from the svn, however, this is not very welcome from the > > user's perspective. > > > > > > I'm not sure I understand to need to mix devel and release. If there is > a > > bug in the release branch, it should be also patched there. And if users > > need the features of the devel branch, they would have to switch to devel > > anyway. > > > > > > Best > > Julian > > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] NAMESPACE problem in MacOS with VariantFiltering
On 7/22/2014 4:27 PM, Robert Castelo wrote:
hi Dan,
I re-installed R, getting the newer 3.1.1 over the 3.1.0 I had but did not make
a difference because I had the devel packages into a specific devel folder which
was still available to the installation. However, when I removed it and made a
completely new fresh installation of VariantFiltering and its dependencies then
it worked, so problem solved! thanks for the hint!!
Comparing your sessionInfo() with Dan's I would have guessed that the error
occurred when trying to load VariantAnnotation, probably because your
VariantAnnotation was out of date. Hopefully
BiocInstaller::biocValid()
would have diagnosed this.
Martin
robert.
On 7/22/14 9:11 PM, Dan Tenenbaum wrote:
Hi Robert,
I just installed VariantFiltering on my system (using the Snow Leopard build
of R) and had no trouble loading it.
Here's my sessionInfo():
R version 3.1.1 (2014-07-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] parallel stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] VariantFiltering_1.1.9 BiocGenerics_0.11.3 BiocContributions_0.99.0
[4] BiocInstaller_1.15.5
loaded via a namespace (and not attached):
[1] AnnotationDbi_1.27.8 BatchJobs_1.3
[3] BBmisc_1.7 Biobase_2.25.0
[5] BiocParallel_0.7.7 biomaRt_2.21.1
[7] Biostrings_2.33.13 bitops_1.0-6
[9] brew_1.0-6 BSgenome_1.33.8
[11] BSgenome.Hsapiens.UCSC.hg19_1.3.99 caTools_1.17
[13] checkmate_1.1 codetools_0.2-8
[15] DBI_0.2-7 digest_0.6.4
[17] fail_1.2 foreach_1.4.2
[19] GenomeInfoDb_1.1.13GenomicAlignments_1.1.22
[21] GenomicFeatures_1.17.12GenomicRanges_1.17.26
[23] htmltools_0.2.4httpuv_1.3.0
[25] IRanges_1.99.23iterators_1.0.7
[27] Rcpp_0.11.2RCurl_1.95-4.1
[29] RJSONIO_1.2-0.2Rsamtools_1.17.31
[31] RSQLite_0.11.4 rtracklayer_1.25.13
[33] S4Vectors_0.1.2sendmailR_1.1-2
[35] shiny_0.10.0 stats4_3.1.1
[37] stringr_0.6.2 tools_3.1.1
[39] VariantAnnotation_1.11.16 XML_3.98-1.1
[41] xtable_1.7-3 XVector_0.5.7
[43] zlibbioc_1.11.1
Maybe try with a fresh install of R? Or try reinstalling everything that's
outdated with biocLite()?
Dan
- Original Message -
From: "Robert Castelo"
To: bioc-devel@r-project.org
Sent: Tuesday, July 22, 2014 11:25:51 AM
Subject: [Bioc-devel] NAMESPACE problem in MacOS with VariantFiltering
hi,
after updating to the last devel version of all packages I cannot
load
one of the packages I develop, VariantFiltering, in MacOS (Snow
Leopard)
while the same version loads smoothly in LInux.
This is the error I get:
library(VariantFiltering)
No methods found in "IRanges" for requests: Rle, substring, ifelse,
as.factor
Error : object ‘runValue’ is not exported by 'namespace:IRanges'
Error: package or namespace load failed for ‘VariantFiltering’
You will find the sessionInfo() at the end of the email, the package
version is the very last one as I can see from the installed package
description:
packageDescription("VariantFiltering")$Version
[1] "1.1.9"
which, as I said, loads without any trouble in my linux box. This
last
version 1.1.9 does not attempt to import the failed requests from
IRanges and in fact the check report at
http://www.bioconductor.org/checkResults/3.0/bioc-LATEST/VariantFiltering/perceval-checksrc.html
does not show any problem either. So I guess this problem may be
specific of my Mac OS Snow Leopard installation and I'm really
puzzled,
any hint will be highly appreciated.
thank you!
robert.
ps: sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] parallel stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] BiocGenerics_0.11.3 vimcom_0.9-93 setwidth_1.0-3
[4] colorout_1.0-2
loaded via a namespace (and not attached):
[1] AnnotationDbi_1.27.8 BatchJobs_1.3
[3] BBmisc_1.7 Biobase_2.25.0
[5] BiocParallel_0.7.7 biomaRt_2.21.1
[7] Biostrings_2.33.13 bitops_1.0-6
[9] brew_1.0-6 BSgenome_1.33.8
[11] BSgenome.Hsapiens.UCSC.hg19_1.3.99 caTools_1.17
[13] checkmate_1.1 codetools_0.2-8
[15] DBI_0.2-7 digest_0.6.4
[17] fail_1.2 foreach_1.4.2
[19] GenomeInfoDb_1.1.13 GenomicAlignments_1.1.22
[21] GenomicFeatures_1.17.12 GenomicRanges_1.17.26
[23] htmltools_0.2.4 httpuv_1.3.0
[25] IRanges_1.99.23 iterators_1.0.7
[27] Rcpp_0.11.2 RCurl_1.95-4.1
[29] RJSONIO_1.2-0.2 Rsamtools_1.17.31
[31] RSQLite_0.11.4 rtracklayer_1.25.13
[33] S4Vectors_0.1.2 sendmailR_1
Re: [Bioc-devel] NAMESPACE problem in MacOS with VariantFiltering
hi Dan,
I re-installed R, getting the newer 3.1.1 over the 3.1.0 I had but did
not make a difference because I had the devel packages into a specific
devel folder which was still available to the installation. However,
when I removed it and made a completely new fresh installation of
VariantFiltering and its dependencies then it worked, so problem solved!
thanks for the hint!!
robert.
On 7/22/14 9:11 PM, Dan Tenenbaum wrote:
Hi Robert,
I just installed VariantFiltering on my system (using the Snow Leopard build of
R) and had no trouble loading it.
Here's my sessionInfo():
R version 3.1.1 (2014-07-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] parallel stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] VariantFiltering_1.1.9 BiocGenerics_0.11.3 BiocContributions_0.99.0
[4] BiocInstaller_1.15.5
loaded via a namespace (and not attached):
[1] AnnotationDbi_1.27.8 BatchJobs_1.3
[3] BBmisc_1.7 Biobase_2.25.0
[5] BiocParallel_0.7.7 biomaRt_2.21.1
[7] Biostrings_2.33.13 bitops_1.0-6
[9] brew_1.0-6 BSgenome_1.33.8
[11] BSgenome.Hsapiens.UCSC.hg19_1.3.99 caTools_1.17
[13] checkmate_1.1 codetools_0.2-8
[15] DBI_0.2-7 digest_0.6.4
[17] fail_1.2 foreach_1.4.2
[19] GenomeInfoDb_1.1.13GenomicAlignments_1.1.22
[21] GenomicFeatures_1.17.12GenomicRanges_1.17.26
[23] htmltools_0.2.4httpuv_1.3.0
[25] IRanges_1.99.23iterators_1.0.7
[27] Rcpp_0.11.2RCurl_1.95-4.1
[29] RJSONIO_1.2-0.2Rsamtools_1.17.31
[31] RSQLite_0.11.4 rtracklayer_1.25.13
[33] S4Vectors_0.1.2sendmailR_1.1-2
[35] shiny_0.10.0 stats4_3.1.1
[37] stringr_0.6.2 tools_3.1.1
[39] VariantAnnotation_1.11.16 XML_3.98-1.1
[41] xtable_1.7-3 XVector_0.5.7
[43] zlibbioc_1.11.1
Maybe try with a fresh install of R? Or try reinstalling everything that's
outdated with biocLite()?
Dan
- Original Message -
From: "Robert Castelo"
To: bioc-devel@r-project.org
Sent: Tuesday, July 22, 2014 11:25:51 AM
Subject: [Bioc-devel] NAMESPACE problem in MacOS with VariantFiltering
hi,
after updating to the last devel version of all packages I cannot
load
one of the packages I develop, VariantFiltering, in MacOS (Snow
Leopard)
while the same version loads smoothly in LInux.
This is the error I get:
library(VariantFiltering)
No methods found in "IRanges" for requests: Rle, substring, ifelse,
as.factor
Error : object ‘runValue’ is not exported by 'namespace:IRanges'
Error: package or namespace load failed for ‘VariantFiltering’
You will find the sessionInfo() at the end of the email, the package
version is the very last one as I can see from the installed package
description:
packageDescription("VariantFiltering")$Version
[1] "1.1.9"
which, as I said, loads without any trouble in my linux box. This
last
version 1.1.9 does not attempt to import the failed requests from
IRanges and in fact the check report at
http://www.bioconductor.org/checkResults/3.0/bioc-LATEST/VariantFiltering/perceval-checksrc.html
does not show any problem either. So I guess this problem may be
specific of my Mac OS Snow Leopard installation and I'm really
puzzled,
any hint will be highly appreciated.
thank you!
robert.
ps: sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] parallel stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] BiocGenerics_0.11.3 vimcom_0.9-93 setwidth_1.0-3
[4] colorout_1.0-2
loaded via a namespace (and not attached):
[1] AnnotationDbi_1.27.8 BatchJobs_1.3
[3] BBmisc_1.7 Biobase_2.25.0
[5] BiocParallel_0.7.7 biomaRt_2.21.1
[7] Biostrings_2.33.13 bitops_1.0-6
[9] brew_1.0-6 BSgenome_1.33.8
[11] BSgenome.Hsapiens.UCSC.hg19_1.3.99 caTools_1.17
[13] checkmate_1.1 codetools_0.2-8
[15] DBI_0.2-7 digest_0.6.4
[17] fail_1.2 foreach_1.4.2
[19] GenomeInfoDb_1.1.13 GenomicAlignments_1.1.22
[21] GenomicFeatures_1.17.12 GenomicRanges_1.17.26
[23] htmltools_0.2.4 httpuv_1.3.0
[25] IRanges_1.99.23 iterators_1.0.7
[27] Rcpp_0.11.2 RCurl_1.95-4.1
[29] RJSONIO_1.2-0.2 Rsamtools_1.17.31
[31] RSQLite_0.11.4 rtracklayer_1.25.13
[33] S4Vectors_0.1.2 sendmailR_1.1-2
[35] shiny_0.10.0 stats4_3.1.0
[37] stringr_0.6.2 tools_3.1.0
[39] XML_3.98-1.1 xtable_1.7-3
[41] XVector_0.5.7 zlibbioc_1.11.1
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
__
Re: [Bioc-devel] Distinction between release and devel package websites
Hi Dan, Michael, Julian, Thank's for keeping the links to the tarballs! I don't argue that mixing release and devel is a good idea in general. Rather, that for some users this might be the best compromise between the following two objectives: 1. a stable working environment 2. the possibility to use or just quickly check a specific new feature available in the devel version of package X Switching entirely to devel is quite often a no-no for them because of the unstable nature of the devel branch. And maintaining both release and devel only adds to their frustration. As a developer I would like to have the freedom to advise people on using the latest devel version of my package regardless of whether they are running release or devel if I think that this is safe for them, which is typically the case for many upstream packages without (many) reverse dependencies. I don't see the point of unnecessary obstructing this approach and I'm not sure I understand why there is such an outrage about mixing release and devel. In contrary, quite often this can be much safer than switching between BioC branches. I personally do not want to find myself in a position when I advice a user to switch to BioC devel because of some new function from my package he/she would like to give a try only to learn that this broke his/hers scripts (due to the changes in some other packages). To sum up, I believe that mixing release and devel might be beneficial in some specific cases similar to the above described one and it's important that the infrastructure allows leveraging this approach, e.g. by providing direct access to devel tarballs. Cheers, Andrzej On Tue, Jul 22, 2014 at 11:12 PM, Julian Gehring wrote: > Hi Andzrej, > > thank you, I see your point but I'm afraid I must disagree with you. > I've had this situation numerous times that I have added/fixed > something in the devel branch of a package and had to advice the users > to use this latest version. Needless to say, they were typically using > the release branch, and it was a relatively painless procedure for > them to pick the tarball from the devel landing page and proceed with > manual installation. Of course, this could be also achieved by > installing from the svn, however, this is not very welcome from the > user's perspective. > > > I'm not sure I understand to need to mix devel and release. If there is a > bug in the release branch, it should be also patched there. And if users > need the features of the devel branch, they would have to switch to devel > anyway. > > > Best > Julian ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Distinction between release and devel package websites
Hi Martin, thank you! On Tue, Jul 22, 2014 at 9:01 PM, Martin Morgan wrote: > We might tell google not to index devel packages (but then packages added > during a particular release cycle aren't indexed until the next release). This adds to the complexity and I'm not sure how hard this would be to implement, but maybe for the packages which didn't make it to the release yet we could allow to index the devel landing pages? Any plans on addressing the distinction between release/devel in the output from the search engine on the BioC website? Best, Andrzej ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Distinction between release and devel package websites
Hi Hervé, thank you for the demo! Yes, this is definitely much more clear than just a different color. Maybe we could first implement this idea on the build/check report websites and see how the uptake will be? I always keep getting confused by the colors which keep changing with every release cycle anyway... Cheers, Andrzej On Tue, Jul 22, 2014 at 10:04 PM, Hervé Pagès wrote: > Hi Andrzej, > > > On 07/22/2014 10:14 AM, Andrzej Oleś wrote: >> >> Hi all, >> >> I think having links is useful, e.g. for someone who uses BioC release >> but wants to install by hand a particular package from the devel >> branch. >> >> Distinct colors between release and devel make sense only if one >> understands their meaning, which in the end might prove not to be very >> useful. > > > I was thinking of something like this: > > http://www.bioconductor.org/checkResults/3.0/data-experiment-LATEST/ > > Just a demo. This will be reset to the usual background tomorrow. > > Cheers, > H. > > >> I would rather recommend emphasizing the distinction between >> release and devel in clear text across the package landing page, >> possibly in multiple places, e.g. somewhere close to the actual >> package version number; for instance, add the word "devel" after the >> version number with a tooltip which will give some explanation/warning >> that this is not the stable release version. >> >> The concept of a notification box is far from ideal because it tends >> to be annoing to the user and once dismissed 'forever' the user won't >> be warned in the future. >> >> I think that the actual problem arises from the fact that the release >> landing pages are not clearly prioritized over the devel ones. Maybe >> this could be addressed by preventing the devel pages from being >> harvested by google? It could make also sense to emphasize (bold face, >> color, ...) the package release landing page on the result list >> returned by the search engine on the BioC website. Currently, the >> results for release and devel differ only in their relative path, >> which can be easily overlooked, and both say " Home", see >> example below: >> >> Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html >>Bioconductor - DESeq2 Home >> Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html >>Bioconductor - DESeq2 Home >> >> >> Cheers, >> Andrzej >> >> On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald >> wrote: >>> >>> Given that we have an ongoing problem with people inadvisedly clicking >>> and >>> installing things, is there a good rationale for allowing them to do so? >>> >>> Perhaps the landing page for each package should be stripped of links and >>> replaced with some indication of the availability for each package on the >>> various operating systems. There could also be a note indicating that >>> people >>> can install using biocLite(). >>> >>> Best, >>> >>> Jim >>> >>> >>> >>> >>> On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: Seems like there are two problems, first that the release and devel pages look similar, but more importantly that people are downloading and installing from the package pages when they should be using biocLite(). I am open to the suggestions for making the release/devel pages look more different from each other, but I think something needs to be done about the second problem as well. Perhaps a popup that comes up when you click on a package tarball saying "The best way to install this is with biocLite(); are you sure you want to download it?" Whatever we do probably won't happen until after BioC2014. Dan - Original Message - > > > From: "Julian Gehring" > To: "Hervé Pagès" , "Michael Lawrence" > , "Vincent Carey" > > Cc: bioc-devel@r-project.org > Sent: Tuesday, July 22, 2014 8:07:29 AM > Subject: Re: [Bioc-devel] Distinction between release and devel package > websites > > Hi, > > Tooltips that appear while hovering over selected links are easy to > miss. This alone will likely not be clear enough. We should convey > the > information that the entire website presents a different version of > the > package. > > The idea of a notification box that can be made visible by the > individual user seems tempting. One can combine this with an > optional > cookie, to remember the state between browser sessions. > > Changing the layout of the devel page itself will also be helpful to > make the distinction more pronounced. Hopefully we could approach > this > in a way that maintains the nice design of the bioc website. > > Best > Julian > > > On 21.07.2014 21:50, Hervé Pagès wrote: >> >> >> Hi, >> >> In addition to these suggestions, how about using a special >> background >> color for package landing pages
Re: [Bioc-devel] Distinction between release and devel package websites
Hi Andzrej, thank you, I see your point but I'm afraid I must disagree with you. I've had this situation numerous times that I have added/fixed something in the devel branch of a package and had to advice the users to use this latest version. Needless to say, they were typically using the release branch, and it was a relatively painless procedure for them to pick the tarball from the devel landing page and proceed with manual installation. Of course, this could be also achieved by installing from the svn, however, this is not very welcome from the user's perspective. I'm not sure I understand to need to mix devel and release. If there is a bug in the release branch, it should be also patched there. And if users need the features of the devel branch, they would have to switch to devel anyway. BestJulian [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Distinction between release and devel package websites
While mixing release and devel may work in specific cases, enabling it in the specific case means also enabling it in general. And in general, it will break and cause frustration and hardship for both users and developers. The other way to access source code is through R itself. On Tue, Jul 22, 2014 at 2:06 PM, Andrzej OleÅ wrote: > Dear Dan, James, Michael, Matt, > > thank you, I see your point but I'm afraid I must disagree with you. > I've had this situation numerous times that I have added/fixed > something in the devel branch of a package and had to advice the users > to use this latest version. Needless to say, they were typically using > the release branch, and it was a relatively painless procedure for > them to pick the tarball from the devel landing page and proceed with > manual installation. Of course, this could be also achieved by > installing from the svn, however, this is not very welcome from the > user's perspective. > > Please correct me if I'm wrong, but to my knowledge there is no > build-in mechanism in 'biocLite' facilitating the above described > scenario. Therefore, I think that it could be useful to have an > 'useDevel' argument to biocLite() allowing for the installation of a > specific package(s) from the devel rather than from the release branch > without having to switch to devel completely. As this would be an > optional argument defaulting to FALSE I wouldn't be worried by > potential abuse, at least not more than by having the devel packages > exposed on the website. As an additional precaution measure we could > issue a warning and ask the user to confirm that (s)he is aware of the > risks and wants to proceed. > > As Matt pointed out, direct links to "package source" tarballs are > very useful for quick and lightweight inspection of package code. This > approach combined with opening the files directly with an archive > browser is particularly appealing, as it saves one from dealing with > manual svn checkout and the cleanup afterwards. Please note that > replacing the prebuild tarball with a link to the SVN has the caveat > of getting potantially broken code. Tarballs which make it through to > the website guarantee that the package at least builds. > > Best, > Andrzej > > On Tue, Jul 22, 2014 at 7:57 PM, Dan Tenenbaum wrote: > > > > > > - Original Message - > >> From: "James W. MacDonald" > >> To: "Andrzej OleÅ" > >> Cc: "Dan Tenenbaum" , "Julian Gehring" < > julian.gehr...@embl.de>, "Michael Lawrence" > >> , bioc-devel@r-project.org > >> Sent: Tuesday, July 22, 2014 10:51:35 AM > >> Subject: Re: [Bioc-devel] Distinction between release and devel package > websites > >> > >> Hi Andrzej, > >> > >> On 7/22/2014 1:14 PM, Andrzej OleÅ wrote: > >> > Hi all, > >> > > >> > I think having links is useful, e.g. for someone who uses BioC > >> > release > >> > but wants to install by hand a particular package from the devel > >> > branch. > >> > >> I'm not sure I think this is a compelling reason for keeping the > >> links. > >> If someone is sophisticated enough to install a devel version of a > >> package into their release install, then surely they are > >> sophisticated > >> enough to get it from svn? > >> > > > > Or to know how to find the link to the tarball. > > > > Dan > > > > > >> It has always struck me as odd that we try time and again to get > >> people > >> to use biocLite() to install packages, yet make it so easy for people > >> to > >> ignore this advice. > >> > >> Best, > >> > >> Jim > >> > >> > >> > >> > >> > > >> > Distinct colors between release and devel make sense only if one > >> > understands their meaning, which in the end might prove not to be > >> > very > >> > useful. I would rather recommend emphasizing the distinction > >> > between > >> > release and devel in clear text across the package landing page, > >> > possibly in multiple places, e.g. somewhere close to the actual > >> > package version number; for instance, add the word "devel" after > >> > the > >> > version number with a tooltip which will give some > >> > explanation/warning > >> > that this is not the stable release version. > >> > > >> > The concept of a notification box is far from ideal because it > >> > tends > >> > to be annoing to the user and once dismissed 'forever' the user > >> > won't > >> > be warned in the future. > >> > > >> > I think that the actual problem arises from the fact that the > >> > release > >> > landing pages are not clearly prioritized over the devel ones. > >> > Maybe > >> > this could be addressed by preventing the devel pages from being > >> > harvested by google? It could make also sense to emphasize (bold > >> > face, > >> > color, ...) the package release landing page on the result list > >> > returned by the search engine on the BioC website. Currently, the > >> > results for release and devel differ only in their relative path, > >> > which can be easily overlooked, and both say " Home", see > >> > example below: > >> > > >> > Bioc
Re: [Bioc-devel] Distinction between release and devel package websites
Andrzej, If you have the an important enough bugfix the correct procedure is to commit it to the release branch. Then users would simply update the package via biocLite. Note that this should be fixes ONLY. No new features. Regardless of how much the users want them, those belong in dev. ~G On Tue, Jul 22, 2014 at 2:06 PM, Andrzej OleÅ wrote: > Dear Dan, James, Michael, Matt, > > thank you, I see your point but I'm afraid I must disagree with you. > I've had this situation numerous times that I have added/fixed > something in the devel branch of a package and had to advice the users > to use this latest version. Needless to say, they were typically using > the release branch, and it was a relatively painless procedure for > them to pick the tarball from the devel landing page and proceed with > manual installation. Of course, this could be also achieved by > installing from the svn, however, this is not very welcome from the > user's perspective. > > Please correct me if I'm wrong, but to my knowledge there is no > build-in mechanism in 'biocLite' facilitating the above described > scenario. Therefore, I think that it could be useful to have an > 'useDevel' argument to biocLite() allowing for the installation of a > specific package(s) from the devel rather than from the release branch > without having to switch to devel completely. As this would be an > optional argument defaulting to FALSE I wouldn't be worried by > potential abuse, at least not more than by having the devel packages > exposed on the website. As an additional precaution measure we could > issue a warning and ask the user to confirm that (s)he is aware of the > risks and wants to proceed. > > As Matt pointed out, direct links to "package source" tarballs are > very useful for quick and lightweight inspection of package code. This > approach combined with opening the files directly with an archive > browser is particularly appealing, as it saves one from dealing with > manual svn checkout and the cleanup afterwards. Please note that > replacing the prebuild tarball with a link to the SVN has the caveat > of getting potantially broken code. Tarballs which make it through to > the website guarantee that the package at least builds. > > Best, > Andrzej > > On Tue, Jul 22, 2014 at 7:57 PM, Dan Tenenbaum wrote: > > > > > > - Original Message - > >> From: "James W. MacDonald" > >> To: "Andrzej OleÅ" > >> Cc: "Dan Tenenbaum" , "Julian Gehring" < > julian.gehr...@embl.de>, "Michael Lawrence" > >> , bioc-devel@r-project.org > >> Sent: Tuesday, July 22, 2014 10:51:35 AM > >> Subject: Re: [Bioc-devel] Distinction between release and devel package > websites > >> > >> Hi Andrzej, > >> > >> On 7/22/2014 1:14 PM, Andrzej OleÅ wrote: > >> > Hi all, > >> > > >> > I think having links is useful, e.g. for someone who uses BioC > >> > release > >> > but wants to install by hand a particular package from the devel > >> > branch. > >> > >> I'm not sure I think this is a compelling reason for keeping the > >> links. > >> If someone is sophisticated enough to install a devel version of a > >> package into their release install, then surely they are > >> sophisticated > >> enough to get it from svn? > >> > > > > Or to know how to find the link to the tarball. > > > > Dan > > > > > >> It has always struck me as odd that we try time and again to get > >> people > >> to use biocLite() to install packages, yet make it so easy for people > >> to > >> ignore this advice. > >> > >> Best, > >> > >> Jim > >> > >> > >> > >> > >> > > >> > Distinct colors between release and devel make sense only if one > >> > understands their meaning, which in the end might prove not to be > >> > very > >> > useful. I would rather recommend emphasizing the distinction > >> > between > >> > release and devel in clear text across the package landing page, > >> > possibly in multiple places, e.g. somewhere close to the actual > >> > package version number; for instance, add the word "devel" after > >> > the > >> > version number with a tooltip which will give some > >> > explanation/warning > >> > that this is not the stable release version. > >> > > >> > The concept of a notification box is far from ideal because it > >> > tends > >> > to be annoing to the user and once dismissed 'forever' the user > >> > won't > >> > be warned in the future. > >> > > >> > I think that the actual problem arises from the fact that the > >> > release > >> > landing pages are not clearly prioritized over the devel ones. > >> > Maybe > >> > this could be addressed by preventing the devel pages from being > >> > harvested by google? It could make also sense to emphasize (bold > >> > face, > >> > color, ...) the package release landing page on the result list > >> > returned by the search engine on the BioC website. Currently, the > >> > results for release and devel differ only in their relative path, > >> > which can be easily overlooked, and both say " Home", see > >> > example below: > >>
Re: [Bioc-devel] Distinction between release and devel package websites
Hi Andrzej, - Original Message - > From: "Andrzej Oleś" > To: "Dan Tenenbaum" > Cc: "James W. MacDonald" , "Julian Gehring" > , "Michael Lawrence" > , bioc-devel@r-project.org > Sent: Tuesday, July 22, 2014 2:06:25 PM > Subject: Re: [Bioc-devel] Distinction between release and devel package > websites > > Dear Dan, James, Michael, Matt, > > thank you, I see your point but I'm afraid I must disagree with you. > I've had this situation numerous times that I have added/fixed > something in the devel branch of a package and had to advice the > users > to use this latest version. Needless to say, they were typically > using > the release branch, and it was a relatively painless procedure for > them to pick the tarball from the devel landing page and proceed with > manual installation. Of course, this could be also achieved by > installing from the svn, however, this is not very welcome from the > user's perspective. > > Please correct me if I'm wrong, but to my knowledge there is no > build-in mechanism in 'biocLite' facilitating the above described > scenario. Therefore, I think that it could be useful to have an > 'useDevel' argument to biocLite() allowing for the installation of a > specific package(s) from the devel rather than from the release > branch > without having to switch to devel completely. As this would be an > optional argument defaulting to FALSE I wouldn't be worried by > potential abuse, at least not more than by having the devel packages > exposed on the website. As an additional precaution measure we could > issue a warning and ask the user to confirm that (s)he is aware of > the > risks and wants to proceed. If a user wants to use a devel package they should be using BioC-devel. We explain on the web site how to run both BioC-devel and BioC-release on the same machine. Installing a devel package into an otherwise release installation is going to cause problems and defeats the entire purpose of having a devel branch. > > As Matt pointed out, direct links to "package source" tarballs are > very useful for quick and lightweight inspection of package code. > This > approach combined with opening the files directly with an archive > browser is particularly appealing, as it saves one from dealing with > manual svn checkout and the cleanup afterwards. Please note that > replacing the prebuild tarball with a link to the SVN has the caveat > of getting potantially broken code. Tarballs which make it through to > the website guarantee that the package at least builds. > I think we're going to leave the links there but put in some sort of popup explaining that you should really use biocLite() unless you have some special reason for downloading the tarball. Dan > Best, > Andrzej > > On Tue, Jul 22, 2014 at 7:57 PM, Dan Tenenbaum > wrote: > > > > > > - Original Message - > >> From: "James W. MacDonald" > >> To: "Andrzej Oleś" > >> Cc: "Dan Tenenbaum" , "Julian Gehring" > >> , "Michael Lawrence" > >> , bioc-devel@r-project.org > >> Sent: Tuesday, July 22, 2014 10:51:35 AM > >> Subject: Re: [Bioc-devel] Distinction between release and devel > >> package websites > >> > >> Hi Andrzej, > >> > >> On 7/22/2014 1:14 PM, Andrzej Oleś wrote: > >> > Hi all, > >> > > >> > I think having links is useful, e.g. for someone who uses BioC > >> > release > >> > but wants to install by hand a particular package from the devel > >> > branch. > >> > >> I'm not sure I think this is a compelling reason for keeping the > >> links. > >> If someone is sophisticated enough to install a devel version of a > >> package into their release install, then surely they are > >> sophisticated > >> enough to get it from svn? > >> > > > > Or to know how to find the link to the tarball. > > > > Dan > > > > > >> It has always struck me as odd that we try time and again to get > >> people > >> to use biocLite() to install packages, yet make it so easy for > >> people > >> to > >> ignore this advice. > >> > >> Best, > >> > >> Jim > >> > >> > >> > >> > >> > > >> > Distinct colors between release and devel make sense only if one > >> > understands their meaning, which in the end might prove not to > >> > be > >> > very > >> > useful. I would rather recommend emphasizing the distinction > >> > between > >> > release and devel in clear text across the package landing page, > >> > possibly in multiple places, e.g. somewhere close to the actual > >> > package version number; for instance, add the word "devel" after > >> > the > >> > version number with a tooltip which will give some > >> > explanation/warning > >> > that this is not the stable release version. > >> > > >> > The concept of a notification box is far from ideal because it > >> > tends > >> > to be annoing to the user and once dismissed 'forever' the user > >> > won't > >> > be warned in the future. > >> > > >> > I think that the actual problem arises from the fact that the > >> > release > >> > landing pages are not clearly prioritized over th
Re: [Bioc-devel] Distinction between release and devel package websites
Dear Dan, James, Michael, Matt, thank you, I see your point but I'm afraid I must disagree with you. I've had this situation numerous times that I have added/fixed something in the devel branch of a package and had to advice the users to use this latest version. Needless to say, they were typically using the release branch, and it was a relatively painless procedure for them to pick the tarball from the devel landing page and proceed with manual installation. Of course, this could be also achieved by installing from the svn, however, this is not very welcome from the user's perspective. Please correct me if I'm wrong, but to my knowledge there is no build-in mechanism in 'biocLite' facilitating the above described scenario. Therefore, I think that it could be useful to have an 'useDevel' argument to biocLite() allowing for the installation of a specific package(s) from the devel rather than from the release branch without having to switch to devel completely. As this would be an optional argument defaulting to FALSE I wouldn't be worried by potential abuse, at least not more than by having the devel packages exposed on the website. As an additional precaution measure we could issue a warning and ask the user to confirm that (s)he is aware of the risks and wants to proceed. As Matt pointed out, direct links to "package source" tarballs are very useful for quick and lightweight inspection of package code. This approach combined with opening the files directly with an archive browser is particularly appealing, as it saves one from dealing with manual svn checkout and the cleanup afterwards. Please note that replacing the prebuild tarball with a link to the SVN has the caveat of getting potantially broken code. Tarballs which make it through to the website guarantee that the package at least builds. Best, Andrzej On Tue, Jul 22, 2014 at 7:57 PM, Dan Tenenbaum wrote: > > > - Original Message - >> From: "James W. MacDonald" >> To: "Andrzej Oleś" >> Cc: "Dan Tenenbaum" , "Julian Gehring" >> , "Michael Lawrence" >> , bioc-devel@r-project.org >> Sent: Tuesday, July 22, 2014 10:51:35 AM >> Subject: Re: [Bioc-devel] Distinction between release and devel package >> websites >> >> Hi Andrzej, >> >> On 7/22/2014 1:14 PM, Andrzej Oleś wrote: >> > Hi all, >> > >> > I think having links is useful, e.g. for someone who uses BioC >> > release >> > but wants to install by hand a particular package from the devel >> > branch. >> >> I'm not sure I think this is a compelling reason for keeping the >> links. >> If someone is sophisticated enough to install a devel version of a >> package into their release install, then surely they are >> sophisticated >> enough to get it from svn? >> > > Or to know how to find the link to the tarball. > > Dan > > >> It has always struck me as odd that we try time and again to get >> people >> to use biocLite() to install packages, yet make it so easy for people >> to >> ignore this advice. >> >> Best, >> >> Jim >> >> >> >> >> > >> > Distinct colors between release and devel make sense only if one >> > understands their meaning, which in the end might prove not to be >> > very >> > useful. I would rather recommend emphasizing the distinction >> > between >> > release and devel in clear text across the package landing page, >> > possibly in multiple places, e.g. somewhere close to the actual >> > package version number; for instance, add the word "devel" after >> > the >> > version number with a tooltip which will give some >> > explanation/warning >> > that this is not the stable release version. >> > >> > The concept of a notification box is far from ideal because it >> > tends >> > to be annoing to the user and once dismissed 'forever' the user >> > won't >> > be warned in the future. >> > >> > I think that the actual problem arises from the fact that the >> > release >> > landing pages are not clearly prioritized over the devel ones. >> > Maybe >> > this could be addressed by preventing the devel pages from being >> > harvested by google? It could make also sense to emphasize (bold >> > face, >> > color, ...) the package release landing page on the result list >> > returned by the search engine on the BioC website. Currently, the >> > results for release and devel differ only in their relative path, >> > which can be easily overlooked, and both say " Home", see >> > example below: >> > >> > Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html >> >Bioconductor - DESeq2 Home >> > Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html >> >Bioconductor - DESeq2 Home >> > >> > >> > Cheers, >> > Andrzej >> > >> > On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald >> > wrote: >> >> Given that we have an ongoing problem with people inadvisedly >> >> clicking and >> >> installing things, is there a good rationale for allowing them to >> >> do so? >> >> >> >> Perhaps the landing page for each package should be stripped of >> >> links and >>
Re: [Bioc-devel] Distinction between release and devel package websites
Hi Andrzej, On 07/22/2014 10:14 AM, Andrzej Oleś wrote: Hi all, I think having links is useful, e.g. for someone who uses BioC release but wants to install by hand a particular package from the devel branch. Distinct colors between release and devel make sense only if one understands their meaning, which in the end might prove not to be very useful. I was thinking of something like this: http://www.bioconductor.org/checkResults/3.0/data-experiment-LATEST/ Just a demo. This will be reset to the usual background tomorrow. Cheers, H. I would rather recommend emphasizing the distinction between release and devel in clear text across the package landing page, possibly in multiple places, e.g. somewhere close to the actual package version number; for instance, add the word "devel" after the version number with a tooltip which will give some explanation/warning that this is not the stable release version. The concept of a notification box is far from ideal because it tends to be annoing to the user and once dismissed 'forever' the user won't be warned in the future. I think that the actual problem arises from the fact that the release landing pages are not clearly prioritized over the devel ones. Maybe this could be addressed by preventing the devel pages from being harvested by google? It could make also sense to emphasize (bold face, color, ...) the package release landing page on the result list returned by the search engine on the BioC website. Currently, the results for release and devel differ only in their relative path, which can be easily overlooked, and both say " Home", see example below: Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html Bioconductor - DESeq2 Home Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html Bioconductor - DESeq2 Home Cheers, Andrzej On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald wrote: Given that we have an ongoing problem with people inadvisedly clicking and installing things, is there a good rationale for allowing them to do so? Perhaps the landing page for each package should be stripped of links and replaced with some indication of the availability for each package on the various operating systems. There could also be a note indicating that people can install using biocLite(). Best, Jim On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: Seems like there are two problems, first that the release and devel pages look similar, but more importantly that people are downloading and installing from the package pages when they should be using biocLite(). I am open to the suggestions for making the release/devel pages look more different from each other, but I think something needs to be done about the second problem as well. Perhaps a popup that comes up when you click on a package tarball saying "The best way to install this is with biocLite(); are you sure you want to download it?" Whatever we do probably won't happen until after BioC2014. Dan - Original Message - From: "Julian Gehring" To: "Hervé Pagès" , "Michael Lawrence" , "Vincent Carey" Cc: bioc-devel@r-project.org Sent: Tuesday, July 22, 2014 8:07:29 AM Subject: Re: [Bioc-devel] Distinction between release and devel package websites Hi, Tooltips that appear while hovering over selected links are easy to miss. This alone will likely not be clear enough. We should convey the information that the entire website presents a different version of the package. The idea of a notification box that can be made visible by the individual user seems tempting. One can combine this with an optional cookie, to remember the state between browser sessions. Changing the layout of the devel page itself will also be helpful to make the distinction more pronounced. Hopefully we could approach this in a way that maintains the nice design of the bioc website. Best Julian On 21.07.2014 21:50, Hervé Pagès wrote: Hi, In addition to these suggestions, how about using a special background color for package landing pages in devel? Cheers, H. On 07/21/2014 07:32 PM, Michael Lawrence wrote: Or an unobtrusive "notification box" that drops down from the top of the page, saying something like "this is devel"; there would be a dismiss button and a checkbox for whether to show again. The user is free to simply ignore it and proceed as normal. On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey wrote: how about a tooltip that reads "installation via biocLite() is the recommended approach to Bioconductor software acquisition, other approaches may lead to inconsistent package-sets" that appears when a reader hovers over a tarball. i would imagine that this is how the "wrong package" gets installed, by manually using an inappropriate tarball. wrong documentation is not so easy but the doc on the devel branch might have a different tooltip cautioning the readers to be sure they want to read the doc on the devel version. On Mon, Jul 21, 2014 at 9:39 P
Re: [Bioc-devel] NAMESPACE problem in MacOS with VariantFiltering
Hi Robert,
I just installed VariantFiltering on my system (using the Snow Leopard build of
R) and had no trouble loading it.
Here's my sessionInfo():
R version 3.1.1 (2014-07-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] parallel stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] VariantFiltering_1.1.9 BiocGenerics_0.11.3 BiocContributions_0.99.0
[4] BiocInstaller_1.15.5
loaded via a namespace (and not attached):
[1] AnnotationDbi_1.27.8 BatchJobs_1.3
[3] BBmisc_1.7 Biobase_2.25.0
[5] BiocParallel_0.7.7 biomaRt_2.21.1
[7] Biostrings_2.33.13 bitops_1.0-6
[9] brew_1.0-6 BSgenome_1.33.8
[11] BSgenome.Hsapiens.UCSC.hg19_1.3.99 caTools_1.17
[13] checkmate_1.1 codetools_0.2-8
[15] DBI_0.2-7 digest_0.6.4
[17] fail_1.2 foreach_1.4.2
[19] GenomeInfoDb_1.1.13GenomicAlignments_1.1.22
[21] GenomicFeatures_1.17.12GenomicRanges_1.17.26
[23] htmltools_0.2.4httpuv_1.3.0
[25] IRanges_1.99.23iterators_1.0.7
[27] Rcpp_0.11.2RCurl_1.95-4.1
[29] RJSONIO_1.2-0.2Rsamtools_1.17.31
[31] RSQLite_0.11.4 rtracklayer_1.25.13
[33] S4Vectors_0.1.2sendmailR_1.1-2
[35] shiny_0.10.0 stats4_3.1.1
[37] stringr_0.6.2 tools_3.1.1
[39] VariantAnnotation_1.11.16 XML_3.98-1.1
[41] xtable_1.7-3 XVector_0.5.7
[43] zlibbioc_1.11.1
Maybe try with a fresh install of R? Or try reinstalling everything that's
outdated with biocLite()?
Dan
- Original Message -
> From: "Robert Castelo"
> To: bioc-devel@r-project.org
> Sent: Tuesday, July 22, 2014 11:25:51 AM
> Subject: [Bioc-devel] NAMESPACE problem in MacOS with VariantFiltering
>
> hi,
>
> after updating to the last devel version of all packages I cannot
> load
> one of the packages I develop, VariantFiltering, in MacOS (Snow
> Leopard)
> while the same version loads smoothly in LInux.
>
> This is the error I get:
>
> library(VariantFiltering)
> No methods found in "IRanges" for requests: Rle, substring, ifelse,
> as.factor
> Error : object ‘runValue’ is not exported by 'namespace:IRanges'
> Error: package or namespace load failed for ‘VariantFiltering’
>
> You will find the sessionInfo() at the end of the email, the package
> version is the very last one as I can see from the installed package
> description:
>
> packageDescription("VariantFiltering")$Version
> [1] "1.1.9"
>
> which, as I said, loads without any trouble in my linux box. This
> last
> version 1.1.9 does not attempt to import the failed requests from
> IRanges and in fact the check report at
>
> http://www.bioconductor.org/checkResults/3.0/bioc-LATEST/VariantFiltering/perceval-checksrc.html
>
> does not show any problem either. So I guess this problem may be
> specific of my Mac OS Snow Leopard installation and I'm really
> puzzled,
> any hint will be highly appreciated.
>
> thank you!
> robert.
> ps: sessionInfo()
> R version 3.1.0 (2014-04-10)
> Platform: x86_64-apple-darwin10.8.0 (64-bit)
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> attached base packages:
> [1] parallel stats graphics grDevices utils datasets methods
> [8] base
>
> other attached packages:
> [1] BiocGenerics_0.11.3 vimcom_0.9-93 setwidth_1.0-3
> [4] colorout_1.0-2
>
> loaded via a namespace (and not attached):
> [1] AnnotationDbi_1.27.8 BatchJobs_1.3
> [3] BBmisc_1.7 Biobase_2.25.0
> [5] BiocParallel_0.7.7 biomaRt_2.21.1
> [7] Biostrings_2.33.13 bitops_1.0-6
> [9] brew_1.0-6 BSgenome_1.33.8
> [11] BSgenome.Hsapiens.UCSC.hg19_1.3.99 caTools_1.17
> [13] checkmate_1.1 codetools_0.2-8
> [15] DBI_0.2-7 digest_0.6.4
> [17] fail_1.2 foreach_1.4.2
> [19] GenomeInfoDb_1.1.13 GenomicAlignments_1.1.22
> [21] GenomicFeatures_1.17.12 GenomicRanges_1.17.26
> [23] htmltools_0.2.4 httpuv_1.3.0
> [25] IRanges_1.99.23 iterators_1.0.7
> [27] Rcpp_0.11.2 RCurl_1.95-4.1
> [29] RJSONIO_1.2-0.2 Rsamtools_1.17.31
> [31] RSQLite_0.11.4 rtracklayer_1.25.13
> [33] S4Vectors_0.1.2 sendmailR_1.1-2
> [35] shiny_0.10.0 stats4_3.1.0
> [37] stringr_0.6.2 tools_3.1.0
> [39] XML_3.98-1.1 xtable_1.7-3
> [41] XVector_0.5.7 zlibbioc_1.11.1
>
> ___
Re: [Bioc-devel] Distinction between release and devel package websites
Thanks everyone for the input. We'll make some changes (over the next day or so), and then iterate on those as needed. Specifically 1. text after the package title indicating when the user is on the 'developer' page, with link to a 'stable release version'. 2. more prominent Installation header 3. Rename 'Package Downloads' to something less appealing, add text to indicate that the correct way to install a package is to follow Installation instructions, add pop-up interstitial to each of the gz/zip/tgz links to try to further clarify installation. We might tell google not to index devel packages (but then packages added during a particular release cycle aren't indexed until the next release). We will not change the color of the devel landing page (because color would not have meaning to the uninitiated). Interesting also that one source of problem is the _vignettes_, not the landing page. Maybe we could add a browseVignettes() code chunk. Martin On 07/22/2014 11:10 AM, Matthew McCall wrote: The current link to the source tarball is called "Package Source" hence the quotes. Yes, I could check out the package using svn, but when browsing through a Bioconductor workflow, there are these handy links to the package pages that let me download and browse the source tarball without having to type anything. I like the idea of replacing the source tarball link with a link to the package source in svn. Best, Matt On Tue, Jul 22, 2014 at 1:58 PM, Michael Lawrence wrote: Just check out from svn to get the source... way easier to keep up to date, and if you notice an issue, easier to make a patch. On Tue, Jul 22, 2014 at 10:49 AM, Matthew McCall wrote: I hope the "package source" link is not on the proposed list of links to remove. I often use these links to browse through the source code of packages to learn from others' work. Also, it seems that making the source code (even slightly) less accessible would go against the principle of open source software. Best, Matt On Tue, Jul 22, 2014 at 1:22 PM, Michael Lawrence < lawrence.mich...@gene.com> wrote: Agreed. Disabling the links is a good idea. There's really no good reason for someone to install packages manually. If a user really wants to mix release/devel, it is still technically possible but this change would strongly discourage it. For ensuring the user notices that a page is for the devel version , I'm still in favor of the simple notification box. Probably without the option to hide forever. On Tue, Jul 22, 2014 at 9:26 AM, James W. MacDonald wrote: Given that we have an ongoing problem with people inadvisedly clicking and installing things, is there a good rationale for allowing them to do so? Perhaps the landing page for each package should be stripped of links and replaced with some indication of the availability for each package on the various operating systems. There could also be a note indicating that people can install using biocLite(). Best, Jim On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: Seems like there are two problems, first that the release and devel pages look similar, but more importantly that people are downloading and installing from the package pages when they should be using biocLite(). I am open to the suggestions for making the release/devel pages look more different from each other, but I think something needs to be done about the second problem as well. Perhaps a popup that comes up when you click on a package tarball saying "The best way to install this is with biocLite(); are you sure you want to download it?" Whatever we do probably won't happen until after BioC2014. Dan - Original Message - From: "Julian Gehring" To: "Hervé Pagès" , "Michael Lawrence" < lawrence.mich...@gene.com>, "Vincent Carey" Cc: bioc-devel@r-project.org Sent: Tuesday, July 22, 2014 8:07:29 AM Subject: Re: [Bioc-devel] Distinction between release and devel package websites Hi, Tooltips that appear while hovering over selected links are easy to miss. This alone will likely not be clear enough. We should convey the information that the entire website presents a different version of the package. The idea of a notification box that can be made visible by the individual user seems tempting. One can combine this with an optional cookie, to remember the state between browser sessions. Changing the layout of the devel page itself will also be helpful to make the distinction more pronounced. Hopefully we could approach this in a way that maintains the nice design of the bioc website. Best Julian On 21.07.2014 21:50, Hervé Pagès wrote: Hi, In addition to these suggestions, how about using a special background color for package landing pages in devel? Cheers, H. On 07/21/2014 07:32 PM, Michael Lawrence wrote: Or an unobtrusive "notification box" that drops down from the top of the page, saying something like "this is devel"; there would be a dismiss button and
[Bioc-devel] NAMESPACE problem in MacOS with VariantFiltering
hi,
after updating to the last devel version of all packages I cannot load
one of the packages I develop, VariantFiltering, in MacOS (Snow Leopard)
while the same version loads smoothly in LInux.
This is the error I get:
library(VariantFiltering)
No methods found in "IRanges" for requests: Rle, substring, ifelse,
as.factor
Error : object ‘runValue’ is not exported by 'namespace:IRanges'
Error: package or namespace load failed for ‘VariantFiltering’
You will find the sessionInfo() at the end of the email, the package
version is the very last one as I can see from the installed package
description:
packageDescription("VariantFiltering")$Version
[1] "1.1.9"
which, as I said, loads without any trouble in my linux box. This last
version 1.1.9 does not attempt to import the failed requests from
IRanges and in fact the check report at
http://www.bioconductor.org/checkResults/3.0/bioc-LATEST/VariantFiltering/perceval-checksrc.html
does not show any problem either. So I guess this problem may be
specific of my Mac OS Snow Leopard installation and I'm really puzzled,
any hint will be highly appreciated.
thank you!
robert.
ps: sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] parallel stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] BiocGenerics_0.11.3 vimcom_0.9-93 setwidth_1.0-3
[4] colorout_1.0-2
loaded via a namespace (and not attached):
[1] AnnotationDbi_1.27.8 BatchJobs_1.3
[3] BBmisc_1.7 Biobase_2.25.0
[5] BiocParallel_0.7.7 biomaRt_2.21.1
[7] Biostrings_2.33.13 bitops_1.0-6
[9] brew_1.0-6 BSgenome_1.33.8
[11] BSgenome.Hsapiens.UCSC.hg19_1.3.99 caTools_1.17
[13] checkmate_1.1 codetools_0.2-8
[15] DBI_0.2-7 digest_0.6.4
[17] fail_1.2 foreach_1.4.2
[19] GenomeInfoDb_1.1.13 GenomicAlignments_1.1.22
[21] GenomicFeatures_1.17.12 GenomicRanges_1.17.26
[23] htmltools_0.2.4 httpuv_1.3.0
[25] IRanges_1.99.23 iterators_1.0.7
[27] Rcpp_0.11.2 RCurl_1.95-4.1
[29] RJSONIO_1.2-0.2 Rsamtools_1.17.31
[31] RSQLite_0.11.4 rtracklayer_1.25.13
[33] S4Vectors_0.1.2 sendmailR_1.1-2
[35] shiny_0.10.0 stats4_3.1.0
[37] stringr_0.6.2 tools_3.1.0
[39] XML_3.98-1.1 xtable_1.7-3
[41] XVector_0.5.7 zlibbioc_1.11.1
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Distinction between release and devel package websites
I just want to add the perspective that I often browse package documentation & vignettes from the website rather than accessing it from the R command line. Sometimes it's just easier or more convenient to view it in a browser. So, when doing this, I sometimes accidentally get the wrong documentation (devel instead of release or vice versa) and end up wondering why the vignette isn't working on my system. So it's just just a problem of downloading the source code. - Original Message - From: "Andrzej Oleś" To: "James W. MacDonald" Cc: "Dan Tenenbaum" , "Julian Gehring" , "Michael Lawrence" , bioc-devel@r-project.org Sent: Tuesday, July 22, 2014 10:14:05 AM Subject: Re: [Bioc-devel] Distinction between release and devel package websites Hi all, I think having links is useful, e.g. for someone who uses BioC release but wants to install by hand a particular package from the devel branch. Why would you want to do that? That's the kind of thing that gets people into trouble. Anyway, the packages would still be downloadable, and the link location could be figured out, but I don't think we need to make it easier for people to do the wrong thing by providing links. Distinct colors between release and devel make sense only if one understands their meaning, which in the end might prove not to be very useful. There are also design considerations; I'm not sure a different background color would look good. I would rather recommend emphasizing the distinction between release and devel in clear text across the package landing page, possibly in multiple places, e.g. somewhere close to the actual package version number; for instance, add the word "devel" after the version number with a tooltip which will give some explanation/warning that this is not the stable release version. The concept of a notification box is far from ideal because it tends to be annoing to the user and once dismissed 'forever' the user won't be warned in the future. I think that the actual problem arises from the fact that the release landing pages are not clearly prioritized over the devel ones. Maybe this could be addressed by preventing the devel pages from being harvested by google? It could make also sense to emphasize (bold face, color, ...) the package release landing page on the result list returned by the search engine on the BioC website. Currently, the results for release and devel differ only in their relative path, which can be easily overlooked, and both say " Home", see example below: Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html Bioconductor - DESeq2 Home Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html Bioconductor - DESeq2 Home These are all great ideas for making the release and devel pages look different from each other, and maybe we'll consider some of them, but the real problem is people downloading packages from these pages--and they could run into the same problems by downloading packages from the release landing page (if, for example, they are running BioC devel, or some version that's earlier than the current release). I don't think any of the measures will be as effective as simply removing the links and replacing them with instructions on installing the package via biocLite(). Dan Cheers, Andrzej On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald wrote: Given that we have an ongoing problem with people inadvisedly clicking and installing things, is there a good rationale for allowing them to do so? Perhaps the landing page for each package should be stripped of links and replaced with some indication of the availability for each package on the various operating systems. There could also be a note indicating that people can install using biocLite(). Best, Jim On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: Seems like there are two problems, first that the release and devel pages look similar, but more importantly that people are downloading and installing from the package pages when they should be using biocLite(). I am open to the suggestions for making the release/devel pages look more different from each other, but I think something needs to be done about the second problem as well. Perhaps a popup that comes up when you click on a package tarball saying "The best way to install this is with biocLite(); are you sure you want to download it?" Whatever we do probably won't happen until after BioC2014. Dan - Original Message - From: "Julian Gehring" To: "Hervé Pagès" , "Michael Lawrence" , "Vincent Carey" Cc: bioc-devel@r-project.org Sent: Tuesday, July 22, 2014 8:07:29 AM Subject: Re: [Bioc-devel] Distinction between release and devel package websites Hi, Tooltips that appear while hovering over selected links are easy to miss. This alone will likely not be clear enough. We should convey the information that the entire website presents a different version of the package. The idea of a notifi
Re: [Bioc-devel] Distinction between release and devel package websites
The current link to the source tarball is called "Package Source" hence the quotes. Yes, I could check out the package using svn, but when browsing through a Bioconductor workflow, there are these handy links to the package pages that let me download and browse the source tarball without having to type anything. I like the idea of replacing the source tarball link with a link to the package source in svn. Best, Matt On Tue, Jul 22, 2014 at 1:58 PM, Michael Lawrence wrote: > Just check out from svn to get the source... way easier to keep up to > date, and if you notice an issue, easier to make a patch. > > > > > On Tue, Jul 22, 2014 at 10:49 AM, Matthew McCall > wrote: > >> I hope the "package source" link is not on the proposed list of links to >> remove. I often use these links to browse through the source code of >> packages to learn from others' work. Also, it seems that making the source >> code (even slightly) less accessible would go against the principle of open >> source software. >> >> Best, >> Matt >> >> >> >> On Tue, Jul 22, 2014 at 1:22 PM, Michael Lawrence < >> lawrence.mich...@gene.com> wrote: >> >>> Agreed. Disabling the links is a good idea. There's really no good reason >>> for someone to install packages manually. If a user really wants to mix >>> release/devel, it is still technically possible but this change would >>> strongly discourage it. >>> >>> For ensuring the user notices that a page is for the devel version , I'm >>> still in favor of the simple notification box. Probably without the >>> option >>> to hide forever. >>> >>> >>> On Tue, Jul 22, 2014 at 9:26 AM, James W. MacDonald >>> wrote: >>> >>> > Given that we have an ongoing problem with people inadvisedly clicking >>> and >>> > installing things, is there a good rationale for allowing them to do >>> so? >>> > >>> > Perhaps the landing page for each package should be stripped of links >>> and >>> > replaced with some indication of the availability for each package on >>> the >>> > various operating systems. There could also be a note indicating that >>> > people can install using biocLite(). >>> > >>> > Best, >>> > >>> > Jim >>> > >>> > >>> > >>> > >>> > On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: >>> > >>> >> Seems like there are two problems, first that the release and devel >>> pages >>> >> look similar, but more importantly that people are downloading and >>> >> installing from the package pages when they should be using >>> biocLite(). >>> >> >>> >> I am open to the suggestions for making the release/devel pages look >>> more >>> >> different from each other, but I think something needs to be done >>> about the >>> >> second problem as well. Perhaps a popup that comes up when you click >>> on a >>> >> package tarball saying "The best way to install this is with >>> biocLite(); >>> >> are you sure you want to download it?" >>> >> >>> >> Whatever we do probably won't happen until after BioC2014. >>> >> >>> >> Dan >>> >> >>> >> >>> >> - Original Message - >>> >> >>> >>> From: "Julian Gehring" >>> >>> To: "Hervé Pagès" , "Michael Lawrence" < >>> >>> lawrence.mich...@gene.com>, "Vincent Carey" >>> >>> >>> >>> Cc: bioc-devel@r-project.org >>> >>> Sent: Tuesday, July 22, 2014 8:07:29 AM >>> >>> Subject: Re: [Bioc-devel] Distinction between release and devel >>> package >>> >>> websites >>> >>> >>> >>> Hi, >>> >>> >>> >>> Tooltips that appear while hovering over selected links are easy to >>> >>> miss. This alone will likely not be clear enough. We should convey >>> >>> the >>> >>> information that the entire website presents a different version of >>> >>> the >>> >>> package. >>> >>> >>> >>> The idea of a notification box that can be made visible by the >>> >>> individual user seems tempting. One can combine this with an >>> >>> optional >>> >>> cookie, to remember the state between browser sessions. >>> >>> >>> >>> Changing the layout of the devel page itself will also be helpful to >>> >>> make the distinction more pronounced. Hopefully we could approach >>> >>> this >>> >>> in a way that maintains the nice design of the bioc website. >>> >>> >>> >>> Best >>> >>> Julian >>> >>> >>> >>> >>> >>> On 21.07.2014 21:50, Hervé Pagès wrote: >>> >>> >>> Hi, >>> >>> In addition to these suggestions, how about using a special >>> background >>> color for package landing pages in devel? >>> >>> Cheers, >>> H. >>> >>> On 07/21/2014 07:32 PM, Michael Lawrence wrote: >>> >>> > Or an unobtrusive "notification box" that drops down from the top >>> > of the >>> > page, saying something like "this is devel"; there would be a >>> > dismiss >>> > button and a checkbox for whether to show again. The user is free >>> > to >>> > simply >>> > ignore it and proceed as normal. >>> > >>> > >>> > >>> > >>> > On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey >>> > >>> > wrote: >>> > >>> > how about a tooltip that
Re: [Bioc-devel] Distinction between release and devel package websites
Just check out from svn to get the source... way easier to keep up to date, and if you notice an issue, easier to make a patch. On Tue, Jul 22, 2014 at 10:49 AM, Matthew McCall wrote: > I hope the "package source" link is not on the proposed list of links to > remove. I often use these links to browse through the source code of > packages to learn from others' work. Also, it seems that making the source > code (even slightly) less accessible would go against the principle of open > source software. > > Best, > Matt > > > > On Tue, Jul 22, 2014 at 1:22 PM, Michael Lawrence < > lawrence.mich...@gene.com> wrote: > >> Agreed. Disabling the links is a good idea. There's really no good reason >> for someone to install packages manually. If a user really wants to mix >> release/devel, it is still technically possible but this change would >> strongly discourage it. >> >> For ensuring the user notices that a page is for the devel version , I'm >> still in favor of the simple notification box. Probably without the option >> to hide forever. >> >> >> On Tue, Jul 22, 2014 at 9:26 AM, James W. MacDonald >> wrote: >> >> > Given that we have an ongoing problem with people inadvisedly clicking >> and >> > installing things, is there a good rationale for allowing them to do so? >> > >> > Perhaps the landing page for each package should be stripped of links >> and >> > replaced with some indication of the availability for each package on >> the >> > various operating systems. There could also be a note indicating that >> > people can install using biocLite(). >> > >> > Best, >> > >> > Jim >> > >> > >> > >> > >> > On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: >> > >> >> Seems like there are two problems, first that the release and devel >> pages >> >> look similar, but more importantly that people are downloading and >> >> installing from the package pages when they should be using biocLite(). >> >> >> >> I am open to the suggestions for making the release/devel pages look >> more >> >> different from each other, but I think something needs to be done >> about the >> >> second problem as well. Perhaps a popup that comes up when you click >> on a >> >> package tarball saying "The best way to install this is with >> biocLite(); >> >> are you sure you want to download it?" >> >> >> >> Whatever we do probably won't happen until after BioC2014. >> >> >> >> Dan >> >> >> >> >> >> - Original Message - >> >> >> >>> From: "Julian Gehring" >> >>> To: "Hervé Pagès" , "Michael Lawrence" < >> >>> lawrence.mich...@gene.com>, "Vincent Carey" >> >>> >> >>> Cc: bioc-devel@r-project.org >> >>> Sent: Tuesday, July 22, 2014 8:07:29 AM >> >>> Subject: Re: [Bioc-devel] Distinction between release and devel >> package >> >>> websites >> >>> >> >>> Hi, >> >>> >> >>> Tooltips that appear while hovering over selected links are easy to >> >>> miss. This alone will likely not be clear enough. We should convey >> >>> the >> >>> information that the entire website presents a different version of >> >>> the >> >>> package. >> >>> >> >>> The idea of a notification box that can be made visible by the >> >>> individual user seems tempting. One can combine this with an >> >>> optional >> >>> cookie, to remember the state between browser sessions. >> >>> >> >>> Changing the layout of the devel page itself will also be helpful to >> >>> make the distinction more pronounced. Hopefully we could approach >> >>> this >> >>> in a way that maintains the nice design of the bioc website. >> >>> >> >>> Best >> >>> Julian >> >>> >> >>> >> >>> On 21.07.2014 21:50, Hervé Pagès wrote: >> >>> >> Hi, >> >> In addition to these suggestions, how about using a special >> background >> color for package landing pages in devel? >> >> Cheers, >> H. >> >> On 07/21/2014 07:32 PM, Michael Lawrence wrote: >> >> > Or an unobtrusive "notification box" that drops down from the top >> > of the >> > page, saying something like "this is devel"; there would be a >> > dismiss >> > button and a checkbox for whether to show again. The user is free >> > to >> > simply >> > ignore it and proceed as normal. >> > >> > >> > >> > >> > On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey >> > >> > wrote: >> > >> > how about a tooltip that reads "installation via biocLite() is >> >> the >> >> recommended approach to Bioconductor software >> >> acquisition, other approaches may lead to inconsistent >> >> package-sets" >> >> that >> >> appears when a reader hovers over a tarball. i would imagine >> >> that >> >> this is >> >> how the "wrong package" gets installed, by manually using an >> >> inappropriate >> >> tarball. >> >> >> >> wrong documentation is not so easy but the doc on the devel >> >> branch might >> >> have a different tooltip cautioning the readers to be sure they >> >> want to >> >>
Re: [Bioc-devel] Distinction between release and devel package websites
- Original Message - > From: "James W. MacDonald" > To: "Andrzej Oleś" > Cc: "Dan Tenenbaum" , "Julian Gehring" > , "Michael Lawrence" > , bioc-devel@r-project.org > Sent: Tuesday, July 22, 2014 10:51:35 AM > Subject: Re: [Bioc-devel] Distinction between release and devel package > websites > > Hi Andrzej, > > On 7/22/2014 1:14 PM, Andrzej Oleś wrote: > > Hi all, > > > > I think having links is useful, e.g. for someone who uses BioC > > release > > but wants to install by hand a particular package from the devel > > branch. > > I'm not sure I think this is a compelling reason for keeping the > links. > If someone is sophisticated enough to install a devel version of a > package into their release install, then surely they are > sophisticated > enough to get it from svn? > Or to know how to find the link to the tarball. Dan > It has always struck me as odd that we try time and again to get > people > to use biocLite() to install packages, yet make it so easy for people > to > ignore this advice. > > Best, > > Jim > > > > > > > > Distinct colors between release and devel make sense only if one > > understands their meaning, which in the end might prove not to be > > very > > useful. I would rather recommend emphasizing the distinction > > between > > release and devel in clear text across the package landing page, > > possibly in multiple places, e.g. somewhere close to the actual > > package version number; for instance, add the word "devel" after > > the > > version number with a tooltip which will give some > > explanation/warning > > that this is not the stable release version. > > > > The concept of a notification box is far from ideal because it > > tends > > to be annoing to the user and once dismissed 'forever' the user > > won't > > be warned in the future. > > > > I think that the actual problem arises from the fact that the > > release > > landing pages are not clearly prioritized over the devel ones. > > Maybe > > this could be addressed by preventing the devel pages from being > > harvested by google? It could make also sense to emphasize (bold > > face, > > color, ...) the package release landing page on the result list > > returned by the search engine on the BioC website. Currently, the > > results for release and devel differ only in their relative path, > > which can be easily overlooked, and both say " Home", see > > example below: > > > > Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html > >Bioconductor - DESeq2 Home > > Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html > >Bioconductor - DESeq2 Home > > > > > > Cheers, > > Andrzej > > > > On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald > > wrote: > >> Given that we have an ongoing problem with people inadvisedly > >> clicking and > >> installing things, is there a good rationale for allowing them to > >> do so? > >> > >> Perhaps the landing page for each package should be stripped of > >> links and > >> replaced with some indication of the availability for each package > >> on the > >> various operating systems. There could also be a note indicating > >> that people > >> can install using biocLite(). > >> > >> Best, > >> > >> Jim > >> > >> > >> > >> > >> On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: > >>> > >>> Seems like there are two problems, first that the release and > >>> devel pages > >>> look similar, but more importantly that people are downloading > >>> and > >>> installing from the package pages when they should be using > >>> biocLite(). > >>> > >>> I am open to the suggestions for making the release/devel pages > >>> look more > >>> different from each other, but I think something needs to be done > >>> about the > >>> second problem as well. Perhaps a popup that comes up when you > >>> click on a > >>> package tarball saying "The best way to install this is with > >>> biocLite(); are > >>> you sure you want to download it?" > >>> > >>> Whatever we do probably won't happen until after BioC2014. > >>> > >>> Dan > >>> > >>> > >>> - Original Message - > > From: "Julian Gehring" > To: "Hervé Pagès" , "Michael Lawrence" > , "Vincent Carey" > > Cc: bioc-devel@r-project.org > Sent: Tuesday, July 22, 2014 8:07:29 AM > Subject: Re: [Bioc-devel] Distinction between release and devel > package > websites > > Hi, > > Tooltips that appear while hovering over selected links are easy > to > miss. This alone will likely not be clear enough. We should > convey > the > information that the entire website presents a different version > of > the > package. > > The idea of a notification box that can be made visible by the > individual user seems tempting. One can combine this with an > optional > cookie, to remember the state between browser sessions. > > Changing the layout of the devel page itself will also
Re: [Bioc-devel] Distinction between release and devel package websites
- Original Message - > From: "Matthew McCall" > To: "Michael Lawrence" > Cc: bioc-devel@r-project.org > Sent: Tuesday, July 22, 2014 10:49:39 AM > Subject: Re: [Bioc-devel] Distinction between release and devel package > websites > > I hope the "package source" link is not on the proposed list of links > to > remove. I often use these links to browse through the source code of > packages to learn from others' work. Also, it seems that making the > source > code (even slightly) less accessible would go against the principle > of open > source software. There is no package source link (unless you mean the source tarball) but I think it would be good to add a link directly to the package source in svn. That would make the source even easier to browse than it is now (you would now have to download and untar a tarball first). Dan > > Best, > Matt > > > > On Tue, Jul 22, 2014 at 1:22 PM, Michael Lawrence > > wrote: > > > Agreed. Disabling the links is a good idea. There's really no good > > reason > > for someone to install packages manually. If a user really wants to > > mix > > release/devel, it is still technically possible but this change > > would > > strongly discourage it. > > > > For ensuring the user notices that a page is for the devel version > > , I'm > > still in favor of the simple notification box. Probably without the > > option > > to hide forever. > > > > > > On Tue, Jul 22, 2014 at 9:26 AM, James W. MacDonald > > > > wrote: > > > > > Given that we have an ongoing problem with people inadvisedly > > > clicking > > and > > > installing things, is there a good rationale for allowing them to > > > do so? > > > > > > Perhaps the landing page for each package should be stripped of > > > links and > > > replaced with some indication of the availability for each > > > package on the > > > various operating systems. There could also be a note indicating > > > that > > > people can install using biocLite(). > > > > > > Best, > > > > > > Jim > > > > > > > > > > > > > > > On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: > > > > > >> Seems like there are two problems, first that the release and > > >> devel > > pages > > >> look similar, but more importantly that people are downloading > > >> and > > >> installing from the package pages when they should be using > > >> biocLite(). > > >> > > >> I am open to the suggestions for making the release/devel pages > > >> look > > more > > >> different from each other, but I think something needs to be > > >> done about > > the > > >> second problem as well. Perhaps a popup that comes up when you > > >> click on > > a > > >> package tarball saying "The best way to install this is with > > >> biocLite(); > > >> are you sure you want to download it?" > > >> > > >> Whatever we do probably won't happen until after BioC2014. > > >> > > >> Dan > > >> > > >> > > >> - Original Message - > > >> > > >>> From: "Julian Gehring" > > >>> To: "Hervé Pagès" , "Michael Lawrence" < > > >>> lawrence.mich...@gene.com>, "Vincent Carey" > > >>> > > >>> Cc: bioc-devel@r-project.org > > >>> Sent: Tuesday, July 22, 2014 8:07:29 AM > > >>> Subject: Re: [Bioc-devel] Distinction between release and devel > > >>> package > > >>> websites > > >>> > > >>> Hi, > > >>> > > >>> Tooltips that appear while hovering over selected links are > > >>> easy to > > >>> miss. This alone will likely not be clear enough. We should > > >>> convey > > >>> the > > >>> information that the entire website presents a different > > >>> version of > > >>> the > > >>> package. > > >>> > > >>> The idea of a notification box that can be made visible by the > > >>> individual user seems tempting. One can combine this with an > > >>> optional > > >>> cookie, to remember the state between browser sessions. > > >>> > > >>> Changing the layout of the devel page itself will also be > > >>> helpful to > > >>> make the distinction more pronounced. Hopefully we could > > >>> approach > > >>> this > > >>> in a way that maintains the nice design of the bioc website. > > >>> > > >>> Best > > >>> Julian > > >>> > > >>> > > >>> On 21.07.2014 21:50, Hervé Pagès wrote: > > >>> > > Hi, > > > > In addition to these suggestions, how about using a special > > background > > color for package landing pages in devel? > > > > Cheers, > > H. > > > > On 07/21/2014 07:32 PM, Michael Lawrence wrote: > > > > > Or an unobtrusive "notification box" that drops down from the > > > top > > > of the > > > page, saying something like "this is devel"; there would be a > > > dismiss > > > button and a checkbox for whether to show again. The user is > > > free > > > to > > > simply > > > ignore it and proceed as normal. > > > > > > > > > > > > > > > On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey > > > > > > wrote: > > > > > > how about a tooltip that reads "installation via biocLite()
Re: [Bioc-devel] Distinction between release and devel package websites
Hi Andrzej, On 7/22/2014 1:14 PM, Andrzej Oleś wrote: Hi all, I think having links is useful, e.g. for someone who uses BioC release but wants to install by hand a particular package from the devel branch. I'm not sure I think this is a compelling reason for keeping the links. If someone is sophisticated enough to install a devel version of a package into their release install, then surely they are sophisticated enough to get it from svn? It has always struck me as odd that we try time and again to get people to use biocLite() to install packages, yet make it so easy for people to ignore this advice. Best, Jim Distinct colors between release and devel make sense only if one understands their meaning, which in the end might prove not to be very useful. I would rather recommend emphasizing the distinction between release and devel in clear text across the package landing page, possibly in multiple places, e.g. somewhere close to the actual package version number; for instance, add the word "devel" after the version number with a tooltip which will give some explanation/warning that this is not the stable release version. The concept of a notification box is far from ideal because it tends to be annoing to the user and once dismissed 'forever' the user won't be warned in the future. I think that the actual problem arises from the fact that the release landing pages are not clearly prioritized over the devel ones. Maybe this could be addressed by preventing the devel pages from being harvested by google? It could make also sense to emphasize (bold face, color, ...) the package release landing page on the result list returned by the search engine on the BioC website. Currently, the results for release and devel differ only in their relative path, which can be easily overlooked, and both say " Home", see example below: Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html Bioconductor - DESeq2 Home Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html Bioconductor - DESeq2 Home Cheers, Andrzej On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald wrote: Given that we have an ongoing problem with people inadvisedly clicking and installing things, is there a good rationale for allowing them to do so? Perhaps the landing page for each package should be stripped of links and replaced with some indication of the availability for each package on the various operating systems. There could also be a note indicating that people can install using biocLite(). Best, Jim On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: Seems like there are two problems, first that the release and devel pages look similar, but more importantly that people are downloading and installing from the package pages when they should be using biocLite(). I am open to the suggestions for making the release/devel pages look more different from each other, but I think something needs to be done about the second problem as well. Perhaps a popup that comes up when you click on a package tarball saying "The best way to install this is with biocLite(); are you sure you want to download it?" Whatever we do probably won't happen until after BioC2014. Dan - Original Message - From: "Julian Gehring" To: "Hervé Pagès" , "Michael Lawrence" , "Vincent Carey" Cc: bioc-devel@r-project.org Sent: Tuesday, July 22, 2014 8:07:29 AM Subject: Re: [Bioc-devel] Distinction between release and devel package websites Hi, Tooltips that appear while hovering over selected links are easy to miss. This alone will likely not be clear enough. We should convey the information that the entire website presents a different version of the package. The idea of a notification box that can be made visible by the individual user seems tempting. One can combine this with an optional cookie, to remember the state between browser sessions. Changing the layout of the devel page itself will also be helpful to make the distinction more pronounced. Hopefully we could approach this in a way that maintains the nice design of the bioc website. Best Julian On 21.07.2014 21:50, Hervé Pagès wrote: Hi, In addition to these suggestions, how about using a special background color for package landing pages in devel? Cheers, H. On 07/21/2014 07:32 PM, Michael Lawrence wrote: Or an unobtrusive "notification box" that drops down from the top of the page, saying something like "this is devel"; there would be a dismiss button and a checkbox for whether to show again. The user is free to simply ignore it and proceed as normal. On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey wrote: how about a tooltip that reads "installation via biocLite() is the recommended approach to Bioconductor software acquisition, other approaches may lead to inconsistent package-sets" that appears when a reader hovers over a tarball. i would imagine that this is how the "wrong package" gets installed, by manually using an inap
Re: [Bioc-devel] Distinction between release and devel package websites
I hope the "package source" link is not on the proposed list of links to remove. I often use these links to browse through the source code of packages to learn from others' work. Also, it seems that making the source code (even slightly) less accessible would go against the principle of open source software. Best, Matt On Tue, Jul 22, 2014 at 1:22 PM, Michael Lawrence wrote: > Agreed. Disabling the links is a good idea. There's really no good reason > for someone to install packages manually. If a user really wants to mix > release/devel, it is still technically possible but this change would > strongly discourage it. > > For ensuring the user notices that a page is for the devel version , I'm > still in favor of the simple notification box. Probably without the option > to hide forever. > > > On Tue, Jul 22, 2014 at 9:26 AM, James W. MacDonald > wrote: > > > Given that we have an ongoing problem with people inadvisedly clicking > and > > installing things, is there a good rationale for allowing them to do so? > > > > Perhaps the landing page for each package should be stripped of links and > > replaced with some indication of the availability for each package on the > > various operating systems. There could also be a note indicating that > > people can install using biocLite(). > > > > Best, > > > > Jim > > > > > > > > > > On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: > > > >> Seems like there are two problems, first that the release and devel > pages > >> look similar, but more importantly that people are downloading and > >> installing from the package pages when they should be using biocLite(). > >> > >> I am open to the suggestions for making the release/devel pages look > more > >> different from each other, but I think something needs to be done about > the > >> second problem as well. Perhaps a popup that comes up when you click on > a > >> package tarball saying "The best way to install this is with biocLite(); > >> are you sure you want to download it?" > >> > >> Whatever we do probably won't happen until after BioC2014. > >> > >> Dan > >> > >> > >> - Original Message - > >> > >>> From: "Julian Gehring" > >>> To: "Hervé Pagès" , "Michael Lawrence" < > >>> lawrence.mich...@gene.com>, "Vincent Carey" > >>> > >>> Cc: bioc-devel@r-project.org > >>> Sent: Tuesday, July 22, 2014 8:07:29 AM > >>> Subject: Re: [Bioc-devel] Distinction between release and devel package > >>> websites > >>> > >>> Hi, > >>> > >>> Tooltips that appear while hovering over selected links are easy to > >>> miss. This alone will likely not be clear enough. We should convey > >>> the > >>> information that the entire website presents a different version of > >>> the > >>> package. > >>> > >>> The idea of a notification box that can be made visible by the > >>> individual user seems tempting. One can combine this with an > >>> optional > >>> cookie, to remember the state between browser sessions. > >>> > >>> Changing the layout of the devel page itself will also be helpful to > >>> make the distinction more pronounced. Hopefully we could approach > >>> this > >>> in a way that maintains the nice design of the bioc website. > >>> > >>> Best > >>> Julian > >>> > >>> > >>> On 21.07.2014 21:50, Hervé Pagès wrote: > >>> > Hi, > > In addition to these suggestions, how about using a special > background > color for package landing pages in devel? > > Cheers, > H. > > On 07/21/2014 07:32 PM, Michael Lawrence wrote: > > > Or an unobtrusive "notification box" that drops down from the top > > of the > > page, saying something like "this is devel"; there would be a > > dismiss > > button and a checkbox for whether to show again. The user is free > > to > > simply > > ignore it and proceed as normal. > > > > > > > > > > On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey > > > > wrote: > > > > how about a tooltip that reads "installation via biocLite() is > >> the > >> recommended approach to Bioconductor software > >> acquisition, other approaches may lead to inconsistent > >> package-sets" > >> that > >> appears when a reader hovers over a tarball. i would imagine > >> that > >> this is > >> how the "wrong package" gets installed, by manually using an > >> inappropriate > >> tarball. > >> > >> wrong documentation is not so easy but the doc on the devel > >> branch might > >> have a different tooltip cautioning the readers to be sure they > >> want to > >> read the doc on the devel version. > >> > >> > >> > >> On Mon, Jul 21, 2014 at 9:39 PM, Julian Gehring > >> > >> wrote: > >> > >> Hi, > >>> > >>> Can we make the package websites for the devel and release > >>> version of a > >>> package more distinguishable? > >>> > >>> To elaborate on this: In the past, I have seen several use
Re: [Bioc-devel] Distinction between release and devel package websites
- Original Message - > From: "Andrzej Oleś" > To: "James W. MacDonald" > Cc: "Dan Tenenbaum" , "Julian Gehring" > , "Michael Lawrence" > , bioc-devel@r-project.org > Sent: Tuesday, July 22, 2014 10:14:05 AM > Subject: Re: [Bioc-devel] Distinction between release and devel package > websites > > Hi all, > > I think having links is useful, e.g. for someone who uses BioC > release > but wants to install by hand a particular package from the devel > branch. > Why would you want to do that? That's the kind of thing that gets people into trouble. Anyway, the packages would still be downloadable, and the link location could be figured out, but I don't think we need to make it easier for people to do the wrong thing by providing links. > Distinct colors between release and devel make sense only if one > understands their meaning, which in the end might prove not to be > very > useful. There are also design considerations; I'm not sure a different background color would look good. > I would rather recommend emphasizing the distinction between > release and devel in clear text across the package landing page, > possibly in multiple places, e.g. somewhere close to the actual > package version number; for instance, add the word "devel" after the > version number with a tooltip which will give some > explanation/warning > that this is not the stable release version. > > The concept of a notification box is far from ideal because it tends > to be annoing to the user and once dismissed 'forever' the user won't > be warned in the future. > > I think that the actual problem arises from the fact that the release > landing pages are not clearly prioritized over the devel ones. Maybe > this could be addressed by preventing the devel pages from being > harvested by google? It could make also sense to emphasize (bold > face, > color, ...) the package release landing page on the result list > returned by the search engine on the BioC website. Currently, the > results for release and devel differ only in their relative path, > which can be easily overlooked, and both say " Home", see > example below: > > Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html > Bioconductor - DESeq2 Home > Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html > Bioconductor - DESeq2 Home These are all great ideas for making the release and devel pages look different from each other, and maybe we'll consider some of them, but the real problem is people downloading packages from these pages--and they could run into the same problems by downloading packages from the release landing page (if, for example, they are running BioC devel, or some version that's earlier than the current release). I don't think any of the measures will be as effective as simply removing the links and replacing them with instructions on installing the package via biocLite(). Dan > > > Cheers, > Andrzej > > On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald > wrote: > > Given that we have an ongoing problem with people inadvisedly > > clicking and > > installing things, is there a good rationale for allowing them to > > do so? > > > > Perhaps the landing page for each package should be stripped of > > links and > > replaced with some indication of the availability for each package > > on the > > various operating systems. There could also be a note indicating > > that people > > can install using biocLite(). > > > > Best, > > > > Jim > > > > > > > > > > On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: > >> > >> Seems like there are two problems, first that the release and > >> devel pages > >> look similar, but more importantly that people are downloading and > >> installing from the package pages when they should be using > >> biocLite(). > >> > >> I am open to the suggestions for making the release/devel pages > >> look more > >> different from each other, but I think something needs to be done > >> about the > >> second problem as well. Perhaps a popup that comes up when you > >> click on a > >> package tarball saying "The best way to install this is with > >> biocLite(); are > >> you sure you want to download it?" > >> > >> Whatever we do probably won't happen until after BioC2014. > >> > >> Dan > >> > >> > >> - Original Message - > >>> > >>> From: "Julian Gehring" > >>> To: "Hervé Pagès" , "Michael Lawrence" > >>> , "Vincent Carey" > >>> > >>> Cc: bioc-devel@r-project.org > >>> Sent: Tuesday, July 22, 2014 8:07:29 AM > >>> Subject: Re: [Bioc-devel] Distinction between release and devel > >>> package > >>> websites > >>> > >>> Hi, > >>> > >>> Tooltips that appear while hovering over selected links are easy > >>> to > >>> miss. This alone will likely not be clear enough. We should > >>> convey > >>> the > >>> information that the entire website presents a different version > >>> of > >>> the > >>> package. > >>> > >>> The idea of a notification box that can be made visible by the >
Re: [Bioc-devel] Distinction between release and devel package websites
Agreed. Disabling the links is a good idea. There's really no good reason for someone to install packages manually. If a user really wants to mix release/devel, it is still technically possible but this change would strongly discourage it. For ensuring the user notices that a page is for the devel version , I'm still in favor of the simple notification box. Probably without the option to hide forever. On Tue, Jul 22, 2014 at 9:26 AM, James W. MacDonald wrote: > Given that we have an ongoing problem with people inadvisedly clicking and > installing things, is there a good rationale for allowing them to do so? > > Perhaps the landing page for each package should be stripped of links and > replaced with some indication of the availability for each package on the > various operating systems. There could also be a note indicating that > people can install using biocLite(). > > Best, > > Jim > > > > > On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: > >> Seems like there are two problems, first that the release and devel pages >> look similar, but more importantly that people are downloading and >> installing from the package pages when they should be using biocLite(). >> >> I am open to the suggestions for making the release/devel pages look more >> different from each other, but I think something needs to be done about the >> second problem as well. Perhaps a popup that comes up when you click on a >> package tarball saying "The best way to install this is with biocLite(); >> are you sure you want to download it?" >> >> Whatever we do probably won't happen until after BioC2014. >> >> Dan >> >> >> - Original Message - >> >>> From: "Julian Gehring" >>> To: "Hervé Pagès" , "Michael Lawrence" < >>> lawrence.mich...@gene.com>, "Vincent Carey" >>> >>> Cc: bioc-devel@r-project.org >>> Sent: Tuesday, July 22, 2014 8:07:29 AM >>> Subject: Re: [Bioc-devel] Distinction between release and devel package >>> websites >>> >>> Hi, >>> >>> Tooltips that appear while hovering over selected links are easy to >>> miss. This alone will likely not be clear enough. We should convey >>> the >>> information that the entire website presents a different version of >>> the >>> package. >>> >>> The idea of a notification box that can be made visible by the >>> individual user seems tempting. One can combine this with an >>> optional >>> cookie, to remember the state between browser sessions. >>> >>> Changing the layout of the devel page itself will also be helpful to >>> make the distinction more pronounced. Hopefully we could approach >>> this >>> in a way that maintains the nice design of the bioc website. >>> >>> Best >>> Julian >>> >>> >>> On 21.07.2014 21:50, Hervé Pagès wrote: >>> Hi, In addition to these suggestions, how about using a special background color for package landing pages in devel? Cheers, H. On 07/21/2014 07:32 PM, Michael Lawrence wrote: > Or an unobtrusive "notification box" that drops down from the top > of the > page, saying something like "this is devel"; there would be a > dismiss > button and a checkbox for whether to show again. The user is free > to > simply > ignore it and proceed as normal. > > > > > On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey > > wrote: > > how about a tooltip that reads "installation via biocLite() is >> the >> recommended approach to Bioconductor software >> acquisition, other approaches may lead to inconsistent >> package-sets" >> that >> appears when a reader hovers over a tarball. i would imagine >> that >> this is >> how the "wrong package" gets installed, by manually using an >> inappropriate >> tarball. >> >> wrong documentation is not so easy but the doc on the devel >> branch might >> have a different tooltip cautioning the readers to be sure they >> want to >> read the doc on the devel version. >> >> >> >> On Mon, Jul 21, 2014 at 9:39 PM, Julian Gehring >> >> wrote: >> >> Hi, >>> >>> Can we make the package websites for the devel and release >>> version of a >>> package more distinguishable? >>> >>> To elaborate on this: In the past, I have seen several users >>> having >>> problems with using bioconductor because they ended up on the >>> wrong >>> page >>> (mostly the devel page when they would have needed the release). >>> This >>> resulted in getting the wrong documentation or installing the >>> wrong >>> package. The pages are well designed, and there is no reason to >>> change >>> this. However, the websites for the devel and release version >>> of a >>> >> package >> >>> look almost identical, and that these two get confused seems to >>> happen to >>> many users (me included). >>> >>> If you search for a package within th
Re: [Bioc-devel] Distinction between release and devel package websites
Hi all, I think having links is useful, e.g. for someone who uses BioC release but wants to install by hand a particular package from the devel branch. Distinct colors between release and devel make sense only if one understands their meaning, which in the end might prove not to be very useful. I would rather recommend emphasizing the distinction between release and devel in clear text across the package landing page, possibly in multiple places, e.g. somewhere close to the actual package version number; for instance, add the word "devel" after the version number with a tooltip which will give some explanation/warning that this is not the stable release version. The concept of a notification box is far from ideal because it tends to be annoing to the user and once dismissed 'forever' the user won't be warned in the future. I think that the actual problem arises from the fact that the release landing pages are not clearly prioritized over the devel ones. Maybe this could be addressed by preventing the devel pages from being harvested by google? It could make also sense to emphasize (bold face, color, ...) the package release landing page on the result list returned by the search engine on the BioC website. Currently, the results for release and devel differ only in their relative path, which can be easily overlooked, and both say " Home", see example below: Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html Bioconductor - DESeq2 Home Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html Bioconductor - DESeq2 Home Cheers, Andrzej On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald wrote: > Given that we have an ongoing problem with people inadvisedly clicking and > installing things, is there a good rationale for allowing them to do so? > > Perhaps the landing page for each package should be stripped of links and > replaced with some indication of the availability for each package on the > various operating systems. There could also be a note indicating that people > can install using biocLite(). > > Best, > > Jim > > > > > On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: >> >> Seems like there are two problems, first that the release and devel pages >> look similar, but more importantly that people are downloading and >> installing from the package pages when they should be using biocLite(). >> >> I am open to the suggestions for making the release/devel pages look more >> different from each other, but I think something needs to be done about the >> second problem as well. Perhaps a popup that comes up when you click on a >> package tarball saying "The best way to install this is with biocLite(); are >> you sure you want to download it?" >> >> Whatever we do probably won't happen until after BioC2014. >> >> Dan >> >> >> - Original Message - >>> >>> From: "Julian Gehring" >>> To: "Hervé Pagès" , "Michael Lawrence" >>> , "Vincent Carey" >>> >>> Cc: bioc-devel@r-project.org >>> Sent: Tuesday, July 22, 2014 8:07:29 AM >>> Subject: Re: [Bioc-devel] Distinction between release and devel package >>> websites >>> >>> Hi, >>> >>> Tooltips that appear while hovering over selected links are easy to >>> miss. This alone will likely not be clear enough. We should convey >>> the >>> information that the entire website presents a different version of >>> the >>> package. >>> >>> The idea of a notification box that can be made visible by the >>> individual user seems tempting. One can combine this with an >>> optional >>> cookie, to remember the state between browser sessions. >>> >>> Changing the layout of the devel page itself will also be helpful to >>> make the distinction more pronounced. Hopefully we could approach >>> this >>> in a way that maintains the nice design of the bioc website. >>> >>> Best >>> Julian >>> >>> >>> On 21.07.2014 21:50, Hervé Pagès wrote: Hi, In addition to these suggestions, how about using a special background color for package landing pages in devel? Cheers, H. On 07/21/2014 07:32 PM, Michael Lawrence wrote: > > Or an unobtrusive "notification box" that drops down from the top > of the > page, saying something like "this is devel"; there would be a > dismiss > button and a checkbox for whether to show again. The user is free > to > simply > ignore it and proceed as normal. > > > > > On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey > > wrote: > >> how about a tooltip that reads "installation via biocLite() is >> the >> recommended approach to Bioconductor software >> acquisition, other approaches may lead to inconsistent >> package-sets" >> that >> appears when a reader hovers over a tarball. i would imagine >> that >> this is >> how the "wrong package" gets installed, by manually using an >> inappropriate >> tarball. >> >> wrong documentation is not so ea
Re: [Bioc-devel] Distinction between release and devel package websites
On Tue, Jul 22, 2014 at 12:50 AM, Hervé Pagès wrote: > Hi, > > In addition to these suggestions, how about using a special background > color for package landing pages in devel? > > it makes sense to do this too. > Cheers, > H. > > > On 07/21/2014 07:32 PM, Michael Lawrence wrote: > >> Or an unobtrusive "notification box" that drops down from the top of the >> page, saying something like "this is devel"; there would be a dismiss >> button and a checkbox for whether to show again. The user is free to >> simply >> ignore it and proceed as normal. >> >> >> >> >> On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey < >> st...@channing.harvard.edu> >> wrote: >> >> how about a tooltip that reads "installation via biocLite() is the >>> recommended approach to Bioconductor software >>> acquisition, other approaches may lead to inconsistent package-sets" that >>> appears when a reader hovers over a tarball. i would imagine that this >>> is >>> how the "wrong package" gets installed, by manually using an >>> inappropriate >>> tarball. >>> >>> wrong documentation is not so easy but the doc on the devel branch might >>> have a different tooltip cautioning the readers to be sure they want to >>> read the doc on the devel version. >>> >>> >>> >>> On Mon, Jul 21, 2014 at 9:39 PM, Julian Gehring >>> wrote: >>> >>> Hi, Can we make the package websites for the devel and release version of a package more distinguishable? To elaborate on this: In the past, I have seen several users having problems with using bioconductor because they ended up on the wrong page (mostly the devel page when they would have needed the release). This resulted in getting the wrong documentation or installing the wrong package. The pages are well designed, and there is no reason to change this. However, the websites for the devel and release version of a >>> package >>> look almost identical, and that these two get confused seems to happen to many users (me included). If you search for a package within the bioc website, the release version always comes first in the search results. If you are coming from the outside (e.g. google), this may not be the case. In fact, googling a few packages names often returned only the devel page in the top 10 search results. What are the feelings regarding this? We could add a header section on >>> the >>> devel page that states that this is an unstable version not meant to be used in production settings, and provide a link to the respective release version? Best wishes Julian ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> [[alternative HTML version deleted]] >>> >>> ___ >>> Bioc-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> >>> >> [[alternative HTML version deleted]] >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> > -- > Hervé Pagès > > Program in Computational Biology > Division of Public Health Sciences > Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N, M1-B514 > P.O. Box 19024 > Seattle, WA 98109-1024 > > E-mail: hpa...@fhcrc.org > Phone: (206) 667-5791 > Fax:(206) 667-1319 > [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Distinction between release and devel package websites
- Original Message - > From: "James W. MacDonald" > To: "Dan Tenenbaum" , "Julian Gehring" > > Cc: "Michael Lawrence" , bioc-devel@r-project.org > Sent: Tuesday, July 22, 2014 9:26:13 AM > Subject: Re: [Bioc-devel] Distinction between release and devel package > websites > > Given that we have an ongoing problem with people inadvisedly > clicking > and installing things, is there a good rationale for allowing them to > do > so? I tend to agree with this... > > Perhaps the landing page for each package should be stripped of links > and replaced with some indication of the availability for each > package > on the various operating systems. There could also be a note > indicating > that people can install using biocLite(). > There is such a note, but it's often ignored, as you point out. Dan > Best, > > Jim > > > > On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: > > Seems like there are two problems, first that the release and devel > > pages look similar, but more importantly that people are > > downloading and installing from the package pages when they should > > be using biocLite(). > > > > I am open to the suggestions for making the release/devel pages > > look more different from each other, but I think something needs > > to be done about the second problem as well. Perhaps a popup that > > comes up when you click on a package tarball saying "The best way > > to install this is with biocLite(); are you sure you want to > > download it?" > > > > Whatever we do probably won't happen until after BioC2014. > > > > Dan > > > > > > - Original Message - > >> From: "Julian Gehring" > >> To: "Hervé Pagès" , "Michael Lawrence" > >> , "Vincent Carey" > >> > >> Cc: bioc-devel@r-project.org > >> Sent: Tuesday, July 22, 2014 8:07:29 AM > >> Subject: Re: [Bioc-devel] Distinction between release and devel > >> packagewebsites > >> > >> Hi, > >> > >> Tooltips that appear while hovering over selected links are easy > >> to > >> miss. This alone will likely not be clear enough. We should > >> convey > >> the > >> information that the entire website presents a different version > >> of > >> the > >> package. > >> > >> The idea of a notification box that can be made visible by the > >> individual user seems tempting. One can combine this with an > >> optional > >> cookie, to remember the state between browser sessions. > >> > >> Changing the layout of the devel page itself will also be helpful > >> to > >> make the distinction more pronounced. Hopefully we could approach > >> this > >> in a way that maintains the nice design of the bioc website. > >> > >> Best > >> Julian > >> > >> > >> On 21.07.2014 21:50, Hervé Pagès wrote: > >>> Hi, > >>> > >>> In addition to these suggestions, how about using a special > >>> background > >>> color for package landing pages in devel? > >>> > >>> Cheers, > >>> H. > >>> > >>> On 07/21/2014 07:32 PM, Michael Lawrence wrote: > Or an unobtrusive "notification box" that drops down from the > top > of the > page, saying something like "this is devel"; there would be a > dismiss > button and a checkbox for whether to show again. The user is > free > to > simply > ignore it and proceed as normal. > > > > > On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey > > wrote: > > > how about a tooltip that reads "installation via biocLite() is > > the > > recommended approach to Bioconductor software > > acquisition, other approaches may lead to inconsistent > > package-sets" > > that > > appears when a reader hovers over a tarball. i would imagine > > that > > this is > > how the "wrong package" gets installed, by manually using an > > inappropriate > > tarball. > > > > wrong documentation is not so easy but the doc on the devel > > branch might > > have a different tooltip cautioning the readers to be sure they > > want to > > read the doc on the devel version. > > > > > > > > On Mon, Jul 21, 2014 at 9:39 PM, Julian Gehring > > > > wrote: > > > >> Hi, > >> > >> Can we make the package websites for the devel and release > >> version of a > >> package more distinguishable? > >> > >> To elaborate on this: In the past, I have seen several users > >> having > >> problems with using bioconductor because they ended up on the > >> wrong > >> page > >> (mostly the devel page when they would have needed the > >> release). > >> This > >> resulted in getting the wrong documentation or installing the > >> wrong > >> package. The pages are well designed, and there is no reason > >> to > >> change > >> this. However, the websites for the devel and release version > >> of a > > package > >> look almost identical, and that these two get confused seems > >> to > >> happen to > >> many user
Re: [Bioc-devel] Distinction between release and devel package websites
Given that we have an ongoing problem with people inadvisedly clicking and installing things, is there a good rationale for allowing them to do so? Perhaps the landing page for each package should be stripped of links and replaced with some indication of the availability for each package on the various operating systems. There could also be a note indicating that people can install using biocLite(). Best, Jim On 7/22/2014 11:48 AM, Dan Tenenbaum wrote: Seems like there are two problems, first that the release and devel pages look similar, but more importantly that people are downloading and installing from the package pages when they should be using biocLite(). I am open to the suggestions for making the release/devel pages look more different from each other, but I think something needs to be done about the second problem as well. Perhaps a popup that comes up when you click on a package tarball saying "The best way to install this is with biocLite(); are you sure you want to download it?" Whatever we do probably won't happen until after BioC2014. Dan - Original Message - From: "Julian Gehring" To: "Hervé Pagès" , "Michael Lawrence" , "Vincent Carey" Cc: bioc-devel@r-project.org Sent: Tuesday, July 22, 2014 8:07:29 AM Subject: Re: [Bioc-devel] Distinction between release and devel package websites Hi, Tooltips that appear while hovering over selected links are easy to miss. This alone will likely not be clear enough. We should convey the information that the entire website presents a different version of the package. The idea of a notification box that can be made visible by the individual user seems tempting. One can combine this with an optional cookie, to remember the state between browser sessions. Changing the layout of the devel page itself will also be helpful to make the distinction more pronounced. Hopefully we could approach this in a way that maintains the nice design of the bioc website. Best Julian On 21.07.2014 21:50, Hervé Pagès wrote: Hi, In addition to these suggestions, how about using a special background color for package landing pages in devel? Cheers, H. On 07/21/2014 07:32 PM, Michael Lawrence wrote: Or an unobtrusive "notification box" that drops down from the top of the page, saying something like "this is devel"; there would be a dismiss button and a checkbox for whether to show again. The user is free to simply ignore it and proceed as normal. On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey wrote: how about a tooltip that reads "installation via biocLite() is the recommended approach to Bioconductor software acquisition, other approaches may lead to inconsistent package-sets" that appears when a reader hovers over a tarball. i would imagine that this is how the "wrong package" gets installed, by manually using an inappropriate tarball. wrong documentation is not so easy but the doc on the devel branch might have a different tooltip cautioning the readers to be sure they want to read the doc on the devel version. On Mon, Jul 21, 2014 at 9:39 PM, Julian Gehring wrote: Hi, Can we make the package websites for the devel and release version of a package more distinguishable? To elaborate on this: In the past, I have seen several users having problems with using bioconductor because they ended up on the wrong page (mostly the devel page when they would have needed the release). This resulted in getting the wrong documentation or installing the wrong package. The pages are well designed, and there is no reason to change this. However, the websites for the devel and release version of a package look almost identical, and that these two get confused seems to happen to many users (me included). If you search for a package within the bioc website, the release version always comes first in the search results. If you are coming from the outside (e.g. google), this may not be the case. In fact, googling a few packages names often returned only the devel page in the top 10 search results. What are the feelings regarding this? We could add a header section on the devel page that states that this is an unstable version not meant to be used in production settings, and provide a link to the respective release version? Best wishes Julian ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] ___ 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] Distinction between release and devel package websites
Seems like there are two problems, first that the release and devel pages look similar, but more importantly that people are downloading and installing from the package pages when they should be using biocLite(). I am open to the suggestions for making the release/devel pages look more different from each other, but I think something needs to be done about the second problem as well. Perhaps a popup that comes up when you click on a package tarball saying "The best way to install this is with biocLite(); are you sure you want to download it?" Whatever we do probably won't happen until after BioC2014. Dan - Original Message - > From: "Julian Gehring" > To: "Hervé Pagès" , "Michael Lawrence" > , "Vincent Carey" > > Cc: bioc-devel@r-project.org > Sent: Tuesday, July 22, 2014 8:07:29 AM > Subject: Re: [Bioc-devel] Distinction between release and devel package > websites > > Hi, > > Tooltips that appear while hovering over selected links are easy to > miss. This alone will likely not be clear enough. We should convey > the > information that the entire website presents a different version of > the > package. > > The idea of a notification box that can be made visible by the > individual user seems tempting. One can combine this with an > optional > cookie, to remember the state between browser sessions. > > Changing the layout of the devel page itself will also be helpful to > make the distinction more pronounced. Hopefully we could approach > this > in a way that maintains the nice design of the bioc website. > > Best > Julian > > > On 21.07.2014 21:50, Hervé Pagès wrote: > > Hi, > > > > In addition to these suggestions, how about using a special > > background > > color for package landing pages in devel? > > > > Cheers, > > H. > > > > On 07/21/2014 07:32 PM, Michael Lawrence wrote: > >> Or an unobtrusive "notification box" that drops down from the top > >> of the > >> page, saying something like "this is devel"; there would be a > >> dismiss > >> button and a checkbox for whether to show again. The user is free > >> to > >> simply > >> ignore it and proceed as normal. > >> > >> > >> > >> > >> On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey > >> > >> wrote: > >> > >>> how about a tooltip that reads "installation via biocLite() is > >>> the > >>> recommended approach to Bioconductor software > >>> acquisition, other approaches may lead to inconsistent > >>> package-sets" > >>> that > >>> appears when a reader hovers over a tarball. i would imagine > >>> that > >>> this is > >>> how the "wrong package" gets installed, by manually using an > >>> inappropriate > >>> tarball. > >>> > >>> wrong documentation is not so easy but the doc on the devel > >>> branch might > >>> have a different tooltip cautioning the readers to be sure they > >>> want to > >>> read the doc on the devel version. > >>> > >>> > >>> > >>> On Mon, Jul 21, 2014 at 9:39 PM, Julian Gehring > >>> > >>> wrote: > >>> > Hi, > > Can we make the package websites for the devel and release > version of a > package more distinguishable? > > To elaborate on this: In the past, I have seen several users > having > problems with using bioconductor because they ended up on the > wrong > page > (mostly the devel page when they would have needed the release). > This > resulted in getting the wrong documentation or installing the > wrong > package. The pages are well designed, and there is no reason to > change > this. However, the websites for the devel and release version > of a > >>> package > look almost identical, and that these two get confused seems to > happen to > many users (me included). > > If you search for a package within the bioc website, the release > version > always comes first in the search results. If you are coming > from the > outside (e.g. google), this may not be the case. In fact, > googling > a few > packages names often returned only the devel page in the top 10 > search > results. > > What are the feelings regarding this? We could add a header > section on > >>> the > devel page that states that this is an unstable version not > meant to be > used in production settings, and provide a link to the > respective > release > version? > > Best wishes > Julian > > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > >>> > >>> [[alternative HTML version deleted]] > >>> > >>> ___ > >>> Bioc-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >>> > >> > >> [[alternative HTML version deleted]] > >> > >> ___ > >> Bioc-devel@r-pr
Re: [Bioc-devel] Distinction between release and devel package websites
Hi, Tooltips that appear while hovering over selected links are easy to miss. This alone will likely not be clear enough. We should convey the information that the entire website presents a different version of the package. The idea of a notification box that can be made visible by the individual user seems tempting. One can combine this with an optional cookie, to remember the state between browser sessions. Changing the layout of the devel page itself will also be helpful to make the distinction more pronounced. Hopefully we could approach this in a way that maintains the nice design of the bioc website. Best Julian On 21.07.2014 21:50, Hervé Pagès wrote: Hi, In addition to these suggestions, how about using a special background color for package landing pages in devel? Cheers, H. On 07/21/2014 07:32 PM, Michael Lawrence wrote: Or an unobtrusive "notification box" that drops down from the top of the page, saying something like "this is devel"; there would be a dismiss button and a checkbox for whether to show again. The user is free to simply ignore it and proceed as normal. On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey wrote: how about a tooltip that reads "installation via biocLite() is the recommended approach to Bioconductor software acquisition, other approaches may lead to inconsistent package-sets" that appears when a reader hovers over a tarball. i would imagine that this is how the "wrong package" gets installed, by manually using an inappropriate tarball. wrong documentation is not so easy but the doc on the devel branch might have a different tooltip cautioning the readers to be sure they want to read the doc on the devel version. On Mon, Jul 21, 2014 at 9:39 PM, Julian Gehring wrote: Hi, Can we make the package websites for the devel and release version of a package more distinguishable? To elaborate on this: In the past, I have seen several users having problems with using bioconductor because they ended up on the wrong page (mostly the devel page when they would have needed the release). This resulted in getting the wrong documentation or installing the wrong package. The pages are well designed, and there is no reason to change this. However, the websites for the devel and release version of a package look almost identical, and that these two get confused seems to happen to many users (me included). If you search for a package within the bioc website, the release version always comes first in the search results. If you are coming from the outside (e.g. google), this may not be the case. In fact, googling a few packages names often returned only the devel page in the top 10 search results. What are the feelings regarding this? We could add a header section on the devel page that states that this is an unstable version not meant to be used in production settings, and provide a link to the respective release version? Best wishes Julian ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] ___ 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
