Bug 591331 - Review Request: rpy1 - Python interface to the R language
Summary: Review Request: rpy1 - Python interface to the R language
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 528664
TreeView+ depends on / blocked
Reported: 2010-05-11 22:21 UTC by José Matos
Modified: 2014-09-27 22:35 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-09-27 22:35:59 UTC
Type: ---

Attachments (Terms of Use)

Description José Matos 2010-05-11 22:21:52 UTC
Spec URL: http://jamatos.fedorapeople.org/rpy1.spec
SRPM URL: http://jamatos.fedorapeople.org/rpy1-1.0.3-13.fc13.src.rpm
Description: RPy provides a robust Python interface to the R
programming language.  It can manage all kinds of R objects and can
execute arbitrary R functions. All the errors from the R language are
converted to Python exceptions.

This is the same version that was built until Fedora 10. From that version on the rpy version used is rpy2. Since both versions are supported and can coexist this package intends to fill the gap.

Comment 1 Jason Tibbitts 2010-11-24 00:51:35 UTC
This fails to build for me in both f14 and rawhide.  Is it really necessary to force such a strict version dependency on the base R package?  That sounds like a recipe for broken dependencies.

Comment 2 José Matos 2010-11-24 08:12:16 UTC
Yes. We (me and Spot) tried several other strategies and this is the only one that is robust and works.

In practice it does not matter much because every time that Spot rebuilds R he rebuilds rpy as well.

Does the build fails if you update the required R version to 2.12.0?

Comment 3 Pierre-YvesChibon 2011-01-26 21:08:50 UTC
With an update R version to 2.12.1, it builds fine: http://koji.fedoraproject.org/koji/taskinfo?taskID=2744369

Comment 4 Jason Tibbitts 2012-06-29 22:08:36 UTC
Not sure why BuildFails is still in the whiteboard if this is building; I'll clear it, but 17 months later I'm not sure if it matters.  Could you indicate if this is still something you'd still like to submit?  Is there still any point in having the old rpy version around, given that it hasn't been part of the distribution in years?

Comment 5 Mario Blättermann 2012-09-12 20:23:41 UTC
Are there still reasons to keep this alive artificially? Who would benefit from this ancient rpy?

Comment 6 José Matos 2012-09-13 23:12:34 UTC
The issue is that rpy1 and rpy2 are different code bases.

I still have code that uses rpy1 as far as possible (and reasonable) I like to have rpms for the packages I use. It simplifies a lot a setup of new machines. :-)

And yes, I am still interested in having this again in the distribution.
My term of comparison is in a sense debian (informed common sense weighting in naturally) and debian does have both rpy1 and rpy2. Both packages are maintained by Dirk Eddelbuettel. I know Dick and I have a respect for his technical options.

Comment 7 Jason Tibbitts 2013-04-29 19:28:50 UTC
Fails to build for me; it appears that this needs to be kept up to date with the current Fedora R version in order to be useful.

Comment 8 José Matos 2013-05-03 13:55:47 UTC
You are right. :-)

I have the patches for that, and I intend to apply them soon.

There are several cases where the code has changed. I have already the debian patches and I will adapt them as I see it fits our rules.

Thanks for your interest in this.

Comment 9 Christopher Meng 2014-08-25 04:17:56 UTC
You should package rpy2.

Comment 10 Christopher Meng 2014-08-25 04:19:22 UTC
Ignore my last comment, as rpy has version 2 in the repo.

I'm curious about whether rpy1 is useful or not.

Comment 11 José Matos 2014-09-27 22:35:59 UTC
The package is only useful for old code that uses it. The new version 2.3.4 at this moment has some kind of compatibility layer but that it implies some time to change the code and it is not a complete solution (it fails in some cases).

Since this review has been open for so long I decided to withdraw it and place rpy1 in a copr:


Note You need to log in before you can comment on or make changes to this bug.