[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Krita-Devbox: A complete Krita development environment in a box!
From: "Emmet O'Neill" <emmetoneill.pdx () gmail ! com>
Date: 2022-07-28 19:59:35
Message-ID: CANZHuebQydyaq6ZqHm5t=+UdaS-oDNvjOUJ_ct7qmCGSAQgzcA () mail ! gmail ! com
[Download RAW message or body]
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@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@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@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
>>
>
[Attachment #3 (text/html)]
<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>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic