FHS compliance long term project.

[bernd]

2. https://github.com/FreeCAD/FreeCAD/pull/3525

lgtm, in the regard of FEM

[bernd]

It's good, and I'm glad somebody is taking the initiative.

+1

[looo]

And the directory can be versioned too so the path could end with freecad-0.19 for example.

Restructuring doesn't make much sense if we still keep the multi-version policy. In my eyes this is not only from a python perspective but in general. If we want to gain consistency we should avoid multiple versions of freecad in the same system. The solution for multiple version is provided by snaps, flatpaks appimages, virtual environments...

[wmayer]

Another point to consider if FreeCAD should be offered for all supported Python3 versions of a system.

When looking at the official repository of Ubuntu Bionic without any external PPA I can install several Python versions in parallel. These are version 2.7, 3.6, 3.7 and 3.8.

In order to make this working correctly and avoid that with Py3.6 it loads an extension module of Py3.7 these .so files have a suffix in their file names.
For example for Py3.6 the extension module _ctypes is not simply called _ctypes.so but _ctypes.cpython-36m-x86_64-linux-gnu.so.

You get the list of allowed suffixes with:

Code: Select all

import _imp
_imp.extension_suffixes()

Or should FreeCAD only be offered for the default Python version of a system?

[hobbes1069]

If one were to drop python libraries directly into /usr/lib{,64} then I think having the python suffix would be a very good idea, but most packages (at least on Fedora) put libraries in a versioned subdirectory, i.e.:

/usr/lib{,64}/pythonX.Y/...

In which case I don't think it matters, but looking in my python3.8 directory, 60-70% of the libraries there do have the python suffix.

Thanks,
Richard

[looo]

When looking at the official repository of Ubuntu Bionic without any external PPA I can install several Python versions in parallel. These are version 2.7, 3.6, 3.7 and 3.8.

In order to make this working correctly and avoid that with Py3.6 it loads an extension module of Py3.7 these .so files have a suffix in their file names.
For example for Py3.6 the extension module _ctypes is not simply called _ctypes.so but _ctypes.cpython-36m-x86_64-linux-gnu.so.

Do we really have to support multiple python versions in one system? In my eyes that's the same wrong design as having multiple freecad-versions in one system. For sure distros simplify packaging by allowing to use different python versions, but if we talk about consistency (which this topic is about) this is not the way to proceed.

[kkremitzki]

While not essential I think it would be a nice-to-have for future potentially difficult Python version transitions.

[PrzemoF]

If FreeCAD can be run from the directory where is was compiled I don't need the ability to install multiple versions, but I'm aware that it might be nice to have for some people. Bug hunting is one obvious example.

I'd stick to the default version of python unless there are some benefits that are not obvious to me. Probably 95% of normal users don't care as long as FreeCAD works. I hope that the recent problems with python (2->3, 3.x compatibility problems, pyside2, shiboken2 etc) were something that we won't see any time soon.

[looo]

If FreeCAD can be run from the directory where is was compiled I don't need the ability to install multiple versions, but I'm aware that it might be nice to have for some people. Bug hunting is one obvious example.

I'd stick to the default version of python unless there are some benefits that are not obvious to me. Probably 95% of normal users don't care as long as FreeCAD works. I hope that the recent problems with python (2->3, 3.x compatibility problems, pyside2, shiboken2 etc) were something that we won't see any time soon.

how is the situation with fedora/centos? Are different versions of python installable side by side?

[hobbes1069]

Only with major versions, you have one python2 and one python3. Although since python2 is EOL most of it has been removed. You can still get a python2.7 if you really need it, but no guarantee on any modules/libraries being avilable.