Clearly we have very different definitions of what convenience is.
This is maybe because I am not a professional software developer and only write code to solve my own (and my business’s) problems (although I do work with some professinal devs for the more “professional” stuff), but the workflows you describe seem positively ghastly to me… As a possible consumer of this library, the idea that I would have to download any kind of software outside of what Mix already does for me, make sure it’s added to the path, etc. is a very, very big inconvenience. I envision this library as being useful for someone who wants to do some logic programming from Elixir, not necessarily someone who needs a super safe setup for production deployment (and you can get that safety once I implement the flags to avoid downloading the binary). The user I have in mind doesn’t need to know anyting about containerization.
To me, convenience is not having to leave the comfortable world of a mix.exs file and have everything work automatically and in which stuctured data is passed in a sane way between functions or sent as a message through processes without (god forbid!) ever having to use something like a unix shell where bash scripts receive and output somewhat free form plain text that is sent to some other bash scripts or weird unix utility that people insist on using as a library when the API is actually much closer to that of a command line application. To you, using the OS outside the BEAM is convenience… To me, using the OS outside the BEAM and integrate it with the BEAM is the definition of inconvenience…
I do acknowledge your arguments, and I will work to make the applications usable without downloading anything at compile time, because I’d like to have as many people using (and contributing!) to this library as possible, but keep in mind that our notions of what is convenient are very different.
