Re: [igraph] Version 0.7?

[Diego Diez]

Hi Gabor,

Please see my comments below:

On Wed, Jan 29, 2014 at 12:19 PM, Gábor Csárdi <address@hidden> wrote:
> Hi Diego, thanks for the answer.
>
> On Tue, Jan 28, 2014 at 9:36 PM, Diego Diez <address@hidden> wrote:
>>
>> Hi Gabor,
>
>
> [...]
>
>>
>> If I understand correctly from your email, the problem is that many
>> packages depend on igraph, and so pushing changes to CRAN that disrupt
>> the API may make a lot of packages to fail to build, potentially
>> creating a lot of disruption.
>
>
> The main problem is not that I am breaking other packages, usually I am not.
> (The 0 -> 1 indexing case was an exception.) The problem is that I need to
> check 150 packages. Most of these are easy, but some (~30) are not and I
> spent my whole day with this. This is a burden, and makes me delay igraph
> releases all the time. This is not productive at all. I would rather work on
> igraph.
>
> Now there will be some changes again in igraph before the release and I'll
> need to do this again. I need to install all these packages, together with
> their dependencies, altogether about 700 packages, more than 5 GBytes. Many
> of them require system libraries, like MPI, GTK, ggobi, etc.
>
> 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).

>> My opinion is that yes, usually changing the API or making other big
>> changes will cause problems. A potential solution is to add a
>> dependency on a particular igraph version (e.g. igraph <= 0.6). But
>> this will not solve the problem if the user has other packages that
>> were updated to use igraph 0.7,  as it is not straightforward to
>> have/maintain both versions of the package in a single installation
>> (AFAIK).
>
>
> Practically impossible, I would say.
>
>> This problem will still exists if you remove igraph from CRAN, as
>> different maintainers will adopt igraph 0.7 or future versions at
>> different paces. It will only make slightly more painful to install
>> packages that depend on future versions of igraph.
>
>
> 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.

>>
>> A better solution is actually what you did when igraph 0.6 came out
>> and changed the index system in R. You released igraph0, which was
>> actually 0.5, to support legacy code. This required a small change in
>> the dependencies that most people were probably willing to do at any
>> time.
>
>
> I am glad that this worked for you, this was exactly my motivation for doing
> it. But this is now not allowed on CRAN, because Prof Ripley didn't like it.
> Don't ask me why. He actually went after people, and made them upgrade to
> igraph from igraph0, and then deleted igraph0 from CRAN, even if I wanted to
> keep it there.

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.

>
> [...]
>
>> The main problem with CRAN is that, unlike Bioconductor, there is no
>> such a concept of "CRAN releases". In CRAN the latest version of a
>> package is available irrespective of whether that breaks all the
>> dependent packages. In Bioc, each release ensures that a particular
>> version of a package works with a particular version of a dependency.
>> Of course, this only applies to packages in the Bioconductor
>> environment.
>
>
> Exactly. One solution would be having releases. As R also has scheduled
> releases, this would be rather easy and logical. But it does not seem that
> it will ever happen. Another solution would be exact dependencies and the
> ability to install and load multiple versions of the same package (at the
> same time, obviously). Jerome Ooms has a nice writeup in the R journal about
> this: http://journal.r-project.org/archive/2013-1/ooms.pdf

Thank you for the link- very interesting. Yes, something is needed
here. Reproducible research is very important for me- and many other
people- and requires being able to specify which package version to
use. Hope there is something in the future to improve this.

>
> [...]
>
>> In summary, I do not think moving igraph from CRAN will solve the
>> problem. If the new code disrupts a considerable amount of packages
>> then using the igraph0 approach may be a much useful way to make the
>> transition smoothly for package maintainers.
>
>
> Actually, you gave me a good idea by mentioning BioConductor. I could just
> move it to BioConductor from CRAN, that could work. There are some things I
> don't like in BioConductor, though, e.g. the way they do versioning instead
> of you, etc.

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!

>
> Alternatively, I could work out the igraph_installer package idea, if it is
> possible at all.

Or maybe the github option :-) Whatever the option you choose, thank
you for the hard work and the excellent igraph package!

All the best,
Diego

>
> Best,
> Gabor
>
> _______________________________________________
> igraph-help mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>