ok the question is: why calling workbenches freecad.<wokbench_name>?
I found this naming convention very convenient:
freecad.gears is a namespace module. This means it extends the freecad namespace. So in python you import the freecad relevant stuff via:
or:
which is nice as the freecad.gears module is only useful with freecad. Without freecad there is not much you can do with this module. But on the other hand the module has no differences compared to a normal python module. So combining the worlds of freecad-packaging and python-packaging.
With this structure it's possible to create a pipit package for the freecad.gears workbench or create a condo-package... This is especially nice if you have a lot of dependencies. Yeah, the add-on-manager can handle also pip dependencies, but for a lot of dependencies I would not trust this process and use alternative ways to install the workbench. For example this is done with the freecad.glider workbench. This is basically a freecad-gui for openglider. This workbench is not available via the add-on-manager because handling the dependencies is a nightmare. Also via pip this is not so easy. So there is the possibility to install freecad.glider via the conda-packagemanager...
I was never very happy with the add-on-manager. This is just another solution for a problem that was already solved (or partially solved, packaging in general is not so easy with python
). In my eyes it would be better to distribute packages via pip or conda and create a gui in freecad for these package-manager...
As you can see with freecad.gears I introduced some changes for the latest FreeCAD main-brach (yes it's now called main, not master anymore). So there are issues with older versions of freecad and the freecad.gears workbench. Adding version checks like this [1] solves this issue, but this is not very nice. It would be nicer to handle this with different versions of the package.
Additionally the add-on-manager format added a version for packages. Again python has a way to do this already... So now there are two versions to keep updated instead of one [2, 3]
But it is what it is. There is the option to distribute via add-on-manager (which is nice for development, and fast for testing), then there is the option to distribute with pip, conda for more advanced packaging and for sure you can also distribute with system-package managers...
So accepting that the packaging world of python, freecad and in general is a little bit messy and use what fits best for you.
Regarding the naming of freecad.gears: In my eyes this is a good way to name freecad extensions. And if all would use name-space modules and extend the freecad-namespace this would be a great solution (we discussed this in the past: search for namespace, name-clashes ...) But it's up to everyone to use what fits best and accept and expect a little bit of mess in the open-source world
[1]
https://github.com/looooo/freecad.gears ... f8803d157d
[2]
https://github.com/looooo/freecad.gears ... fe9378e45d
[3]
https://github.com/looooo/freecad.gears ... d1572d52f7