On Wed, Jan 29, 2014 at 10:10 PM, Diego Diez <[email protected]> wrote:
> On Wed, Jan 29, 2014 at 12:19 PM, Gábor Csárdi <[email protected]> > wrote: > [...] > > I think the current CRAN organization is unsustainable, and makes > > maintainers with popular packages work a lot. This should be avoided, > and my > > problem is that I don't see any improvement or developments towards this. > > Do you really need to check all dependent packages in CRAN by > yourself? I am ignorant about CRAN rules as I never submitted there, > mainly because all my packages fit better in the Bioconductor > environment. But it looks unreasonable to put that burden on the > developers. Maintainers of dependent packages should either adapt the > package or require a specific version of the package (with all the > limitations this has). > Yes, I do. I asked them explicitly, and they told me that on a four core machine it only takes a couple of hours, or something like that. > Yes, that is exactly the problem. I am thinking about working around this, > > e.g. by having an igraph_installer package on CRAN, that would be able to > > install and load multiple versions of igraph. This way people could > depend > > on exact versions. But I still need to work this out fully, in a way > that it > > potentially acceptable for the CRAN maintainers, and convenient for > people > > who use igraph. > > Another possibility is using github and then people can use devtools' > install_github() to get any version they want. This is becoming so > popular that probably it is worth trying. Today in Bioconductor they > announced a bioc-github bridge and I am looking forward to move all my > development there. > igraph is on github, but I don't like installing packages from github, because I want to provide binaries for windows and osx users. So if not CRAN, then I would create a CRAN-like repository people can install from, simply with install.packages(). I just read the thread in R-devel where you were asking for advice > about making the transition with igraph 0.6. I guess the main problem > is that they did not like the idea of igraph0, but preferred that you > have left igraph as it was and created igraph2. Indeed that would have > been even better in terms of the end users as no packages would have > been disrupted at all. Then adding a warning in igraph about igraph2 > being released would make users/package maintainers aware of the new > version. I understand that maybe you did not want to change the name > of the package for consistency with the other igraph APIs. In my > personal case I only use the R interface, so whether the other > interfaces have different version numbers or not is completely > irrelevant- as far as I have the latest R version. > I think changing the name of the project every time there is an incompatible update is absurd. The problem is clearly the lack of versioned dependencies and installs, and renaming is a big hack, imho. What I did was a hack, too, but on the long run it was better, I think. [...] Actually, I was tempted to suggest that directly. The reason I did not > do so is that igraph is way a more general package in terms of > audience. Many people working on things unrelated to biology may find > it more difficult to access the latest version of igraph if it is in > bioconductor. (maybe not?). After all, and as you said, package > versioning will be controlled there. That is not so different to > making a new package called igraph2! > It is actually easy to install from BioC, you just need to set the repository in your startup file, or explicitly in install.packages(). It is 20 more characters to type, that is true. So this is not really like igraph2. I could try to negotiate the BioC people about version numbers, obviously I don't want to change the igraph version numbers. Anyway, I don't think anything will happen soon and igraph will be on CRAN for a while. Best, Gabor
_______________________________________________ igraph-help mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/igraph-help
