tempated ebuilds using jinja2

[Sławomir Nizio]

Hello,

Sharing an idea and implementation.

Some ebuilds in Sabayon are split (things like separate one for gtk, qt,
mono etc.) which is necessary in binary distributions to avoid bloat.

Maintaing such split ebuilds isn't very exciting (textual and logical
merging of changes, testing), and I'm trying a few approaches to
simplify it from different angles, and reduce mistakes.[1]

Here is one approach: all code in a single template file, with things like:

{% if pkg == "gtk3" %}

so it's like another dimension with use flags on how the package is
configured.

Constructive feedback is welcome. Anyway actual support of split ebuilds
in Portage (then Entropy) would be better. :)


https://github.com/Sabayon/sabayon-distro/commit/d9cd87cd16b1ab43ca3d9cf943757b848c4131f3

[net-dns] add Jinja2 template and gen. script for avahi

It generates exactly how the ebuilds look like for easier testing.
As stated in the comment, it can be cleaned a bit, but still it could be
easier during version and revision bumps (applying changes to ebuilds.)
Time will tell; it's an experiment, and moving back to previous
(hopefully only after due consideration!) is as easy as just starting
to use the generated ebuilds.



[1] One of them was three way merges with Gentoo using git, with rerere,
but for the most part split ebuilds differ enough to produce many
conflicts and the end result isn't as helpful as it might be.

[Ettore Di Giacinto]

+1

Really like the Idea :) Few points popped to my mind about it, feel free to ignore as necessary:

- Why jinja2? Used it at work, but really not much into it (prefer the golang built-in :P)

- I think this shouldn't be a helper, but instead treated as a first class citizien. There were discussions already on IRC for having a mirror of the Portage tree: There are few pro and cons which we are considering, this could be a even more strong point on it. 

We could even have a <tool> which is in charge of compiling the overlay from a template overlay (which can also have raw ebuilds as well) and let's say it could possibly even merge more overlays into a resulting one which is later then consumed by clients. 

Not to promote this immediately, but I see the other side of the medal, which leads to a growth of lot of scripts-doing-what-i-want in the overlay for each splitted ebuild.

Otoh we could also setup easily automation to have, let's say a "release" branch which is compiled off from master on each push and parses the existing templates. 

--
You received this message because you are subscribed to the Google Groups "Sabayon Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sabayon-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sławomir Nizio]

jinja2 is what I have already worked in the past with, [anyway] it's
standard, common, well known, which can also be said about the
language/syntax, unlike Go (when compared to Python one).

And it just works almost out of the box: equo install dev-python/jinja
is enough to get started.

Yup now generated stuff is in the VCS which is almost always a bad idea,
but still it's just an overlay, readily usable, without any magic
knowledge nor tooling required from the users.

If there are more such occurences, something like you said would be
nice, but in that case an ./autogen(erated).sh ;) overlay for
users/layman would be useful, IMHO.

KISS. :)

[Daniele Rondina]

I haven't doubts that Mudler prefers Golang! :)

Some weeks ago IIRC drobbins said on IRC channel that has begun to work in an improvement of Portage that permits to create more of one package/tarball from one ebuild, so before beginning something it's better to ask to him if could be released soon.

If this is true then we could avoid split probably.

My cent

[Ettore Di Giacinto]

Il giorno sab 9 mar 2019 alle ore 16:16 Sławomir Nizio <slawomi...@sabayon.org> ha scritto:

jinja2 is what I have already worked in the past with, [anyway] it's
standard, common, well known, which can also be said about the
language/syntax, unlike Go (when compared to Python one).

And it just works almost out of the box: equo install dev-python/jinja
is enough to get started.

That's very subjective I'm afraid :) I know that's the Pythonist inside you speaking here :P 

e.g. ERB is used as much as well

 

Yup now generated stuff is in the VCS which is almost always a bad idea,
but still it's just an overlay, readily usable, without any magic
knowledge nor tooling required from the users.

Well, it implies the knowledge of what your scripts are doing, tooling doesn't necessarly make things complex, but instead can help to hide the complexity imho.

 

If there are more such occurences, something like you said would be
nice, but in that case an ./autogen(erated).sh ;) overlay for
users/layman would be useful, IMHO. 

KISS. :)

Sure, my 2 cents were mostly on making the general approach rather then the specific (so others could pick it up as well in the long run, and not only for us) nothing really complex was proposed here

[Sławomir Nizio]

> That's very subjective I'm afraid :)

Yes, it is! :)

[André Jaenisch]

Hi,

had a look at it.
I know Jinja2 from django, so I could read it quite well.

I'd probably split the file and use includes to be able
to focus on subsets of a file at a time.

Since jinja2 is python-related, maybe ansible
makes more sense than bash?

Kind regards


Ryuno-Ki

---

Von: "Sławomir Nizio" <slawomi...@sabayon.org>
Gesendet: 9. März 2019 11:57:18 MEZ
An: sabay...@googlegroups.com
Betreff: [sabayon-dev] tempated ebuilds using jinja2

[Sławomir Nizio]

> Hi,
>
> had a look at it.
> I know Jinja2 from django, so I could read it quite well.

That's good to hear.

> I'd probably split the file

I admit it's a little messy and doing how you suggest would improve on
that, but having a few files (split ebuilds) was one of the things that
made applying changes from upstream less comfortable. [1] So at least
for me, single file has a benefit on its own.

> and use includes to be able
> to focus on subsets of a file at a time.
>
> Since jinja2 is python-related, maybe ansible
> makes more sense than bash?

It has to be bash as ebuilds are generated from it, and they use bash.



[1] For example, doing (context aware) search-and-replace in one editor
buffer should be easier than doing the same with multiple files.