You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're going to be expanding that state mapping to include severity ordering, and I'm planning to wrap all of these (strings, severities, constants) up in a class so we can define comparison functions for the severity ordering and simplify state stringification.
That would be more easily done outside the scope of "DRMAA job runner" initialization linked above, but unfortunately, drmaa may not be importable outside of that scope. This leads me to two questions:
Would it be possible to make drmaa.const importable without a libdrmaa? Or...
Would you be interested in incorporating the higher level state wrapping I am planning to write for Galaxy directly in to the drmaa library?
I'm happy to submit a PR for either, if either sound good to you.
The text was updated successfully, but these errors were encountered:
@natefoo, as I've tried to make clear in other issues, I don't actually use this library anymore (because I don't use a DRMAA compatible cluster). I know many people find it useful (as I did when I was using the appropriate cluster), so I'm happy to review and merge PRs as necessary.
That said, let me answer your questions:
That seems totally reasonable.
I try to keep this library as system agnostic as possible, so a higher level wrapper for Galaxy should probably be a separate thing.
Sounds good. I might be interested at some point in the future especially if I had some reason why I needed to make some major changes or if you were no longer able to review PRs. Anyway, I'll PR my first suggestion.
In the application I develop on, we delay importing drmaa so that
$DRMAA_LIBRARY_PATH
can be set in the application config. We also map the state constants to corresponding strings.We're going to be expanding that state mapping to include severity ordering, and I'm planning to wrap all of these (strings, severities, constants) up in a class so we can define comparison functions for the severity ordering and simplify state stringification.
That would be more easily done outside the scope of "DRMAA job runner" initialization linked above, but unfortunately,
drmaa
may not be importable outside of that scope. This leads me to two questions:drmaa.const
importable without alibdrmaa
? Or...I'm happy to submit a PR for either, if either sound good to you.
The text was updated successfully, but these errors were encountered: