Krita-Devbox: A complete Krita development environment in a box!

[Emmet O'Neill]

For anyone who might be interested, Eoin and I have updated the Krita
Devbox and added a bunch of new features. :)

+ 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.
+ 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.
+ Build Krita's Sphinx documentation with `krita-devbox build-docs
/path/to/krita/docs`
+ Added `--debug` and `--test` options to `krita-devbox run` which will run
Devbox's Krita with GDB and run unit tests respectively.
+ 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.
+ 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.
+ 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.
+ Added info about using a separate $HOME for the devbox to the readme.

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.
https://invent.kde.org/eoinoneill/krita-devbox#initial-setup

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.

On Sat, Jul 23, 2022 at 9:24 AM Emmet O'Neill <emmetoneill.pdx at gmail.com>
wrote:

> 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.
>
> 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.)
>
> 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.)
>
> Please give it a try and let us know what you think. Suggestions and MRs
> welcome. :)
>
> On Sat, Jul 23, 2022, 6:49 AM Dmitry Kazakov <dimula73 at gmail.com> wrote:
>
>> 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.
>>
>> The only worry I have is the shared home directory. It should be optional
>> at least, because different branches use very different configs/resources.
>>
>> On Sat, Jul 23, 2022 at 3:53 AM Emmet O'Neill <emmetoneill.pdx at gmail.com>
>> wrote:
>>
>>> Hey all,
>>>
>>> So... last weekend Eoin got a new laptop and installed Fedora Kinoite
>>> (an immutable/atomic Fedora-based OS with KDE Plasma) on it.
>>> Similarly, I've been running Fedora Silverblue (basically the same
>>> immutable/atomic OS but running Gnome) on my laptop for a few months.
>>>
>>> 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.
>>>
>>> So this week we started a little project we're calling Krita Devbox
>>> <https://invent.kde.org/eoinoneill/krita-devbox>:
>>>
>>>> Based on Distrobox <https://github.com/89luca89/distrobox> (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.
>>>>
>>>> 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.
>>>>
>>> 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!)
>>> Thanks to Distrobox it integrates with the host system in convenient
>>> ways that make it more user-friendly than working directly with Docker.
>>> 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.
>>>
>>> For example, how about `krita-devbox build --appimage
>>> /path/to/krita/source` to produce an AppImage of whatever is currently in
>>> your source tree? ;)
>>>
>>> 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.
>>>
>>>
>>
>>
>> --
>> Dmitry Kazakov
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20220728/cbc4c8d3/attachment.htm>