[QGIS-Developer] Development environment setup

[Alessandro Pasotti]

Hi Tom,

here is my setup for building with QT6 (QT5 also works):

Ubuntu 25.10
all dependencies installed from the system except for GDAL (which I build
by myself to have full control and because I am also co-maintainer of GDAL
and I occasionally do some development work on that library).

If you are in doubt about how/what to install, you can get inspired by
https://github.com/qgis/QGIS/blob/master/.docker/qgis3-ubuntu-qt6-build-deps.dockerfile
(or use the docker directly if you decide to go that way).

The environment is configured by setting environment variables in
QT-Creator and by setting the environment variables in a bash wrapper
script when I run the python tests from VS-Codium (I use QT-Creator for C++
but I prefer VS-Codium for python).

A docker also works just fine, I've used that in the past.
IMHO a VM is probably overkill (I've also used that mainly to reduce the
entry barriers for newcomers: see now abandoned
https://github.com/elpaso/qgis-dev-vagrant).

Hope this helps.


On Fri, Nov 7, 2025 at 2:45 AM Tom Christian via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Hi All,
>
> I am interested in learning more about how QGIS developers configure their
> development environments, and I would like to get some feedback on an
> alternate approach.
>
> I recently contributed my first changes to QGIS and I found the
> development environment quite challenging. While the QGIS Developers Guide
> <https://docs.qgis.org/3.40/en/docs/developers_guide/index.html> contains
> lots of information I found most of it to be high-level, e.g. how to work
> with Git, and there was limited information on gathering required
> dependencies and setting build configurations.
>
> Given the number of dependencies, the risk of conflicts with existing
> packages, and my strong preference to avoid VMs, I thought a containerised
> build environment was ideal. My work requires frequently switching between
> projects and environments. I generally cannot let any one project's
> dependencies pollute the system outside of a Conda environment, a
> container, or a VM.
>
> I found the CI Docker configuration
> <https://github.com/qgis/QGIS/tree/master/.docker> and thought I could
> use this to build and test QGIS. These Dockerfiles should guarantee all
> required dependencies AND this is the environment that passes or fails CI
> checks on my changes. Building QGIS using the CI Docker configuration was
> OK, but CI is not setup for running the build product in a container -
> meaning changes cannot quickly be manually / visually tested in this way.
> The project would have to be compiled (with the benefit of mounted ccache)
> and installed every time the container was started before the application
> could run. The long Docker commands are not currently scripted outside of
> GitHub Actions Workflows, and build configurations are provided via
> matrices, so replicating these processes locally is non-trivial.
>
> I created this repo
> <https://github.com/sparkgeo/QGIS-Container-Development> to better
> automate container-based development and testing of QGIS. It contains build
> / run / test scripts, .env configurations, and Docker Compose overrides to
> work with the QGIS CI Docker configuration with as few changes as possible.
> It currently requires a single small commit
> <https://github.com/sparkgeo/QGIS-EOPF/commit/64b6f6568ec24f9a064a24869b3d1fb95a6ae0b1> in
> the active QGIS branch to support this approach, which I removed before
> creating PRs for the main QGIS repo.
>
> With this approach, building and running a containerised QGIS development
> build is (in theory) as simple as scripts/run.sh. Tests can be executed
> with scripts/test.sh.
>
>
> I have some questions:
>
> 1) are you installing QGIS build dependencies on "bare metal", or perhaps
> using a VM?
> 2) is there a simpler approach than this for containerised builds, runs,
> and tests?
>   2a) if not, is there any interest in pursuing this or a similar approach
> to simplify containerised development environments?
>
>
> Ultimately I suspect the QGIS project would benefit from lower barriers to
> entry and the ability to better isolate build dependencies.
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>


-- 
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20251110/a2c70181/attachment.htm>