Those of you who used RPy in there code would perhaps have been slightly stunned when moving to Fedora 11 by the presence of only RPy2. Whilst RPy2 is the natural progression to the R – Python interface there is just the small annoying problem that years of code in RPy does NOT work in RPy2. If that is the case and your like me and have not got the time to rewrite your code just now and the RPy2 “classic” compatibility mode sucks up all you code and spits it out blood guts and all then you’ll be happy to find RPy1 on the Fedora 11 test-repo in the next hour or so.

For me having RPy back means that beamish (beam correction code) and faithful (spectra processing code) are now back up and running and unaware of their near premature demise.

The RPM was adapted from the Fedora 10 SRC rpm renamed (rather crudely) and once installed will work as it did prior to RPy2. As RPy2 now uses the RPy name but not the RPy module name in python both can co-exist happily.

5 thoughts on “RPy

  1. rpy2 has indeed a rpy_classic module that aims at emulating the rpy interface, but unfortunately the rpy user base has remained *completely* unresponsive to calls for contributions in order to make it more complete.

    The absence of bug reports regarding what is exactly not working with rpy_classic is probably not helping to create vocations either.



  2. Yep, I looked into using the rpy_classic mode and it did not work. I thought it was a conversion issue, basic/no etc. Corrected still did not work. Googled and found another person with the same problem.

    http://www.mail-archive.com/rpy-list@lists.sourceforge.net/msg01893.html they had raised the issues and I see that you had informed them that rpy_classic was similar NOT the same. Hence as it was quicker to build and re-release rpy back into Fedora 11 than to fix the issues in my code regarding RPy2 and or RPy_classic we are where we are. I would report a bug but it seemed to be behaviour you expected and therefore NOT a bug as such.

  3. You are most welcome to report bugs (see
    http://rpy.sourceforge.net/rpy2_bugs.html )
    There is no warranty that *I* will try to solve them, but I will know about it, and someone else may also feel like contributing a fix.

    I chose the namespace rpy2 so users of rpy would not be forced to upgrade one way or the other, but I would like to clear up potential misunderstandings.

    In the thread you are referring to, I am reading:

    This is not a complete implementation of the rpy API because of:
    – limited resources
    – apparently a limited demand
    Contributions have not been many.

    For reference:


  4. No worries.

    I read the thread in full before making the rpm. From my interpretation it was getting rather stressed and a tad personal. I’m glad you kept the namespaces separate. It was very forward and backward thinking of you. It is a shame though that the rpm is not a default part of Fedora 11. If it were it would allow people time to port their code over. As it stands my code is stuck in rpy and rpy classic created the error:
    “””AttributeError: ‘Robj’ object has no attribute ‘getSexp'”””.
    After I had to set the default conversion. I will have to do some proper debugging and post it to your bug tracker system. BUT like I say your post clearly stated that RPy_classic mode is similar NOT the same so I took that as it is read – do not expect all the code to work.

  5. I made two fixes to rpy_classic on Aug 5th, following someone’s report of a problem (one of which concerns ‘getSexp’).
    Those fixes are in the branch 2.1-dev and I just backported them to 2.0.x. The fixes will appear with 2.0.7, but trying the code from repository before could save a release cycle before the next issue is found.

    Otherwise, the same as rpy *is* rpy. 😉

    The lower-level interface in rpy2.rinterface can be used to implement a similar interface to R than the one provided by rpy.
    The degree of similarity can be rather high, provided that the necessary effort is invested. Currently rpy_classic is less than 300 lines of Python (yet emulating a fair bit of rpy).