FreeCAD is pedantic about the source of its python packages. It has
been unsetting the PYTHONPATH environment variable for some time. With
the recent support for Python 3.11 they are initializing the Python
environment using an "isolated" configuration. That means our previous
approach of removing the `putenv` line from the MainGui doesn't cut it
anymore. In this commit I'm replacing the isolated configuration with
a regular configuration. This means that FreeCAD will again pickup our
PYTHONPATH.
An alternative approach would have been to pass each of our (runtime)
python dependencies with the `-P` argument to the FreeCAD binary
using (yet another) wrapper.
Perhaps the best approach, one that I might explore, is to figure out
where FreeCAD usually expects the python dependencies to be. It might
be that we can just symlink them into the package itself. One escape
hatch that has been there for a while but hasn't been used (by us at
least) is the `VIRTUAL_ENV` environment variable. We could provide an
environment to the binary and get away without patching the source
code. This requires some (new) machinery to produce virtualenv-alike
folders.
Since version 0.19, freecad can open .dwg files through libredwg. See
https://wiki.freecadweb.org/FreeCAD_and_DWG_Import#FreeCAD_v0.19_and_LibreDWG.
Before this commit, freecad could open .dwg files only if libredwg was
independently installed. This is not how programs should work in Nix.
Therefore, we explicitly depend on libredwg and hardcode full path to
dwg2dxf.
It's arguable that the FreeCAD flatmesh library should be included by default.
The upstream FreeCAD appimages are provided with this library compiled in.
See the following:
77a64701075bcddb3b86
Update pkgs/applications/graphics/freecad/default.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
When a user installs this package, it's likely they will try to run 'freecad' instead of 'FreeCAD', this symlinks FreeCAD -> freecad such that the user will not be confused and assume that installation of the package did not work properly.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
