|
> I agree. And in a way this is why I find it problematic to statically > ship those wrappers when there are newer versions already available on > the CWL github. We need an update mechanism, I think, not only at build > time but also for the already installed packages - but then again, this > very much contradicts the concepts of a stable release. So, I still need > to make my mind up about this all. Yes, .cwl tool files are just part of packaging like man pages – either they should be managed by the tool itself (as with samtools), or live as Debian-augmented resources where our debian/ packaging files live. That way it can either progress with the versions of the tools – or with the packaging -version (which may just patch the upstream CWL file in the case the upstream cwl file is broken). Adding a third location (e.g. a shared GitHub repository) means you need a third version number to track; and also to make sure the CWL file itself relates to the correct tool version installed (e.g. might depend on compile options) – and not in CWL run a third-party Docker image. So I think that would easily get too murky – although of course CWL-community-wise that is what we are seeing already because neither the upstream tool nor Debian provide a CWL tool file. -- |