Hello Chris,

do you think any of these pieces could be moved to 'official yocto',
specifically as bitbake-layers subcommands? I read through the README,
and it seems that things like 'status' and 'run' would fit very well
there.

Also note that there's a proposal for a json schema and layer tooling
that would be provided directly in oe-core:
https://git.yoctoproject.org/poky-contrib/log/?h=akanavin/setup-layers

I can't help but say that there's a certain bit of irony in referring
to https://xkcd.com/1987/ - when introducing yet another external tool
for yocto layer management :-)

Alex

On Wed, 3 Aug 2022 at 22:21, Chris Laplante via lists.openembedded.org
<chris.laplante=agilent.com@...> wrote:

Hi all,



Today I’m excited to publish a tool I’ve been developing internally for about a year now. It is called ‘yb’, and you can think of it like a cross between kas, Google’s repo, and myrepos (mr).



Project page: https://github.com/Agilent/yb

Download it here: https://github.com/Agilent/yb/releases/tag/0.0.11



The tool is written in Rust. It is statically linked, so all you need to do is download the binary and put it somewhere in PATH.



The primary contribution I believe this tool makes is the ability to not only setup Yocto environments, but keep them in sync with the rest of your team as your product(s) evolve. This is realized via the ‘stream’ mechanism - a git repo that holds your specs (basically like kas’ configuration files). Most operations in yb automatically fetch updates to the active stream before doing anything. If you need to add or remove a layer from your build, just do it in the stream. Anyone using that stream will automatically get the update and be informed to update their environment.



I am also very proud of the ‘status’ command. It works even with vanilla Yocto environments (i.e. what you’re using today) as long as the tool can find “bitbake” on PATH. The “status” command will automatically do a ‘git fetch’ on each layer. When used along with streams/specs, it will also first check for updates to the stream.



I hope you can give it a try and let me know what you find useful/broken. It is still in relatively early development (in particular the ‘yb sync’ command) but it is already helpful for my teams’ day-to-day work.



(P.S. Please forgive the multi-mailing list post)



Thanks,

Chris

Hi Alex,

do you think any of these pieces could be moved to 'official yocto',
specifically as bitbake-layers subcommands? I read through the README, and
it seems that things like 'status' and 'run' would fit very well there.

I would agree that 'status' and 'run' would be useful additions, though I can't say I'll have time to volunteer to do it :(.

Also note that there's a proposal for a json schema and layer tooling that
would be provided directly in oe-core:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.y
octoproject.org%2Fpoky-contrib%2Flog%2F%3Fh%3Dakanavin%2Fsetup-
layers&amp;data=05%7C01%7Cchris.laplante%40agilent.com%7C533ad5afc07
54a885d7808da75907dff%7Ca9c0bc098b46420693512ba12fb4a5c0%7C0%7C0
%7C637951560728773611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
%7C&amp;sdata=hN7QRlYqAPxigCSQfNlaCM7nWZ4vvSLv5IWzckYWAFU%3D
&amp;reserved=0

I saw that a few weeks ago and it is certainly good work :). (as are the other existing solutions, like kas, whisk, etc.)

But IMHO bundling the layer setup tool inside bitbake itself feels a bit like the chicken-and-egg problem. I'd like my spec file (or JSON file, kas configuration file, whatever) to be a complete manifest of things to download. But with bitbake-layers, first I need to know the right version of poky and where to get it. Also, I think it would be hard to implement 'yb sync'-like functionality there, specifically if we wanted to be able to change between poky branches.

Overall the thing I like about yb is that it is independent of Yocto/BitBake and easier to setup. Like an IDE, I can install it once and use it across multiple projects.

I can't help but say that there's a certain bit of irony in referring to
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxkcd
.com%2F1987%2F&amp;data=05%7C01%7Cchris.laplante%40agilent.com%7C
533ad5afc0754a885d7808da75907dff%7Ca9c0bc098b46420693512ba12fb4a5c0
%7C0%7C0%7C637951560728773611%7CUnknown%7CTWFpbGZsb3d8eyJWIj
oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
000%7C%7C%7C&amp;sdata=uTq3p2HeA0Xfe3DMZ1fxkAxlHfOJNXM4za2XIC
v5OcA%3D&amp;reserved=0 - when introducing yet another external tool
for yocto layer management :-)

The irony is not lost on me :), especially given the layer setup tool conversation last month.

Chris

On Wed, 3 Aug 2022 at 23:02, Chris Laplante via lists.openembedded.org
<chris.laplante=agilent.com@...> wrote:

But IMHO bundling the layer setup tool inside bitbake itself feels a bit like the chicken-and-egg problem. I'd like my spec file (or JSON file, kas configuration file, whatever) to be a complete manifest of things to download. But with bitbake-layers, first I need to > know the right version of poky and where to get it. Also, I think it would be hard to implement 'yb sync'-like functionality there, specifically if we wanted to be able to change between poky branches.

Overall the thing I like about yb is that it is independent of Yocto/BitBake and easier to setup. Like an IDE, I can install it once and use it across multiple projects.

The bitbake-layers command is needed only to generate the layer config
file (in json format) out of an already existing yocto setup. It does
not perform the actual layer fetch/setup from the json. That's the
feature I like the most in my proposal: none of the other tools
bootstrap the config file in this way, you need to always write it by
hand.

The actual layer setup (using the json) is performed by an
independent, self-contained python script (copied from a template in
oe-core), which you can place anywhere you want (e.g. in a product
layer repo, or in a 'config stream repo'), and which does not require
an active yocto environment or a poky checkout. The equivalant of 'yb
sync' would be to pull that repo to get latest revisions of the script
and the json, then run the script pointing to an existing checkout -
it will sync everything to the revisions in json.

Alex

The bitbake-layers command is needed only to generate the layer config file
(in json format) out of an already existing yocto setup. It does not perform
the actual layer fetch/setup from the json. That's the feature I like the most
in my proposal: none of the other tools bootstrap the config file in this way,
you need to always write it by hand.

The actual layer setup (using the json) is performed by an independent, self-
contained python script (copied from a template in oe-core), which you can
place anywhere you want (e.g. in a product layer repo, or in a 'config stream
repo'), and which does not require an active yocto environment or a poky
checkout. The equivalant of 'yb sync' would be to pull that repo to get latest
revisions of the script and the json, then run the script pointing to an existing
checkout - it will sync everything to the revisions in json.

Ah, I misunderstood your approach then. That all makes sense and sounds very nice.

Chris