Hi,
>> The GWL may need to acquire a few more changes before I can propose it >> as a viable alternative for the team. > > What should be these changes ? > What do you have in mind ? I honestly don’t know yet. First I should take some time to discuss with Roel, who is the original author of the GWL and asked me to co-maintain it with him. Some time ago I added support for Wisp syntax and I added a few macros to make the GWL syntax look a bit more like what people are accustomed to when working with YAML or Python workflow languages. I’d like to make a release that includes these changes. The manual certainly needs to be expanded before we can recommend the GWL to other people. (There is a website, but it is not in sync with the included manual.) The GWL needs to gain common checks to skip rules when existing results are still “fresh”. This has to be done manually now, but it doesn’t need to be this way. Another thing that I’d like to see is integration with existing application bundles. The GWL does very well by integrating Guix software deployment with the workflow definition, but it can be useful to mix and match Guix software with existing application bundles (e.g. a squashfs image containing some software). Another big thing I’d like to play with in the context of the GWL is data provenance. Can we come up with a way to track artefacts of the workflow, so that users can find out where a piece of data has come from and what its trajectory in the context of the workflow might be. Maybe there’s a chance to collaborate or integrate with iRODS. Instead of just producing files and encoding their origin and processing grade with file names we could annotate them with the help of an object storage system. I think there are still many things that we can do with the GWL that would make it much more interesting. -- Ricardo
