Ticket #5559 - Splitting FreeCAD up in to smaller packages

[jmaustpc]

4. Isolation of developers in WBs forming closed groups, risks associated to departing from well established programming practices or taking diverging approaches.

I see a big risk in the long term with any 3rd party WB is that if the developer (often only one) gives up on developing it, the WB will likely bit rot into disfunctionality. If the code is in master then it is more likely to have bugs reported and there is more pressure to ensure its continued functioning.

You make many other good points. For example,

I think there are two separate "issues" to tackle Development packages or units and distribution packages.

In terms of distribution, I am a fan of keeping as much as possible in a standard FreeCAD. However, one logical splitting of the Ubuntu package might be FreeCAD without the GUI for a pure command line application and then a more commonly needed desktop version that has all the GUI stuff.

Generally I am inclined to want as much as possible in master.

As a matter of curiosity, Ship was originally a 3rd party WB, it came to master because I asked the developer if he would like to offer it, the others at the time agreed so it was accepted. There seemed to be enough people wanting to (or dreaming of) designing water craft to make sense having it.

[abdullah]

As a matter of curiosity, Ship was originally a 3rd party WB, it came to master because I asked the developer if he would like to offer it, the others at the time agreed so it was accepted. There seemed to be enough people wanting to (or dreaming of) designing water craft to make sense having it.

It was a worthy example in that argument, but it is as good as counterargument as well (if a workbench does not have exposure it may be forgotten, even when it is really valuable for a non-core task). Maybe we should start editing the "FreeCAD magazine" featuring new Workbenches, new Features, updated lists with all the 3rd party WBs... anybody here with a journalist background or interest?

[jmaustpc]

As a matter of curiosity, Ship was originally a 3rd party WB, it came to master because I asked the developer if he would like to offer it, the others at the time agreed so it was accepted. There seemed to be enough people wanting to (or dreaming of) designing water craft to make sense having it.

It was a worthy example in that argument, but it is as good as counterargument as well (if a workbench does not have exposure it may be forgotten, even when it is really valuable for a non-core task). Maybe we should start editing the "FreeCAD magazine" featuring new Workbenches, new Features, updated lists with all the 3rd party WBs... anybody here with a journalist background or interest?

Honestly I almost never use any 3rd party WB on principal, I doubt others will agree with me.

Another problem with using add-ons is how they may effect your project when sharing a file with someone else or when wanting to work on a file in a different computer, that may not have the add-on installed.

I would rather FreeCAD be a massive complex monolith with endless features to explore, but look the same, work the same and have all the same features on all systems, wherever it is installed. But then I also hate the modern idea that applications should appear like "native" applications and thus look different on different OSes etc. For example it anoys me that on stupid Apples the version data is not under the same menu as Linux and Windows etc. I doubt many would agree ....but that doesn't mean that I am wrong, just the rest of the world is wrong!

[yorik]

my opinion is basically technical: C++ modules have to be bundled into FreeCAD (too much of a hassle to recompile for every different platform out there), pure python modules can be external. But for python modules that are already there (arch, ship, openscad, etc...) it's hard to ask the authors to "take it back" and manage a repo themselves, so they are best to stay there. I can turn Arch into an external WB, if people were asking for it...

