A simplified Dockerfile from https://gitlab.com/daviddaish/freecad_docker_env/

[rostskadat]

Problem

The Dockerfile from https://gitlab.com/daviddaish/freecad_docker_env/ (to be included in #1 ) is complex and do not rely on the distribution's packages for its dependencies.

Solution

This updated version intends on relying as much as possible on the distribution packages in order to build the current version of FreeCAD

Tested with:

OS: Ubuntu 22.04.5 LTS
Word size of FreeCAD: 64-bit
Version: 1.1.0dev.38894 (Git)
Build type: Unknown
Branch: main
Hash: fecd8940e76b2ca3d36cee0ad859f104e1c50844
Python 3.10.12, Qt 5.15.3, Coin 4.0.0, Vtk 9.1.0, OCC 7.5.1
Locale: C/Default (C)
Stylesheet/Theme/QtStyle: unset/FreeCAD Classic/Qt default
Installed mods: 
  * Render 2024.9.25

[Zikoel]

I really want to contribute to the project and I'm searching for something like that! Thank you, I will try to use that starting from now.

[paulywill]

I honestly wish I came across this PR before troubleshooting @DavidDaish's Gitlab Docker image (#1).

It's damn intense and I've been slowly updating and confirming many of the broken links (ie. mirror downloads that are now 404) ... only half way through the Dockerfile and certainly concurring a simple version is required.

@rostskadat, any traction on the CI error?

[rostskadat]

@paulywill unfortunately it seems that the repository is kind of dead. I'm not sure how to best move forward. The PR is still standing, and I'm not sure what would be the best way to help new comers when it comes to building FreeCAD locally.

Any suggestion welcome...

[paulywill]

@rostskadat, perhaps as anecdotal rather than evidence, I did a build with the docker on my MPB which took approx >= 6 hours to do, natively building on MPB was less than 20 mins.

I initially had issues compiling from src on MPB natively with previous versions and sparse instructions and thought Docker might be a nice work around. The Developer Handbook this time around is well done and easy to follow. Thus I'm struggling to find a use case for using a Docker container (especially for those of us with MPB M1 Silicone).

[rostskadat]

@paulywill it is strange the build takes so long. Mine took also a long time the first time around. But I put that on the fact that I have a really old HP640G2. As for the native build I gave up when I couldn't get the dependencies properly installed. As for use case it could go something like this:

1. I'm a new comer to FreeCAD :)
2. I found a bug maybe or I want to quickly experiment with something new or I want to understand a quirky behavior either on the Python side or on the C++ side.
3. I do not want to install all relevant dependencies and "pollute" my system or my python install, because my distro is using some other version of some of the packages.
4. A self contained and updated build environment with debug facilities (for python at least) is a blast because I can be up and running relatively fast with whatever code is necessary for the investigation, be it main or whatever branch.

[furgo16]

@FreeCAD/maintainers @FreeCAD/sysadmins the OP has put a lot of effort in submitting this PR, which from the comments, is also well received. Could perhaps someone of you help them with a review and potentially merging the changes?

The underlying question is as well what to do with this repository, which is unmaintained. Perhaps someone wants to step in (the OP?) and become the maintainer?

On the other hand, there's also https://github.com/FreeCAD/FreeCAD/tree/main/tools/build/Docker on the main FreeCAD repo.

Thanks!

[hyarion]

As for use case it could go something like this:

1. I'm a new comer to FreeCAD :)
2. I found a bug maybe or I want to quickly experiment with something new or I want to understand a quirky behavior either on the Python side or on the C++ side.
3. I do not want to install all relevant dependencies and "pollute" my system or my python install, because my distro is using some other version of some of the packages.
4. A self contained and updated build environment with debug facilities (for python at least) is a blast because I can be up and running relatively fast with whatever code is necessary for the investigation, be it main or whatever branch.

Pixi does solve the same use cases mentioned above, but builds natively (https://freecad.github.io/DevelopersHandbook/gettingstarted/#pixi). Is there something that this docker image handles better than using pixi?

FreeCAD also has docker images in the main repo, maybe it would be better to contribute to that and archive this repository?

[kinghat]

Pixi does solve the same use cases mentioned above, but builds natively (https://freecad.github.io/DevelopersHandbook/gettingstarted/#pixi). Is there something that this docker image handles better than using pixi?

i think people dont want to be building/deving on host and would rather have it all in a containerized environment.

[rostskadat]

Pixi does solve the same use cases mentioned above, but builds natively (https://freecad.github.io/DevelopersHandbook/gettingstarted/#pixi). Is there something that this docker image handles better than using pixi?

• It is nice to be able to debug python code without the hassle of going through the whole setup.
• It is also nice to be able to switch quickly from one branch to the next (i.e. HEAD vs 1.0), but still using the same container. and thus the use of the volumes for the source and build directories.

FreeCAD also has docker images in the main repo, maybe it would be better to contribute to that and archive this repository?

That make sense. Are there any limitations about the container that are produced. Namely would it be allowed to add povray or a debugger (or any other relevant tool)?

[hyarion]

• It is also nice to be able to switch quickly from one branch to the next (i.e. HEAD vs 1.0), but still using the same container. and thus the use of the volumes for the source and build directories.

This is a good point, especially for having different branches but reusing the same deps. TIL :)

FreeCAD also has docker images in the main repo, maybe it would be better to contribute to that and archive this repository?

That make sense. Are there any limitations about the container that are produced. Namely would it be allowed to add povray or a debugger (or any other relevant tool)?

I've not used it, so I don't know.