Re: [igraph] Version 0.7?

[Diego Diez]

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 <address@hidden> wrote:
> On Wed, Jan 29, 2014 at 10:10 PM, Diego Diez <address@hidden> wrote:
>>
>> On Wed, Jan 29, 2014 at 12:19 PM, Gábor Csárdi <address@hidden>
>> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>