Addon Manager Redesign 2021

[chennes]

why not see the macro wiki page (as the workbench addon display the Github page) ?

This is in process right now, I should have it in the next few days. I need to change how we show web pages.

[chennes]

Only when you have admin privileges. The issue is that it tries to gain unnecessarily admin permissions to copy a file.

I see some notes in the symlinking code, but I'm not familiar enough with it to understand yet: this is the code that's executing (it's in addonmanager_utilities.py if you want to see it in situ)

Code: Select all

            csl = ctypes.windll.kernel32.CreateSymbolicLinkW
            csl.argtypes = (ctypes.c_wchar_p, ctypes.c_wchar_p, ctypes.c_uint32)
            csl.restype = ctypes.c_ubyte
            flags = 1 if os.path.isdir(source) else 0
            # set the SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag
            # (see https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#joC5tFKhdXs2gGml.97)
            flags += 2
            if csl(link_name, source, flags) == 0:
                raise ctypes.WinError()

[chennes]

Actually, in the Python documentation they spell the situation out fairly clearly:

On newer versions of Windows 10, unprivileged accounts can create symlinks if Developer Mode is enabled. When Developer Mode is not available/enabled, the SeCreateSymbolicLinkPrivilege privilege is required, or the process must be run as an administrator.

OSError is raised when the function is called by an unprivileged user.

So in the interim since this code was written, it has become nonviable on Windows. I hate having to copy those macros instead of symlinking them, but it appears on Windows that's really the only viable path forward. I'll add code to catch that exception and copy if it's caught.

[uwestoehr]

I'll add code to catch that exception and copy if it's caught.

Thanks. I will try if it works for me as Win user-only when you committed this.

[chennes]

@uwestoehr when you have a moment can you please verify that git commit 7ea0394e9 resolves this issue? I am just guessing about which branch of the symlinking code you are running into, based on the Python docs.

Ping

[chennes]

This actually calls my attention to an uninstall problem. Right now the uninstall code works by just deleting the mod directory, but that's not really correct: it will leave dangling symlinks to these macros, and now on Windows will leave copies. I think the functioning copies is preferable, but I think when a user uninstalls a mod the AM should actually uninstall all of it, even these macros. What do you think?

[uwestoehr]

when a user uninstalls a mod the AM should actually uninstall all of it, even these macros. What do you think?

Yes, the AM should also delete these macros. Ideally everything is after the uninstallation as it was before. This helps in case there are bugs or files that have been removed in a new addon version and users need to reinstall the addon to fix that properly or to get rid of the removed addon files.

[uwestoehr]

@uwestoehr when you have a moment can you please verify that git commit 7ea0394e9 resolves this issue?

Many thanks! This works fine for me. So the issue is fixed.

[chennes]

Thanks again for the report and the testing. I have added the necessary code now to correctly uninstall these macros if they were copied in. git commit ecc6dee17

[TheMarkster]

If an addon creates parameters these should also be removed during uninstallation or at least give the user the option to remove them. I'm thinking in the package xml file the folder name and hierarchy could be given in a semicolon separated list, and then the entire group removed by the addon manager. Something like:

parameters = "Plugins/MeshRemodel;BaseApp/Preferences/Mod/MeshRemodel;Tux/PersistentToolbars/User/MeshRemodelWorkbench"

Addons should probably only use Plugins/AddonName, but FreeCAD is creating stuff, too, mainly related to toolbars. The stuff FreeCAD creates maybe can be automatically removed if it's based on the workbench name.