FreeCAD-addons
FreeCAD-addons copied to clipboard
Addon Manager behavior when addon is removed from submodules list
Recently I added Assembly4 workbench:
I initially added it as 'A4': 6914f4874bd7227082d799a873fa87aa880ddd1c
and then reverted: dacf4084d43373c0520d708c8fe1af0a1d77e91c
(didn't remove the A4/
directory though)
then I re-added the workbench as Assembl4: 321fcde29d97c1e1d7088de84aa35de0a93a9bb3
Later, kkremitzki removed the A4/ dir in: 4c2d603087a302800eec48576bc36b5969fbeb49
This caused some issues downstream for FC users: https://forum.freecadweb.org/viewtopic.php?f=4&t=39945
We may need logic in the FC Addon Manager that removes/modifies local ~/.FreeCAD/Mod/ subdirectories if their upstream has changes as well.
@yorikvanhavre just recently added a fix: https://github.com/FreeCAD/FreeCAD/commit/f66023a646
~~Not sure if this takes care of the issue.~~
Edit: the fix doesn't address the above issue
We may need logic in the FC Addon Manager that removes/modifies local ~/.FreeCAD/Mod/ subdirectories if their upstream has changes as well.
I think this is a non-issue. An external workbench should be published with a fixed name, and after this is done, it is not expected that its name will change in the future.
The problem reported in the forum occurred because a new workbench was added, first with a name, and then with a second name. But this will rarely occur. In general, developers should be asked the preferred name of their workbench before they are added to the repository; if this is done, I don't see how there will be any issues.
Also, f66023a doesn't do anything about removing folders in the local directory. It will just check the online repository. If there is a problem, it will ignore it and continue, but it does nothing about a previously installed workbench in Mod/
I think this is a non-issue. An external workbench should be published with a fixed name, and after this is done, it is not expected that its name will change in the future.
The problem reported in the forum occurred because a new workbench was added, first with a name, and then with a second name. But this will rarely occur. In general, developers should be asked the preferred name of their workbench before they are added to the repository; if this is done, I don't see how there will be any issues.
You need something more future-friendly than this outlook, the current usecase is an edgecase. As you pointed out 'But this will rarely occur.'
A more common usecase is an upstream submodules changes their name down the road. It's happened a handful of times already.
Edit: so this ticket, IMO is still valid.
A more common usecase is an upstream submodules changes their name down the road. It's happened a handful of times already.
I think this is a bad thing in general. The appropriate way to handle this would be for the addon developer to create a separate repository for the re-named workbench. Say, MyAddon
becomes MyNewBench
. Then all development in MyAddon
stops, and MyNewBench
becomes the new mainstream repository.
Then in the Addon Manager, you can add both MyAddon
next to MyNewBench
, and they can coexist in parallel. Of course, a new README file should be provided in the MyAddon
repository mentioning that it is obsolete, and urging people to remove MyAddon
and install MyNewBench
instead. Asking the Addon Manager to rename directories and all that is messy, more so if the user has added directories to Mod/
that aren't online. What happens if an online addon uses the same name that is already in the computer? Will it overwrite the local files without informing the user?
As far as I can tell, the .gitmodules
file controls how the external repositories are imported. https://github.com/FreeCAD/FreeCAD-addons/blob/master/.gitmodules
The name may be kept the same, you only need to change the corresponding url=
to point to the renamed repository. I think this should be enough to handle an upstream repository suddenly changing its name and address.
Using the new package.xml metadata file, you can change the display name of a Workbench easily, it's only the "canonical" name that must be constant. The Addon Manager will display the contents of the
I suggest changing the title of this issue: "Addon Manager behavior when addon is removed from submodules list". It isn't the AM doing the removal, and we don't store old copies of the list. So as far as the AM is concerned the WB in question is just a user-installed Addon that it knows nothing about, which of course is no error.
Then there is no reason to keep this open...right?
Well, I view it as a feature request: the Addon Manager could notice that something was removed from the list. Probably the best thing to do would be to have a "renamed" section in the JSON file or something like that.