Root collection `/` contains itself in the subcollections

[chStaiger]

I am using the PRC 2.0.1 and I found this behaviour:

>>> coll = irods_session.collections.get("/")
>>> coll.id
10003
>>> coll.subcollections
[<iRODSCollection 10003 b''>, <iRODSCollection 10004 b'tempZone'>]
>>> coll.subcollections[0].path
'/'

It seems that the root collection contains itself as subcollection.

[trel]

Oh, well that's neat. Hmmm....

[d-w-moore]

Yep, probably because:

$ iquest "select COLL_NAME where COLL_PARENT_NAME = '/'"
COLL_NAME = /
------------------------------------------------------------
COLL_NAME = /tempZone
------------------------------------------------------------

which is a very special case (only one collection is its own parent, and that's "/") so just excluding '/' specifically from the query should work just fine.

On the other hand:

$ cd / ; cd .. ; pwd
/
$ icd /
$ icd ..
 ERROR: parseRodsPath: parsing error for /..
No such collection: /..

[chStaiger]

I see. Maybe it should not be excluded from the query but just from the explicit listing of the subcollections in the PRC? From a user/scientific programmer perspective these are two different things for me. Explicitly calling subcollections I expected to get all members of the collection. While indeed, as a user, when I do iRODS path operations, it would be nice to behave similarly to pathlib or linux paths.

The iRODS Query I see as a sort of a backend function that gives information which then needs to be tweaked towards the user API call goal, i.e. list sub collections and return parent path.

I hope that makes sense and it is strictly from a programmers and user perspective.

[trel]

I think I agree. PRC could exclude the / from the subcollections method easily enough...

https://github.com/irods/python-irodsclient/blob/d4756797fff964a01bbd90488383a4930683fb18/irods/collection.py#L50-L53

[d-w-moore]

Yes, agree, also. And with 'sub' being part of the name, some developers might expect to be able to write collection iterators or iterating functions where the subcollections member can be depended to be a proper subcollection of the parent. (In the mathematical sense of "proper" e.g. "proper subset"). That should be allowable, with no members of subcollections being 'equal' to the parent, otherwise the developer gets an infinite loop calling the iterator on the root collection.

[chStaiger]

Yes, agree, also. And with 'sub' being part of the name, some developers might expect to be able to write collection iterators or iterating functions where the subcollections member can be depended to be a proper subcollection of the parent. (In the mathematical sense of "proper" e.g. "proper subset"). That should be allowable, with no members of subcollections being 'equal' to the parent, otherwise the developer gets an infinite loop calling the iterator on the root collection.

Indeed I also noticed that in a never-ending while loop :)

[alanking]

@d-w-moore - Please close if complete. Thanks!