Meta issue: how much hope should I place in biomake, realistically?

[rulatir]

I actually use biomake in a company project.

Biomake's "selling points" for me are those of make, combined with biomake's ability to use hashes.

The make selling points are mainly those that pertain to rapid prototyping of a build specification:

• absence of the insufferable theoretically-informed opinionatedness of the more modern build tools
• in particular, absence of sandboxing
• shell-first syntax of build spec language, where a command that executes a build step can be basically pasted verbatim into the build spec file, without having to manually parse it into an array of quoted strings (which often necessitates escaping characters in those strings) or writing a separate description of a build tool - all of which the modern build systems tend to require
• writing recipes for types of transformations that the builder's authors didn't specifically foresee is not an order of magnitude more complicated than for types of transformations the builder is typically used with (e.g. *.c -> *.o)

However, there are many outstanding issues with biomake, relating to missing functionality and usability. I even wrote a preprocessor to overcome #79, but there are other issues like #81 and #82 that cannot be solved in this manner, and usability issues like #80 that make debugging of build specification bugs very difficult.

I understand that biomake was developed by a specific team for a specific use case, and issues that don't harm that use case have very low priority for biomake authors. I would like to argue however that biomake could be much more than what it currently is. A compatible "make with hashes" is something lots of people would happily use. Normally in the open source world those users would participate in the development of the tool. Unfortunately biomake is written in an almost esoteric programming language, which results in most of those potential users being unable to contribute. As a result, the only hope for most users that those issues will ever be addressed is in the possibility that biomake authors might dedicate time to solving issues that don't directly pertain to their own use case.

So here are the questions:

• how realistic is that hope?
• how would the answer change if sponsorship could be secured?

[ihh]

Sadly, I think taking three years to reply to this issue is itself an answer. I expect any hope is long dead but I will reply anyway.

I wish @cmungall and I had time to maintain biomake. I appreciate your opinion that it could be much more than what it is. Unfortunately you are also absolutely correct that Prolog is almost esoteric at this point.

I think @cmungall and I perhaps originally started Biomake to make some kind of abstruse point about how GNU Make and Prolog had commonalities (both being declarative languages), and because we both actually used GNU Make quite a lot and felt that it was an interesting exercise to see how far we could push it.

At this point I can't imagine dedicating serious time myself to maintain it. There are just too many other things to do. It is a pity.

Sponsorship... well, if we could find a Prolog programmer.....

[rulatir]

Meanwhile I wrote my own build system in JS. Thanks for the response!

[malcook]

FWIW: I too have hoped that this project might get more traction and have watched this issue for some years.

In the mean time I have remained an adherent to GNU Make, and have had some interesting experiences learning how to:

• change the .SHELL from bash to an Rscript call allowing recipes to be written in R an be executed in a running RServe process
• change the .SHELL to a srun "on the fly" when the makefile is being executed in a slurm allocation (also allowing for task/rule specific resource allocations)
• craft macros allowing use of "test anything protocol" to prove tests
• write "generic" help targets which extract help-text from in-line annotated comments

But I remain interested in other workflow management systems & formalisms (Toil, CWL, nextflow, Guix Workflow Language, etc), and am especially interested in how to stay abreast of the directions @cmungall and @ihh are finding most fruitful these days...