 So I'm going to talk about using DevTool to streamline your Yachto project workflow. My name's Tim Morling. I work for Open Source Technology Center at Intel. I've been involved with Yachto project and open embedded since open embedded classic days, so quite a while now. So first I want to ask, how many people have used Yachto project? Okay, everybody. How many people have used DevTool? That's exactly what I expected, okay. So that's the reason for today's talk. So what I'm going to talk about today is why DevTool, why do we create it, a review of how it works, the types of packages that are currently, or projects that are currently supported, the most common DevTool commands including demos of those, and just a little bit about how DevTool is evolving and improving. So why DevTool? What was the workflow before? Fire up your trusty editor, figure out where the recipe should go, or where is it? And then copy and paste errors, over and over and over again, odd infinitum. And then you have to figure out what is a minimum recipe to actually build, what's valid, what was that variable naming in? I really can't remember, and I didn't remember to look it up in the reference manual. How do I do it? MD5Sum in my editor, because I need licensed file checksums and source URI checksums. What's that? That is an answer, yes. The comment was run at once, and that's very true. In fact, you're going to see that later. So then you have to ask yourself, what should I inherit? Or require? Or depends? Or are depends? And some of you may not even know what those things mean, and it can be confusing. Oops, I forgot to commit that. I have no get history of all the work I've just been doing, and I really wanted that. Oops, I should have put that in a new layer, because I just put everything in tree, and that is not the right thing to do, trust me. I just want to build it. That's it. Just build it. And can I just deploy it and try it out and see if it'll work? So this was the workflow before. It was a little bit frustrating. I'm trying to be comical here. So what do we have now? So the last list on the left, we're going to tick them off as we go. So in the development phase on your host, you're going to be running DevToolAd, for instance. So this is a sub-command, which is going to create a workspace. That is going to have a recipe inside of it, and your source code inside of it. So we checked off a whole bunch of things. We got rid of copy and paste errors, because an automated system generated a recipe for you. We got rid of a bunch of these other things, right? We got rid of the minimum valid recipe. It knows about variable names, so it used the right ones and didn't misspell them. It did the MD5 sums for you on your source URI and your license files. It did a best attempt at figuring out what to inherit, what to require, what to depend, what to R depend. It starts off with a Git repo when that makes sense, and it creates a layer right off the bat. So the workspace is a layer. So this is a sandbox for you. This is for you to do your development for a short period of time before you move it to where it should really be. So I'm going to DevTool build. That gives me my binary. So that gets rid of our, I just want to build it part, right? Then we've got DevTool deploy target. This gets us to the testing phase. You actually take that binary that you built, and you SSH it or SCP it over to your test hardware or your QMU image. So that gets rid of our, I just want to deploy it. So we collect some issues, figure out some things, we go back and we edit our recipe. And we go through a loop here until this is to our satisfaction, right? So we're basically editing the recipe, maybe editing the source code, we're building it, we're deploying the target, we're checking things out, maybe you're running testing, and then we're going to edit the recipe and so on and loop back till we're happy. So now when we finally want to, and this DevTool edit recipe actually fires up your default editor for you. So now the last thing we need to do is finalize it. So DevTool finish will actually push it to the repo layer or the meta layer that you are attempting to target for this, and this is sort of the release phase. And that figures out where that recipe actually should go in that layer. It's really cool. So just a little bit of overview of how it works. And this isn't the nuts and bolts, I can get into that in detail outside of this room because it's too much detail to go into today, most people won't want to know. So let's just say we do DevTool create workspace, and then we're going to call that workspace because it's a nice name. You don't normally actually have to run this. DevTool add will run this command for you, but I just want to show you what the basic workspace is. The workspace is just a directory which has a readme in it, and it's got a config directory with a layer.conf, right, because it's a layer. So the first thing it does, it also injects itself into your bblayers.conf file, and so it added itself as a layer to your build system that you've already got going on. So let's just look at DevTool add because this is probably a pretty common command you guys are going to want to be doing. So let's say I'm going to do the hello 2.10 from Guinea, right? So what's different? This is going to put it into the workspace, a directory called appends, which may or may not be used. It's going to create a recipes directory where it's going to put the hello and the hello bb that it created. It's also going to have the sources directory, so it's going to download the tar ball, it's going to fetch it for you, it's going to uncompress it and everything, and it's going to create a get directory for you, right? It made a get repo right off the bat. So even though this is a tar ball that has no get history, it started off by creating your initial commit of get history. And it's smart enough to look at the files that are there and attempt to figure out what kind of build is this, what kind of project is this. And so in this case, it's going to look at either the config AC or the makefile.am and know that that's an inherit auto tools type of, or an auto tools type of project and so it's going to inherit auto tools. So all of that actually goes into a separate tool that's called recipe tool. And this is what actually knows how to do this stuff. So there's actually a command line you can do recipe tool create, which does all of this, the same stuff, but why do that when DevTool will do it for you? Well, how does it know all of this stuff? It knows all of this stuff because it knows about the already parsed cached data. So when you first run BitBake, it says parsing, that's the cached data. It also knows about the built package data. So if you've already been building a bunch of packages, it knows about that history and use that information to attempt to figure out what your depends, our depends, inherit, and all that stuff is going to be. And all these things are actually written into plug-ins for these tools. What kind of projects are currently supported? So we've got auto tools, CMake, Qmake, plain old make file that's been there for a long time. We can do out of tree kernels, kernel modules, sorry. We can also do binary packages. Recent addition is Node.js modules, and that's actually quite powerful. And we can also do Python modules if they use setup tools or disk details. So what are the most common commands? So I am trying to get you to walk out of this room today and go use these commands. That's what the demos are going to be for. So DevTool add, you want to create a new recipe. So you've got a local source tree. You have a internal GitHub or Git repository, whatever it is, right? You want to use that to add a new recipe. DevTool modify, you've got existing stuff that's in OECore or in some layer you're already pulling in and you need to modify the source code itself. And you want to generate all those patches. And you want those patches to go into your build system. And DevTool upgrade, this is as a layer maintainer of multiple layers actually now. This is part of my workflow is how do I upgrade to a newer version, right? So yeah, I can do that. I can download a new tar ball. I can do the MD5 checks and all that stuff myself, but why, right? So one thing I want you to get in your head is to go out and do DevTool help or DevTool sub-command, in this case add, dash, dash help. It's really, really well self-documented. I cannot stress that enough. If you can't figure out basically what you need to do from this, then just try some stuff and see if it works. But the most common thing for me is DevTool add that you or I because I'm going to go off and get some tar ball upstream. So let me ask you a question. Why are you creating recipes from scratch? Do you have extra time to spare? Because I do not. So let me do my first demo. This is DevTool add. We're going to do a complete workflow from start to finish. So this is the longest of the demos. And this is all screencast. So in my directory, I've got Pocky. This happens to be a link. And I did my OE in it. And I'm just going to give you best practices using a state mirror. So unfortunately, my ASCII Cinema did not do a great job of capturing some of the wraps. So some of these things are a little hard to read. When I put videos up to YouTube, I'll correct some of these issues. And it's a slower than I remember it, but anyway. Pretend I'm typing. So I'm just going to do a local state mirror. So I did this just by running python-m simple HTTP server in the directory where my estate cache was. I'll put that in a wiki that I'll have later. Because I want to use the model that you've got a team which is using an estate mirror that's shared amongst the team. Because I think that's the place where most people want to use it. That's my model. OK, so now I also want to get you in the habit of adding a new layer whenever you're going to do a new application. So I'm going to go through and just create a layer. I'm going to go ahead and put some metadata in there because it makes it easier to use it. And I need to add that layer into my BB layers. So I'm going to add that layer in. So here's my metafoo layer. And now I'm going to finally get to the stuff you actually care about. DevTool, create workspace with a very imaginative name. So what's in there? It's just got a cache, conf, and a workspace directory. So what's in that local.conf? There's my estate mirror stuff. You can see that it added the metafoo layer when I did the BB layers. And the build demo workspace got added in. So if I just look at that, you see what I talked about earlier, that there's a conf layer.conf to read me in there. And unfortunately, it really, really helps for the step right after I do the add when I build to target something that I've actually got something to target. And so I'm going to just use the default QMU x86 machine. And rather than build minimal, which is really hard to work with because it's an internet ramfs, and it's hard to add stuff to it, I'm going to start with. And it doesn't have much in it. I'm going to do core image full command line. And now through the magic of television, we're going to do a full build in just a few seconds here. So notice it's telling me there's nothing to add because I did dev tool build. That's because dev tool knows about its workspace and there were no recipes there. OK, so our build is done. So that was about 40 minutes on a server class machine. It'd be four hours on a laptop. So I built my image. Now I want to finally add something really interesting. So I'm going to add the nano editor because what the heck? It works. So I did cherry pick the things I'm demoing today. So I have to admit that. But we're just going to go get a tar ball from upstream. And it's going to download that stuff, create a recipe. So in my workspace, what did we add? In the recipes directory, we've got a nano folder with that nano BB recipe in it. So I mentioned that it starts off with a Git repo. So it's going to do the initial commit for you with a dummy username. So it will let you edit the recipe with your default editor. And what does it got in there? It's got things like the license and the license file checks them because it figured out by guessing what the license file was. It's telling us unknown because there's some documentation in there that doesn't have an obvious license. And here you see the beginnings of ASCII cinema not liking raps. And so anyway, so I just got rid of the unknown because we don't really need that. And you can see that it knows that it depends on glib and curses and so on. You can see that it inherited get text package config and auto tools. So all of that, this is all totally automated. I did nothing but say dev tool add. OK, so let's build it. Again, through the magic of television, we're going to build very, very quickly. But this really didn't take that long. I just sped it up in order for us to make the most of our time together today. So it's built. So it did not blow up on me, so that's a good sign. So it was valid. And in order for us to have something to look at, I'm doing run QMU, slurp public VNCs. In case I wanted to look at it, I could do so. Slurp lets me not have to do sudo to create the network interfaces. So we go ahead and run QMU. So that's going on in the background. And I'm now going to deploy to target. So right here I did come across a workflow issue when I was doing these demos. And that it wanted to default to port 22. And that wasn't going to work for me to show you anything all in one console window today. I would have had to have another window open and so on. So I actually submitted a patch upstream to add this option to use the host bind mounted port. So bind bound port. So the host 222 port goes to the target 222 port. So that's what I'm trying to do here. So because of that, it's root at localhost, not root at 192.168.72. And it tells me it successfully deployed it to the target. So it basically runs a little shell script that it escopies over and it installs everything. So I'm going to go ahead and SSH in. Again, we're using the host 222 to the port. And just to prove that I'm actually running Yachto and not cheating by using Fedora, it is the Yachto that we built just a little bit ago. And guess what? I can run nano. How long did that take? Five minutes, right? Not long. So pretty awesome. Where did it put it? Where you would expect it to be? User bin. So there's user bin nano, right? So let's get out of there. I want to clean up. I'm going to uninstall. I'm going to undeploy it. Same syntax, basically. Successfully undeployed. Again, it ran a shell script on the target. And just to feed it to death, I want to make sure you come out knowing what's going on here. Nano is no longer on the target. And as expected, it's not in the user bin file anymore. So we're happy, right? It ran. We tested it. We runtime tested it. We want to put it away. So DevTool finished nano. Put it to the metafoo layer that we created. And we're going to go ahead and clean up and remove the local workspace stuff. DevTool doesn't want to assume that it knows that you're done. And so it leaves the stuff here. But if you keep it here, it actually clutters things later on. So let's go ahead and look at the layer. And there you look. It went by too quick. But your BB recipe was created there. No, that did not remove the workspace. So I only did was remove it from the workspace so that my sandbox didn't have it anymore. Because I wanted it just to be clear. I wanted that to be in my metafoo layer as its final resting place. I don't want it in sandbox anymore. I don't want to be playing with it. I'm considering it done. I'm probably going to hand it off to my build engineer guy now. Yes, sorry. Some of this stuff I went really quick. So my apologies because I'm trying to get a lot in today. And yes. No, it's just using SSH and Scopy, SCP. That's it. That's what's there right now. Correct. At this moment, right now, what's there for simplicity because it covers most use cases. It just uses the fact that you got an SCP available. Dennis? I'm not going to show that today. I'm really happy to talk to anybody. I'm here all week. I'll be at the Yachta booth probably most of Thursday. So if you've got questions about stuff, and I know you do, just come find me. I'm really, really happy to talk you through a lot more stuff than I've got time to do today. Patches, I'm going to show you patches. But I didn't specifically do a Git repo today. So let me ask you another question. Here's another demo. Why are you modifying source code with patches with quilt by hand? You're starting to sense a theme here, right? Do you have extra time to spare? Because I sure don't. So we're going to do a little bit shorter demo. But just dev tool modify. So we're going to take a already existing recipe. I'm actually going to create one again. And we're just going to go through and we're going to modify the source code itself and generate patches, which are going to go into your build system. So same layer, or same workspace I had earlier. I do have to re-initialize environment. And just to give me something to actually work with that I know will work, I'm going to go ahead and download GNU Hello project. And we're going to build it. So it turns out the first time through, it doesn't build clean for some reason. I didn't have time to figure out exactly why. If you just build it again, it works. So sorry, hand-waving argument. So we're going to deploy to target, just because I want to see the thing I built actually works before we modify it, right? And you know what it's going to say, right? And of course, I forgot how to type the command in the right way, so I'm human. And it's not nano, it's hello. But hey, we're all friends. So we're going to deploy it. I still got that QMU machine running. So we're going to go ahead and SSH into it. So again, it just S copied in, right? They had it manifest, installed it. Hello, hello world. Hey, yay, that's what we expected. Just for cleanliness, I'm going to undeploy it. I'm also just trying to get this to sink in a little bit. Question? Probably yes. I didn't test it. I'm almost positive that is the case, because it's not a very smart mechanism that it's using. But it wouldn't necessarily clean up anything. That's the problem, right? So the reason I'm doing undeployed is it'll clean up any garbage. But I think you're probably safe. If you want to just do a really quick churn and burn, I would recommend you can just go ahead and just keep deploying. You're probably fine. So it's going to overwrite. It's going to overwrite. Yep. OK, so it ran, so we're happy. So for today's demo, we're going to finish that to our metafoo layer so that I have actually something that I can modify, right? You can probably even guess what I'm going to do to modify. So I'm going to clean up my workspace. So I'm removing that source, because I'm considering that done, right? Done with my sandboxing. DevTool reset hello. Hey, it's not there. OK, I'm good to go. DevTool modify hello. So it knows how to go and find the hello recipe, right? Because it knows about the cache data. So it's going to go ahead and do the fetch and all this stuff that it normally would do. But it's going to unpack into the workspace. And now if I look at workspace sources hello, this is where my demo, or sorry, my source tree is going to be. And it is not hello.c, it's hello, it's source hello.c. And I'm going to change world to Portland. And this is when I found out that Vim worked a lot better than Vi, which is what caused some RAP issues earlier. So I do a Git log, just to show you that it created a Git repo for me. And I'm going to do the regular Git workflow, right? DevTool is not going to replace everything, right? You've already got hammers in your toolbox. We don't need to replace all of them. But we do need to improve some of them. So I'm going to go ahead and commit. And I'm going to build, because I needed to show you what we did. Get into the magic of television, fairly quick build, deploy to target again, starting to get the pattern, right? So this workflow is pretty quick. And especially if you're using QMU or hardware that supports Ethernet, you're really going to be able to turn and burn very quickly. Just to prove, again, that we are running Yachto and I didn't use anything else. And what do you know? Hello, hello, Portland. So again, I'm a little bit anal about cleaning up, right? I don't really like dirty data around. So I personally always run, sorry for the mic, I always run a deploy target, personally. And Stefano's nodding his head up here. I'm almost positive that you don't have to do that. OK, so we're done, right? We're happy and built. We've made our changes. We're going to go ahead and finish. And what's that? Yes? Yeah, I'm going to show you that right now. I'm going to show you that right now. So I'm going to clean up my workspace again, because I am fairly anal about being clean. And we're going to go ahead and go to where that stuff went to. So here's my directory, right? I've got my hello BB append. That was, or sorry, my hello underscore 2.10 BB. That was created by the original recipe, right? Or the original DevTool add that we first did. And then we've got, let me just show you what's in that really quickly. So that's got your source URI. It's got your checksums. It's got your license and your license checksum, right? So it also created a BB append. And this is where the patch went. So here you see that it added your 0001 change world to Portland patch, right? So it just used your git commit as the name of the patch, OK? So you could have merged those together if you wanted to, right? But again, it's not assuming everything. It doesn't want to clobber everything for you. I don't remember, and there probably is. I don't know. I'm still dog-fooding this a bit myself. So yep, it's going to put the correct data where it's only going to put, in that case, the BB append and the patch to metafoo. It would leave the original alone. Exactly, yes. But I believe that there is another option, and I don't remember anything. Let me get back to you on that one. So here you just see the very, very simple patch, right? And that's the end of that demo. That's not what I wanted to do. No, I didn't want to do that either. OK, so you're definitely sensing a theme now because why upgrade recipes by hand? Do you have extra time to spare? Because I sure don't. So in this case, I'm actually going to show you an actual real layer maintenance that I just did in the last week. And I had two, but I'm not going to show you the one I did for MetaSE Linux. So it turns out that I went back and looked at a Perl module that I did about three years ago, and it had updated three months after I submitted the original recipe. Always happens. So I'm going to add the MetaPerl layer. This is also a little bit cleaner because it only depends on MetaPerl. Actually, earlier in my other workflow that I didn't show you, I had also added MetaOE just to be fully clear. But OK, so here we've got lib module build tiny Perl version .036. Turns out that three months after I submitted this, .039 came out. So what am I going to do? DevTool, upgrade, lib module, build tiny Perl because we use Debian naming, version 039. Could that get any easier than that? I don't need to know the source URI, the fetch, where it's coming from, anything. All I need to know is what's the new version. So here it's doing the fetch. And in this case, it knew to look at a GitHub repo and grab the newer version. And I'm going to go ahead and just edit the recipe just to show you that it added a new source URI and so on to this. So it's kind of boring, but so let's go ahead and build it just to make sure that DevTool is doing something good and things are building cleanly. And of course, at this moment, I would also want to run time test this, but I'm not going to beat a dead horse right now. So yes? No, it's just going to you. So actually, all it does is in place. It takes the variables that it's looking for, like source URI and license file checksum and things like that. And in place changes the value. That's all it's doing. So I'm just going to pretend that everything was great. Oh, sorry, Tom. 274 is the current version and it'll barf. But yes, it's going to figure out. Right. Right. Yeah. So there is an outstanding issue if the upstream changed to a different source URI. We don't have that yet. So if you actually need to change where it upgraded from, we don't have that. But if it's just a new regex for the tar ball or it's just a new tag for the Git repo, then it works. And it's really clean. I don't know. Sorry, I can get back to you on that. So again, I'm still kind of dog-fooding this myself. I've been preaching about using it for years and I finally forced myself to start using it in my workflow. So here's another place where my rap went bad. So I went ahead and assumed it was good and I finished it. But just to make sure, I'm going to double check and bit bake it. And there's a reason for this, because right now DevTool is not checking the license file checksum and everything properly. We have a bug open for this as well. And so it turns out when I build this, boom, guess what? The license file changed. Well, what changed? The address for Free Software Foundation changed. That's all that changed. I just did it. Yeah, I just went ahead and ran bit bake. So DevTool should be doing this in the near future. It would actually warn you that things had changed and show you the diff on the license file. OK, and again, my ASCII cinema is failing me. But basically I just went in because bit bake tells you what the checksum should have been. And I actually did go and check what it was and saw that it was just the address. And so we're going to go ahead and we're done now. So we want to go in and do our get commit. I'll build it one more time just to make sure it's clean. Sorry, I'm trying to make sure I leave time for questions at the end, so trying to power through here. And again, you would normally run time check this and everything, right? So here in the when I finished it, it put the new recipe and left the old recipe alone, right? It is not presumptuous enough to clobber your old data, right? You really wouldn't want it to be doing that. And so we're going to go ahead and get remove the old version, get add the new version. So that'll do the effect of a rename. This is not how slow I type, so I think ASCII cinema did something. Go ahead and get commit it and sign it off because this is going to the mailing list. And I'm going to write some kind of get commit, so following the open embedded guidelines. And to keep Kim happy, I'm going to tell you why the license file changed. Because I always forget to do that, and Kim always catches it, thank God. Because if this isn't in the get commit, how do we know? So basically I'm done, get send email, right? So enough of that. So that's it for the demos. Just want to talk a little bit more about how things are changed. So this came out of an OEDAM meeting back in 2013 or 2014 timeframe. And so we realized we needed some workflow tools. So the first time it was introduced was in FIDO 1.8. And then in Jethro it was improved. In Krogoth, it really actually became totally completely useful. If you are not on Krogoth, come talk to me in the hallway later on so I can help you understand how to get to Krogoth. Do not keep yourself in the dark ages, or sorry, in the older release, because you are stuck with a vendor kernel or something like that. You have reasons that you think you are stuck. I assure you they are not valid all the way across the board. It is easier to upgrade than you think. Okay, so enough of my soapbox. So in Morty, it was refined in particular in Morty is when the NPM Node.js stuff was added. Whoops. In Pyro, we polished some things up, caught some bugs and so on, because it has been getting used a lot more. So more things have been reported. And we still got 2.4, planning out for the rest of this year. So Pyro will be released in April. 2.4 will really start hitting development in June. So we got a lot of possibilities of where we could go. And I really want you guys to give us your ideas and in fact, contribute your ideas to the tool. So gratuitous plug. I didn't show it today, I was planning on it, but I had a little bit of issues. So rather than bog you guys down with those, anyway, I did the demo the way I did it. So tomorrow, Randy Witt is talking about cross-platform enabling, enablement for YAKTA project with containers. This stuff is really, really cool. Even if you're on Linux, you should be using it. It is really, really awesome. Because one of the things that happens in development workflow is you gotta control C to kill BitBake and it leaves stuff behind, okay? So this is really, really awesome. Also, tomorrow is gonna be YAKTA project, Extensible SDK simplifying the workflow for application developers. Today, I was targeting build engineers and integrators, okay? Henry is going to be talking about application developers and the rest of your team is beyond you that wants to actually use the SDK to create web spaces and things like that. Okay, so call to action. I want you guys to go out and use this tool immediately. Start using it, just start playing with it. Trust me, you're gonna save so much time. Unbelievable how much time you're gonna save. And this is open source, so please, please contribute to it. This is OECore. Yes, it was created by YAKTA project people, but it's OECore. So if you have any patches, it goes to the OECore mailing list. That QR code is that web address for where to sign up for the mailing list. Also, we've got great documentation from Scott, who's in the room, thank you. And this is the URL for that. So this link will take you to the currently released version, and this is just a show of basically, hey, what do you know? DevTool add, DevTool modify, DevTool upgrade. So again, QR code will take you to that. We also have a wiki, and Henry has created this developer workflow improvements page. I'll be adding to that after this, or during the rest of this week to add some of the stuff that I didn't quite get in yet. Just show you that. And this is a place that you can go and edit and add your own experiences and so on, or ideas and whatever. We're a community, right? So finally, I really wanna thank Paul Eggleton. He was really the main force behind this, and the original author of recipe tool and DevTool. Chris Larson, who's one of the grandfathers of BitBake, was instrumental in creating the Python plug-in that creates the Python recipes. And Leo Sandoval and others have been adding to this in the last few releases. Really wanna thank Henry Bruce, because without him, I wouldn't even have had the abstract for this talk, and he's been doing an awful lot of work for this developer workflow stuff, and it's really, really helping us out a lot. Also, I wanna thank the crops team. I was gonna show you all this done in containers. I just needed to cut, bait, and run. But it's a total mention of Randy Witt and Brian Avery. We're really, really helping out with the crops team to create the container stuff, which works really awesome. I had a minor flaw that I didn't have time to figure out. So any questions? I think we have time. Yes. What would upgrade do if it was an underscored Git recipe? It knows about Git, so it's going to actually go and figure out the, probably, head. I think there are options in the command line to tell it which specific tag you wanted or which commit issue you wanted, but you're still gonna have to do some human intervention in that regard. No, it's gonna create a BB append by default. Yes. Did you have a question? If you have multiple patches already in your recipe and you do a DevTool modify, does it apply those patches to the Git tree and allow you to, can you do an interactive rebasin and then go back and modify one of the patches and have it actually pull that back through and put that back? Basically, yes. We also have plans for adding a more interactive mode that would enable even more of that, but yes, it's gonna go and fetch and patch, and then at that point, you can apply changes on top of that. And then it'll spit out a BB append or it'll... Yes, okay. The default's gonna be a BB append. And so your new patches would go in the same directory, but the actual patch source URI would actually go into the BB append file, which you can merge yourself later on. More questions? I guess I have more to work on. Is DevTool add or is it create? Is that just like totally a wrapper around recipe tool create, or does it do really... DevTool add is totally a wrapper around recipe tool. Okay, so I'm familiar with that, so I guess I should probably be pretty familiar with it. Yes. Yeah. Any other questions? And again, if you wanna see under the hood, it's all Python, it's plugin-based, I can show you way more about that. I just didn't have time today, and I don't think that would have helped anybody. So I was trying to get you guys to go out and use this tool because it's such a time saver. I mean, I've been doing this stuff by hand for years, right? I've been preaching about using the tool and not actually using it, and I just said I have to start dog-fooding, and so I started using it and I kicked myself for the time I wasted. It's really cool. Yes. Okay, so the question is if you do DevTool add and there are dependencies that are not in the original image, would it deploy those as well? And no, it does not. That would be great. We're trying to figure out the right way to do that because it's harder than you think. And in particular, the undeploy becomes hard because you need to have a manifest. So what if your dependencies, you wanna do all your dependencies, right? So you're gonna do a simple dependency approach and you're gonna install all your dependencies onto the image, because you don't know what's on the image, right? It's just a box that you're talking to you through sCopy. So you might be blowing stuff away, you didn't intend to blow away, so you might have to store that, create a manifest of what you stored and what you blew away, yada, yada, yada. So yes, that is an obvious need, right? And I might come across that in my workup here because that's why I didn't show a live-module-pearl thing because it needed 23 dependencies, right? So yes, we're working on that as a future enhancement. That is probably another great approach. And if anybody would like to try to implement that and send patches, you know? It might, it really might. And so I mean, seriously, I know it sort of sounds funny, but if you wanted to go out and implement that or try it and send it to the mailing list, we'll make it work, right? I mean, it's a great idea, it's a great way to do it. Yes, you can only deploy what is in your workspace and so it has to have been built in the workspace and you can't build it in the workplace unless it was already there via DevTool Add or DevTool Modify or DevTool Upgrade. Indeed, you could just use DevTool Modify, don't do a dang thing to it and deploy it. It's that easy, yes, absolutely. I have done that. Yes, any other questions? Okay, so disclaimer, Intel's a trademark and there were some other trademarks in there and this was brought to you by Intel, so thank you.