Extension Manager (ExtMan)

[vocx]

In the case of ExtMan, it is an external workbench, it is very easy to self-update it, I will add an option.

Yes, but the question is, what if ExtMan becomes the official addon manager, and then it lives not in the user's $HOME/.FreeCAD/Mod directory but in a system directory, /usr/share/freecad/Mod?

Then how would you update it? This is the problem with the current Addon Manager. Would you ask the user to run FreeCAD with superuser privileges one time to self update it? Is there a better solution? So this is a general question for any addon manager that is meant to be included with FreeCAD.

What I think makes some sense is that the addon manager looks for updated code in a user writeable place, and if that is not found, default to the normal code.

Code: Select all

try:
    import ext_man.updates as regular
except ImportError:
    import ext_man.regular as regular

regular.parse_page(...)
# rest of code

So, in this case, the ext_man/updates.py should exist in $HOME/.FreeCAD/Mod/ext_man to pick new code that we can easily distribute, and if there is none, it just falls back to the /usr/share/freecad/Mod/ext_man/regular.py that is static in the system.

The alternative, self-updating, would be to download and rewrite the entire /usr/share/freecad/Mod/ext_man/ directory which requires writing to system directories.

[mnesarco]

In the case of ExtMan, it is an external workbench, it is very easy to self-update it, I will add an option.

Yes, but the question is, what if ExtMan becomes the official addon manager, and then it lives not in the user's $HOME/.FreeCAD/Mod directory but in a system directory, /usr/share/freecad/Mod?

Then how would you update it? This is the problem with the current Addon Manager. Would you ask the user to run FreeCAD with superuser privileges one time to self update it? Is there a better solution? So this is a general question for any addon manager that is meant to be included with FreeCAD.

What I think makes some sense is that the addon manager looks for updated code in a user writeable place, and if that is not found, default to the normal code.

Code: Select all

try:
    import ext_man.updates as regular
except ImportError:
    import ext_man.regular as regular

regular.parse_page(...)
# rest of code

So, in this case, the ext_man/updates.py should exist in $HOME/.FreeCAD/Mod/ext_man to pick new code that we can easily distribute, and if there is none, it just falls back to the /usr/share/freecad/Mod/ext_man/regular.py that is static in the system.

The alternative, self-updating, would be to download and rewrite the entire /usr/share/freecad/Mod/ext_man/ directory which requires writing to system directories.

That is a pretty elegant solution. I like it.

[mnesarco]

Btw, what is the purpose of the blacklist?

When I Started ExtMan I found that list in the existing AddonManager (hardcoded), so in order to make ExtMan to behave as close as possible to AddonManager I ported this kind of things, externalizing as much as possible.

Some extensions are very old and have compatibility problems but still works in some cases. So those lists are there to alert the user that those extensions probably will not work in their installed version of FreeCAD.

There are actually 3 lists:
- obsolete: Not maintained extensions (probably still work)
- py2only: Extensions that not work with python3
- banned: Must not be installed (probably replaced with another extension from the same author)

[matsievskiysv]

Btw, what is the purpose of the blacklist?

When I Started ExtMan I found that list in the existing AddonManager (hardcoded), so in order to make ExtMan to behave as close as possible to AddonManager I ported this kind of things, externalizing as much as possible.

Some extensions are very old and have compatibility problems but still works in some cases. So those lists are there to alert the user that those extensions probably will not work in their installed version of FreeCAD.

There are actually 3 lists:
- obsolete: Not maintained extensions (probably still work)
- py2only: Extensions that not work with python3
- banned: Must not be installed (probably replaced with another extension from the same author)

Yeah, but banned list is not needed anymore. Incompatible addons may be just dropped from the repo. This list just prevents addon name recycling.

[Edit]
Didn't notice that this is a macro blacklist.

[matsievskiysv]

flags.json merged: https://github.com/FreeCAD/FreeCAD-addons/pull/174

[mnesarco]

flags.json merged: https://github.com/FreeCAD/FreeCAD-addons/pull/174

Great!

[matsievskiysv]

In the case of ExtMan, it is an external workbench, it is very easy to self-update it, I will add an option.

Yes, but the question is, what if ExtMan becomes the official addon manager, and then it lives not in the user's $HOME/.FreeCAD/Mod directory but in a system directory, /usr/share/freecad/Mod?

Then how would you update it? This is the problem with the current Addon Manager. Would you ask the user to run FreeCAD with superuser privileges one time to self update it? Is there a better solution? So this is a general question for any addon manager that is meant to be included with FreeCAD.

What I think makes some sense is that the addon manager looks for updated code in a user writeable place, and if that is not found, default to the normal code.

Code: Select all

try:
    import ext_man.updates as regular
except ImportError:
    import ext_man.regular as regular

regular.parse_page(...)
# rest of code

So, in this case, the ext_man/updates.py should exist in $HOME/.FreeCAD/Mod/ext_man to pick new code that we can easily distribute, and if there is none, it just falls back to the /usr/share/freecad/Mod/ext_man/regular.py that is static in the system.

The alternative, self-updating, would be to download and rewrite the entire /usr/share/freecad/Mod/ext_man/ directory which requires writing to system directories.

There could be a bootstrap addon manager that will load a real one into writable folder. This adds a possibility of having multiple addon managers selectable from application preferences.

[vocx]

... This adds a possibility of having multiple addon managers selectable from application preferences.

Please don't quote my entire post, it looks crazy.

Why would we need several addon managers? We only need one, I mean, one official.

If you want to provide an alternative, you can provide it as an external workbench, which is exactly what mnesarco is doing at the moment. But the idea is not to have multiple of them, just an official one, and maybe a way of updating it. Yes, a bootstrap mechanism is exactly what I tried to hint with my snippet.

[Kunda1]

Whats the next step for implementation of Extension Manager?
We need to get external workbenches on board for using a common manifest file ?

[mnesarco]

Whats the next step for implementation of Extension Manager?
We need to get external workbenches on board for using a common manifest file ?

Current Extension Manager does not require anything different from the AddonManager except it is QT5 Only and Python3 only.

And there are two use cases not implemented yet:

- Automatic check for extension updates
- Uninstall extensions

It does not require any additional metadata, the discussion about metadata is about how to improve the quality of extensions in general. Not about the ExtensionManager itself.