Re: [igraph] Version 0.7?

[Diego Diez]

Hi Gabor,

Thank you so much for the info.

Best,
Diego

On Fri, Feb 14, 2014 at 11:02 PM, Gábor Csárdi <address@hidden> wrote:
> Hi Diego,
>
> I am sorry, I forgot to update the NEWS file in the R package, and there is
> nothing on the web page yet, so I agree this is not nice at all. Here is the
> list of changes, I'll also put them on the web page soon:
> https://github.com/igraph/igraph/blob/release-0.7/www/_posts/2013-11-13-igraph-0.7-r.markdown
>
> Best,
> Gabor
>
>
> On Thu, Feb 13, 2014 at 11:49 PM, Diego Diez <address@hidden> wrote:
>>
>> 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
>> >
>>
>> _______________________________________________
>> igraph-help mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
>
> _______________________________________________
> igraph-help mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>