<div dir="ltr"><div>For anyone who might be interested, Eoin and I have updated the Krita Devbox and added a bunch of new features. :)</div><div><br></div><div>+ Rewrote the `krita-devbox` interface script in Python, added a lot of new CLI subcommands and options, which are all documented in the `krita-devbox --help` page.</div><div>+ More flexible building and packaging with `krita-devbox build /path/to/krita/source` with arguments for which phases of the build process to do and not do. (For example, `krita-devbox build -aBC /path/to/krita/source` will skip cmake and make, then simply package an appimage from an existing build). Also added a `--fresh` option to perform a full rebuild.<br></div><div>+ Build Krita's Sphinx documentation with `krita-devbox build-docs /path/to/krita/docs`</div><div>+ Added `--debug` and `--test` options to `krita-devbox run` which will run Devbox's Krita with GDB and run unit tests respectively.</div><div>+ Added `krita-devbox goto` command with subcommands like `krita-devbox goto bug 123456` to open a browser to Krita bug 123456, `krita-devbox goto mr 1234` to browse to merge request #1234, and others.</div><div>+ Added `krita-devbox clone /krita/project/dir/of/choice` command to quickly `git clone` Krita source and docs repos when setting up dev environment from scratch.<br></div><div>+ Added a `--deps-path` option to the `krita-devbox-init` script so that you can manually supply persistent dependency tar instead of having it be automatically downloaded on first Devbox enter.<br></div><div>+ Added info about using a separate $HOME for the devbox to the readme.</div><div><br></div><div>Right now I think the best way to update Krita Devbox is to remove and create again using the same two commands that are listed in the "Initial Setup" section here.</div><div><a href="https://invent.kde.org/eoinoneill/krita-devbox#initial-setup">https://invent.kde.org/eoinoneill/krita-devbox#initial-setup</a></div><div><br></div><div>I've also added a short blurb about Krita Devbox to the "Specialized Ways of Building Krita" section of the "Building Krita" page of the Krita documentation.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 23, 2022 at 9:24 AM Emmet O'Neill <<a href="mailto:emmetoneill.pdx@gmail.com" target="_blank">emmetoneill.pdx@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">Dmitri: you'll see that It's a fork of your Docker setup mixed with the KDE appimage docker, and then modified to make workflow a bit more distrobox friendly. </div><div dir="auto"><br></div>Shared home is optional using the '--home' option during the 'distrobox create' step. (In this case, distrobox still has access to the host user's home, but the guest home can be put elsewhere.)<div dir="auto"><br></div><div dir="auto">Eoin and I went back and forward about where a separate home would be smart to use by default or not, and I still don't really know. For now we've opted for going as simple as possible, but there are possibly bugs. (I've been using an ubuntu distrobox with shared home on silverblue for a while now without issue, but I could be overlooking something.)</div><div dir="auto"><br></div><div dir="auto">Please give it a try and let us know what you think. Suggestions and MRs welcome. :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 23, 2022, 6:49 AM Dmitry Kazakov <<a href="mailto:dimula73@gmail.com" target="_blank">dimula73@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Sounds promising :) If distrobox solves the integration problem between the host and the container, it could give us some benefits. Right now, integration of the GPU drivers is the biggest problem.<div><br></div><div>The only worry I have is the shared home directory. It should be optional at least, because different branches use very different configs/resources.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 23, 2022 at 3:53 AM Emmet O'Neill <<a href="mailto:emmetoneill.pdx@gmail.com" rel="noreferrer" target="_blank">emmetoneill.pdx@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hey all, <br></div><div><br></div><div>So... last weekend Eoin got a new laptop and installed Fedora Kinoite (an immutable/atomic Fedora-based OS with KDE Plasma) on it.</div><div>Similarly, I've been running Fedora Silverblue (basically the same immutable/atomic OS but running Gnome) on my laptop for a few months.</div><div><br></div><div>This got us thinking about ways that we might be able to improve the containerized (Docker-based) Krita development workflow that Dmitry has been using.<br></div><div><br></div><div>So this week we started a little project we're calling  <a href="https://invent.kde.org/eoinoneill/krita-devbox" rel="noreferrer" target="_blank">Krita Devbox</a>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p dir="auto">Based on <a rel="nofollow noreferrer noopener noreferrer" href="https://github.com/89luca89/distrobox" target="_blank">Distrobox</a> (which manages Docker/Podman containers), Krita Devbox is intended to provide a consistent and easy-to-use development container that comes with everything you need to develop Krita, write documentation, produce AppImages, and so on. A key goal for Krita Devbox is to be as simple to setup and use as possible by integrating with the host system (when it makes sense), and otherwise exporting a flexible, human-readable interface to the host system.</p>
<p dir="auto">Also, while Krita Devbox is being made with atomic operating systems like Fedora Kinoite/Silverblue in mind, we hope it'll be useful in the future to anybody who is interested in developing for Krita.</p></div></blockquote><div>There are still some kinks to work out and I'm sure a lot of improvements can be made, but the basic idea is that in just a couple of commands you can get a fully functional Krita development container up and running. (Even on an atomic OS!) <br></div><div>Thanks to Distrobox it integrates with the host system in convenient ways that make it more user-friendly than working directly with Docker.  <br></div><div>We've also made a `krita-devbox` helper script that is meant to do a lot of common Krita dev tasks in a single command.</div><div><br></div><div>For example, how about `krita-devbox build --appimage /path/to/krita/source` to produce an AppImage of whatever is currently in your source tree? ;)<br></div><div><br></div><div>Eoin and I will probably be using this heavily in the future for our Krita development, and I hope you'll all check it out and let us know what you think.<br></div><div> </div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Dmitry Kazakov</div>
</blockquote></div>
</blockquote></div>