Honestly I find the current situation quite good... We have a good, complete base, and a growing ecosystem outside. We should maybe take some more actions to make external workbenches authors feel more at home and truly part of the freecad developers family, and also to make the addons installer better (ability to detect missing dependencies, notify of available update, etc) and also make the workbench documentation more easily accessable (I'm working on that in the new start center)

Maybe we should start editing the "FreeCAD magazine" featuring new Workbenches, new Features, updated lists with all the 3rd party WBs... anybody here with a journalist background or interest?

Yeah, somehting like that, make them as discoverable as the builtin ones

Otherwise, is there really a need to change? Why split things further? Nowadays the freecad package is not THAT big, compared to other packages...

[looo]

Honestly I find the current situation quite good...

I would rather FreeCAD be a massive complex monolith with endless features to explore

FreeCAD wants to give solutions for a big range of problems. These problems share common needs like a scene-graph, a scripting language, a cad kernel, a sketcher-tool and some other things (core). But most of the tools are very specific. And thats why I think "monotholitic" doesn't suite the problem FreeCAD aims to solve.

But this are basic questions which should have been solved at the beginning of the development. I think it is simple too late to change to an idealistic modular FreeCAD. Maybe the next generation FreeCAD will solve this, but such a project won't have many things in common with the current FreeCAD I guess.

Actually exactly this question led me to conda some time ago... This tool could solve the modularity-problem but seems to be not very accepted in the open-source comunity

[abdullah]

But for python modules that are already there (arch, ship, openscad, etc...) it's hard to ask the authors to "take it back" and manage a repo themselves,

I have no issues with the current state of FC. I am not pro-splitting. However, if we were to manage very high activity in those workbenches, so high it would create problems for people with FC repo r/w access (so for development), then all pure python modules could still have its separate repo, with their specific read/write rights, and STILL be a git sub-module of the FreeCAD repo. This regards only development. Distribution can still be an "all-in-one".

With this I want to point out that separate repositories is compatible with common distribution.

I can turn Arch into an external WB, if people were asking for it...

I have used Arch once, I am very happy to have it in the stock solution.

We should maybe take some more actions to make external workbenches authors feel more at home and truly part of the freecad developers family

I like your idea. There is however a difference between feeling at home and being at home. Distributing as part of FC is being at home (e.g. putting my WB as a git submodule of FC, so that it gets packaged and distributed together with FC). I get my room in the FC house, that is my family house (good that we do not have to build actual houses with walls, it would get expensive). Having the addonmanager do it is more like feeling at home when I come for a visit. Here I come back to the standard tool argument. My WB will never be a standard tool. No matter how cool it gets. Just because interoperability with other users of the standard tool.

In fact, from a distribution point of view and only thinking on the standardisation argument, it would make sense to distribute ALL together including all 3rd party WBs. This is most likely not feasible or wanted for other reasons. There Branding may be part of the solution: FreeCAD Express (what we have now), FreeCAD Complete (Everything including 3rd party, e.g. stable 3rd party, 3rd party that want to be part of it).

Anyway, feeling at home is much better than feeling an outsider or sleeping over in the car outside the house

Note: I have no WB of my own.

[looo]

We should maybe take some more actions to make external workbenches authors feel more at home and truly part of the freecad developers family

a simple step towards this idea is to have 3rd-party modules included in the freecad-organisation on github. Also some unmaintained dependencies should get a place at the freecad-organization...

[abdullah]

We should maybe take some more actions to make external workbenches authors feel more at home and truly part of the freecad developers family

a simple step towards this idea is to have 3rd-party modules included in the freecad-organisation on github. Also some unmaintained dependencies should get a place at the freecad-organization...

+1

[Kunda1]

Really good feedback generated in this discussion. Lots to consider.

[wmayer]

I think for development it would make sense to have a small core-system. Maybe without workbenches... But splitting up everything into parts, mostlikely will have the need of a good package-manager to solve all the version troubles. As long as freecad doesn't have a consistent tool for delivering packages, I would not start with splitting the sources.

But I am fine with outsourcing some pure python workbenches like ship, arch?, image?, plot.

Just to avoid any misunderstandings: the idea of splitting the FreeCAD package doesn't mean to split the source repository or the like.

All what it is about is that on Debian/Ubuntu we have a monolithic package with many dependencies and that it should be split. Modules like Ship or Plot are rarely used but depends on big packages like numpy. So the idea is to have a freecad-core package, freecad-ship, freecad-plot, freecad-fem, ... so that a user can only install the stuff he is really interested in. Then we can also have a meta-package freecad which depends on all freecad sub-packages.