Port over makes essentials

[blaggacao]

I think we can ship makes-essentials such as https://github.com/fluidattacks/makes/blob/main/src/args/make-template/builder.sh direcly as outputs.library.<system>.std-nameXY. (but only the essentials to limit the scope of "opinionating")

/cc @kamadorueda @tomberek wdyt?

(poor man's implementation of env substitution)

[blaggacao]

especially [things] like runner and writers..

(from #28 / @GTrunSec)

[GTrunSec]

Yes, I agree that the makes should be a runner in std as a part of the shared library.
Because of the existing work between makes and some features, it is charming to integrate as a relatively complete runner in std. But here, I want to talk about another idea about the writer. I would like to recommend using the following tools as standard writers for a few specified languages.

1. https://github.com/kootenpv/cliche [python]
2. https://comonicon.org/stable/ [julia]

These projects have similar functional features that direct us to write standard scripts and have a beautiful input and output. Furthermore, makes and std will associate script set up a more independent environment for each command of the writer, and we don't need to write a primordial script.

The last point is about some digressions. As a Julia lang fan and comonicon inspired me, I think it is also an excellent option to use Julia to implement the function of the std. @colinxs If you could give some advice about julia to std that we can talk about in another issue.

[blaggacao]

@GTrunSec I think there is a misunderstanding, here:

• Runners: std ls #17 Just Integration #8
• makes has a nice agnostic library to use for things like injecting bash arrays etc. Things that don't work perfect in nixpkgs (or are not homogeneous)

I think it is very worthwhile indeed to provide a library of writers, starting from bash and also including some of these frameworks in elegant ways: writeClicheApplication / writeComoniconApplication.

But since there are many, many, it might also make sense to keep writers in a separate repo (with a more flexible future release cycle).

[blaggacao]

I think we don't necessarily want to recreate a task library in std. We still may provide a better integration with makes, in future, though.