irods
create a utility module for miscellaneous functions
There may be value in providing a namespace (irods.utility?) for free functions of high general utility in the Python client library or in applications using it. One example is make_session (which now, somewhat awkwardly, resides in irods.test.helpers).
This namespace could easily be expanded to include others in the future, like is_collection / is_data_object, etc.
Perhaps this be or become a library of free functions called irods.lib.* or similar .... See https://github.com/irods/python-irodsclient/pull/506#discussion_r1458231160
I'm a little wary of introducing a "utilities" module because those sorts of things always make me itchy, but it would definitely be useful in the short term for exposing the useful functionality. Eventually, I personally would like to see more targeted libraries which logically group together the related functions. Just my two cents.
I'm a little wary of introducing a "utilities" module because those sorts of things always make me itchy, but it would definitely be useful in the short term for exposing the useful functionality. Eventually, I personally would like to see more targeted libraries which logically group together the related functions. Just my two cents.
That's fine by me, I'm going to defer due to having no strong opinion. Are we, as a group, more comfortable with the make_session function in a README example being imported from irods.test.helpers than from a potential irods.lib? (Referencing this comment from a currently active PR)
Or... how about this: We introduce an irods.demo module from which README examples can import conveniently?
I don't think demo is the best name for this functionality. It can be viewed as toy-code (i.e. not for production use) just like demoResc.
We can move make_session into the session module. Fits the purpose of the module perfectly IMO.
Same thing for the path utility functions. They can become part of path/init.py.
Thoughts?
Wait, you're saying irods.demo would be for example code. That could work, but the functions we're discussing are very convenient and would be helpful to users.
I think moving the existing functionality into an existing/appropriate module makes sense.
