rirods package

34 views
Skip to first unread message

Mariana Montes

unread,
Mar 1, 2023, 9:36:03 AM3/1/23
to iRODS-Chat

Hello! I am part of the KU Leuven team working on the iRODS implementation. We are very interested in an R client that could help increase iRODS adoption across R users in our institution. So, first of all, thank you for working on this package!


Given our interest and my experience with R, I looked into the rirods package. I understand it is still under development, and some of my observations can eventually be reported for bug fixes. However, I also have some questions that pertain to more profound design choices and the direction chosen for this package. 


My most fundamental question is to what degree rirods is meant to align with other clients such as iCommands and the PRC. In particular, the names of the functions are the same as in iCommands, and this relationship was explicitly mentioned in the TRIRODS presentation. However, the {rirods} implementations of iput() and iget() behave in a different way, with a double functionality: transferring files (like in iCommands) and storing/reading R objects in RDS format. On the one hand, I think that the possibility to directly store objects in and read them from iRODS is a great feature, because it is already hard for users to wrap their head around the idea that they have to download the data to work on it and then upload the results. On the other, I'm not convinced that such a functionality should be covered by iput() and iget(), for two main reasons. First, because it then deviates from the iCommands behavior and can be confusing for users that are also familiar with iCommands. Second, and most importantly, because it makes the documentation of the function itself harder: the arguments are of different types, the return values are different... I think that the two behaviors, i.e. transferring files and saving/reading R objects, are different enough that they warrant separate functions, e.g. ireadrds() and isaverds(), or maybe iload() and isave(). This would have the additional consequence of setting apart this rirods-specific functionality from the common ground with iCommands, making it more clear and highlighting what {rirods} in particular brings to the table. Moreover, using different functions can make the choice more clear to the users: between interacting directly with iRODS but with an R-specific format, or using interoperable formats but going through the trouble of uploading and downloading. 

A related question regards the limited range of file extensions that can be successfully transferred to iRODS via rirods. Is that a limitation of the API or a {rirods} choice, and what is the reasoning behind it?


Again, thanks for working on the package. I have a few notes that can become issues on the repository, but for now our main concern is the principle of the package: is the goal to mimic iCommands as much as possible while additionally offering the option to communicate directly with iRODS, or is the direct communication and storage in RDS format a priority, as suggested by the documentation and the iput() and iget()behaviors? 


Kind regards,


Mariana

Martin Schobben

unread,
Mar 2, 2023, 10:37:43 AM3/2/23
to iRODS-Chat
Hi Mariana,
Thank you for looking into rirods. It is also very important to tackle these philosophical questions about the package now rather than later. I have to admit that I haven’t touched the package in a while, and I am not able to give a definite answer to your input.  So, I have to stay a little superficial in this brief answer. But I think I tend to agree with you and the functions should be renamed. The proposition of naming them as iCommands inspired alternatives to R’s readRDS() and saveRDS() is then probably the most elegant solution. To your second question, I did not want to add support for other extensions until I fully tested their implementations in the code (including unit tests). I wanted to expand this functionality along the way, e.g. upon request, or by contributions from outside (PRs). This probably also prevents implementation of unnecessary support for file types that are not used by R users.

You can also add these concerns in an GitHub Issue, maybe this generates more debate on the overall design of the package. I truly hope that the package will cater to the needs of R users, so such feedback is very much needed.

Kind regards,

Martin

Paul Borgermans

unread,
Mar 3, 2023, 5:41:35 AM3/3/23
to iRODS-Chat
(ignore, just a test)

Mariana Montes

unread,
Mar 3, 2023, 7:35:16 AM3/3/23
to iRODS-Chat
Hi Martin,

Thank you for your reply! We would be really interested in actively contributing to the package. Would that be possible? If so, would it be ok to set up a meeting to discuss that option?

Kind regards,

Mariana

Martin Schobben

unread,
Mar 3, 2023, 7:44:41 AM3/3/23
to irod...@googlegroups.com
Oh great! I actually wanted to suggest the same. I would be happy to discus this in a meeting.

Kind regards
Martin

________________________

Martin Schobben

Vienna, Austria

personal webpage  

Email: schobbe...@gmail.com



--
--
The Integrated Rule-Oriented Data System (iRODS) - https://irods.org
 
iROD-Chat: http://groups.google.com/group/iROD-Chat
---
You received this message because you are subscribed to the Google Groups "iRODS-Chat" group.
To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/irod-chat/b7a0de79-3cd8-432f-9ebc-6576329055e5n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages