Namespaces can exclusively be used during rendering, which is fine if
you remind yourself of the newline rules.
However, I also need some utiltiies that convert input data. These
are now within their own libraries, which can be used from python blocks
like the ordinary python functions they are.
Quite neat.
In future, most of the functionality will be in separate namespaces,
the top-level will just assemble the main library file, usnig the
provided %defs. That way, the main file is kept clean.
It's quite final, and super easy to change and to read.
It seems we want to use namespaces/shared implementations soon to allow
using defs. In our case, we transform the version in a particular way,
which is easy enough, yet I'd like to use it to make the system more
powerful.
That way, we read the data files only once, but produce all the outputs
we need. Together with a powerful makefile, we have a multi-invocation
with proper depedency tracking.
Everything will be regenerated though, even though just a single input
template file changed.
The alternative would be to have one dependency and invocation per
input dependency, but that will read the entire json each time.
Let's see what's faster/more useful during development.
Now we can write mako templates, with a similar feature set as
pyratemp. Except that its syntax is nicer, allows to do everything
and that there is syntax highlight support.
Let's see how it fares
After minor modifications to pyratemp, it certainly does the job.
What it **does NOT** do:
* multiple outputs per template/command invocation
* NICE embedding of code (like GSL can)
It will do the job nonetheless, but mako might be worth a look
As GSL failed in my first attempt to get the example program going,
it might be better to try something else before too much time is spend.
Fortunately, pyratemp **seems** to be something usable, and even if not,
it might be possible to make it usable as it's just a 'simple'
python script that I might be able to understand, if need be.
Added all prerequisite programs in binary for easier use.
Make is now implemented top-level, and is not expected to do too much
work actually. It will, however, keep track of all required
gsl invocation and make sure calls are efficient by not having
to rebuild everything every time. That's what make does, anyway ;)
That will allow interaction between client and authentication attempts.
It also shows how cumbersome it is to deal with all these
generics ... but hey, you gotta do what you gotta do.
If boxes of pointers would be used, it would be easier to handle, but
enforces a certain memory model. That, of course, is not desired.
That way, it will remain clearly documented how to do this, and allow
for efficient calling of gsl as well, at some point.
Of course it will be a little more difficult for us to know all
dependencies, but gsl could generate these as well for us, I suppose.
Now it should be possible to implement first version of actual
insert handling, with everything there is about it.
That should eventually help to generalize it, as I am definitely
not going to hand-implemented these protocols ... .
The great thing is, that if done right, one will be able to truly be
first and make an impact !
As there will be plenty of types, it will be better to split it up.
Also learned something about self::<submodule> :).
Insert and and update should be hand-implemented just to see how it's
working. Then there should be some investment to auto-generate this
with `gsl`. Once the latter works ... I could auto-generate all apis,
or adjust the go generator to create rust instead.
Depends on what will be faster ... .
There is a central `YouTube` type which helps constructing various
sub-builders, which in turn provide individual functions.
Architecturally, it's very similar to the go implementation, but
more efficient memory wise.
