Hi Gabor, I have noticed that igraph 0.7 has hit CRAN. Congratulations!
Also noticed some of the incompatibilities you have mentioned before. In particular two affecting my package were: - the removal of igraph.intersection.by.name() and igraph.union.by.name(). I found that everything can be done with igraph.intersection() and igraph.union() and they will guess the right thing to do. - before, doing V(g)[ 1 ]$pie.color would return a vector, now it returns a list() with one element. I could find and fix those due to some warnings in the R CMD check command, but I am wondering if there are other changes that are not shown there that we should be aware of. I could not find the list of changes in the NEWS file. Is there a place where the changes in igraph 0.7 can be checked? Thank you. Best regards, Diego On Fri, Jan 31, 2014 at 12:52 AM, Gábor Csárdi <[email protected]> wrote: > 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 > _______________________________________________ igraph-help mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/igraph-help
