Disable snap-specific modified PYTHONPATH #176
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fix Python path search order so that user Python packages have precedence over system Pyton Packages. Enable FreeCAD to use upgraded packages even if an older version is already provided by the system.
Fixes #167
Details
The Python modules search path in FreeCAD is put together on
src/App/FreeCADInit.py
. There, initially the path (as insys.path
) is set to the standard Python locations adapted to the snap environment:Afterwards, the path for each FreeCAD module is prepended to
sys.path
:Peculiarities:
FreeCADInit.py
file is converted to a C++ header (FreeCADInit.h
) at build time, which is included insrc/App/Application.cpp
The snap has a mechanism for injecting initialization Python code by adding it to the
SnapSetup/Init.py
file. As that file is installed on theMod
directory, it will be loaded byFreeCADInit.py
as any other regular module.One of the things that SnapSetup/Init.py does is to initialize the snap-specific
PYTHONPATH
. There are two issues with this:PYTHONPATH
was already initialized. Probably somewhere beforeFreeCADInit.py
was executed.SNAP_PYTHONPATH
list in reverse order intosys.path
Point 2 is the actual issue. Since it reverses the original search path and it appears before it in
sys.path
(point 1), it effectively changes the search order. The search order becomes: system paths first (/snap/freecad/1313/usr/local/lib/python3.10/dist-packages
) then user paths ($HOME/snap/freecad/common/.local/lib/python3.10/site-packages
).This means that the user can install a newer version of a package via
pip
, yet that newer version will not be used if there is an older version of the package installed in a system location (e.g. a dependency shipped by FreeCAD, such asifcopenshell
). Python will never see the newer version, as it will search the system location, find the package and load it from there.There seems to have been much care put in setting this up in
snapcraft.yaml
. So I'm not sure it's an oversight (a bug), or something that used to work in the past and it no longer does. The reverse insertion order at least seems deliberate.As such, I'd rather not remove the code, but just uncomment it for now, with a reference to this PR for more info. In case it turns out that deactivating it is causing issues.
In summary, this PR deactivates setting the snap-specific
PYTHONPATH
on startup, as there is no need to modify the already correctPYTHONPATH
being set before.