Addon Manager does not understand renaming an addon

[luzpaz]

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: FreeCAD/FreeCAD@f66023a646
Not sure if this takes care of the issue.
Edit: the fix doesn't address the above issue

[vocx-fc]

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/

[luzpaz]

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.

[vocx-fc]

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.

[chennes]

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 tag from the metadata file regardless of the name of the directory, etc.

[chennes]

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.

[luzpaz]

Then there is no reason to keep this open...right?

[chennes]

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.

[maxwxyz]

is this still an issue or fixed with the Addon Manager overhaul?

[chennes]

Still an issue.