From the discussion in this mornings meeting with @djarecka @effigies @ghisvail @mahdieh-dst @yibeichan, I thought I would create an issue as a place for further discussion/ideas.
Nipype has the concept of min/max_ver to handle forwards/backwards incompatible changes to command line interfaces of the underlying packages (e.g. FSL, MRtrix, ANTs, etc...). We could look to adopt this logic in Pydra but there might be a better way to handle it by having separate versions of the Pydra interfaces that map to each version of the underlying package.
This could potentially be handled by
Separate packages, e.g. pydra-fsl5, pydra-fsl6, ...
Submodules of a single package, e.g. pydra.tasks.fsl.v5, pydra.tasks.fsl.v6, ... pydra.tasks.fsl.latest
A combination of these strategies plus min/max_ver
Some things to consider:
Workflows written to be agnostic to underlying tool versions
HPC users who aren't sure which version of a given package is available
From the discussion in this mornings meeting with @djarecka @effigies @ghisvail @mahdieh-dst @yibeichan, I thought I would create an issue as a place for further discussion/ideas.
Nipype has the concept of min/max_ver to handle forwards/backwards incompatible changes to command line interfaces of the underlying packages (e.g. FSL, MRtrix, ANTs, etc...). We could look to adopt this logic in Pydra but there might be a better way to handle it by having separate versions of the Pydra interfaces that map to each version of the underlying package.
This could potentially be handled by
Some things to consider: