The graph package moved from suggests to imports.

[wlandau]

The graph package was removed from CRAN, so I do not think the strict dependency bodes well for reverse dependencies such as drake. Unless graph will reappear on CRAN. Do you think that is likely to happen, or will Bioconductor remain the primary/only destination for releases?

[gmbecker]

From what I can see the graph package is (and still is) in Bioconductor so it should be fine.

…

On Sun, Mar 25, 2018, 12:56 PM Will Landau ***@***.***> wrote: The graph package was removed from CRAN, so I do not think the strict dependency bodes well for reverse dependencies such as drake. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#30>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3dsVc-rfRHA8wPKf0NcA8eevVmrQFbks5th_aFgaJpZM4S6R62> .

[wlandau]

It may be within the rules, but I worry that it will create extra friction during installation for CodeDepends and all its reverse dependencies. For me, devtools::install_github("duncantl/CodeDepends") failed because I did not have graph installed. I think this is related to r-lib/devtools#700. Does graph really need to be in Imports:? If so, what about adding a blank biocViews: field to the DESCRIPTION? (from this post).

[gmbecker]

I can look into what we can do about this in the longer term, but in the shorter term, using switchr instead of devtools to install CodeDepends (and thus, drake) from github works fine, even with no bioconductor packages already installed: man = GithubManifest("duncantl/CodeDepends") install_packages("CodeDepends", man) Hope that helps with any immediate issues you may be having during development. I can even do them at the same time and get the github versions for both (unlike devtools) man = GithubManifest("wlandau/drake", "duncantl/CodeDepends") install_packages("drake", man) Or I would be able to if igraph weren't failing to compile for me for some reason (regardless of if I use install.packages or switchr). drake has a *lot* of dependencies when installed into a completely clean library, btw... Anyway, I hope that helps.

…

On Mon, Mar 26, 2018 at 6:16 AM, Will Landau ***@***.***> wrote: It may be within the rules, but I worry that it will create extra friction during installation for CodeDepends and all its reverse dependencies. For me, devtools::install_github("duncantl/CodeDepends") failed because I did not have graph installed. I think this is related to r-lib/devtools#700 <r-lib/devtools#700>. Does graph really need to be in Imports:? If so, what about adding a blank biocViews: field to the DESCRIPTION? (from this post <https://stackoverflow.com/questions/14343817/cran-package-depends-on-bioconductor-package-installing-error/38577486> ). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3dsRTRyPKUxfXobP4_sFg5kKkA5VaBks5tiOongaJpZM4S6R62> .

-- Gabriel Becker, Ph.D Scientist Bioinformatics and Computational Biology Genentech Research

[wlandau]

Moving to igraph would also fix #25. Maybe I can help. What is the compilation error exactly? What platform do you use?

[gmbecker]

For this release I've cleaned up the import to clobber the warnings but haven't made the jump to igraph. If you're still interested/willing to help I'd like to explore that further and see how close it could come to a drop-in replacement.

[wlandau]

Which functions require graph? Any besides makeCallGraph(), makeVariableGraph(), and makeTaskGraph()? If not, would it be enough for now to move graph to Suggests: and check for it in those functions (with instructions to install from Bioconductor if graph is not found)?

[wlandau]

I am still interested in helping to make the transition to igraph, and this first step seems like a good way to work up to an understanding of the internals.

[gmbecker]

I'm not really happy with removing existing, valuable functionality from the package like that. We made graph a dependency for a reason, and the fact that it is a Bioconductor package not withstanding, I still think it was a good one. I'm willing to consider moving to igraph if it can do everything we currently use graph + Rgraphviz for (I'm skeptical but openminded about this), but as it stands now convincing me to remove the functionality to behind suggests would take some doing. Bioconductor packages did also just recently get easier to install. Not as completely easy as I have argued for, but there is now a package on CRAN for the installation, validation, and management of sets of bioc packages. So maybe it wont' be as much of an issue as it has in the past?

…

On Sun, Jun 24, 2018 at 3:57 PM, Will Landau ***@***.***> wrote: I am still interested in helping to make the transition to igraph, and this first step seems like a good way to work up to an understanding of the internals. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3dsaxzZLeT_hB0Zs9OV1m4XItIZXHXks5uABlvgaJpZM4S6R62> .

-- Gabriel Becker, Ph.D Scientist Bioinformatics and Computational Biology Genentech Research

[wlandau]

I understand. I have been using CodeDepends exclusively for getInputs(), so I did not know just how central the other functionality was.

[dgkf]

Hey @gmbecker - this dependency recently caused a bit of friction when trying to roll out scriptgloss.

As a stop-gap measure, the recommended installation is through BiocManager - that method was new to me and might be a barrier to adoption for those more accustom to the usual devtools practices. Furthermore, BiocManager seems to be only available for R >=3.5.0 and I'd really like to make my package available for all R versions for which shiny is available (R >= 3.0.2)- or at least support it as far back as possible.

I would certainly support a move to igraph to lower this installation barrier. I'm sure there are plenty of other considerations as to which package was chosen, but this was the sticking point from my perspective. I hope it adds to the discussion.