[Feature request] Let Addon Manager show current and available version of an add-on

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: [Feature request] Let Addon Manager show current and available version of an add-on

Post by Zolko »

mnesarco wrote: Sun Jul 04, 2021 6:18 pm I started the ExtMan project with the idea to make a next generation Extension Manager for Freecad.
I'm not sure that creating a new tool from scratch because the existing tool isn't perfect is the best approach.

Most of the problems of extension managers can be solved just with proper Metadata.
...
ref: Metadata thread: https://forum.freecadweb.org/viewtopic.php?f=10&t=57448
Yes, I think that this metadata thing was the original idea of this thread.

chennes wrote: Sun Jul 04, 2021 7:40 pm See also Pr 4787: https://github.com/FreeCAD/FreeCAD/pull/4787

…which includes a first cut at implementing the metadata format we discussed.
I think that the metadata description is way too complicated, overengineered.

The metadata file must be a valid, well-formed XML 1.0 document. It must be called "package.xml"

Code: Select all

<version>1.0.0</version>
<maintainer email="email@freecadweb.org">No Maintainer</maintainer>
<url type="repository">https://github.com/FreeCAD/FreeCAD</url>
can you imagine the amount of SPAM the maintainer would get with his email in clear like this ? Also, it's not logical to keep the URL of the package and the version in the same file: the AddonManager (or whatever its name) must know the URL to know where to fetch the package from, but the repository needs to provide the version.

The original request was to be able to identify installed and available versions of addons. This is some sort of metadata, but please, make this simple. The AddonManager needs to know:

- the name of the extension (workbench, macro, preference pack ...)
- the URL and protocol to fetch it (doesn't have to be git)
- an icon (optional)
- a description (optional)
- the currently installed version (optional)

The package needs to provide :

- the current version
- the license
try the Assembly4 workbench for FreCAD — tutorials here and here
User avatar
mnesarco
Posts: 446
Joined: Thu Mar 26, 2020 8:52 pm

Re: [Feature request] Let Addon Manager show current and available version of an add-on

Post by mnesarco »

Zolko wrote: Sun Jul 04, 2021 8:14 pm I'm not sure that creating a new tool from scratch because the existing tool isn't perfect is the best approach.
Well, the good thing about extensions is that they can be used by people who likes them and ignored by the rest ;)

I was intending to move the Extension Management to a next level, but I failed, and the current solution (AddOnManager) is very fragile (I know its code very well), but the same problems will be present in any extension manager if things are not standardized and enforced, relaying on parsing external wiki pages and html is not a good thing and adding features on top of that will lead to more maintainability problems.

But if people is happy with that there is no reason to bother with things like ExtMan, it is an external and unimportant project.
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: [Feature request] Let Addon Manager show current and available version of an add-on

Post by Zolko »

mnesarco wrote: Mon Jul 05, 2021 12:31 am Well, the good thing about extensions is that they can be used by people who likes them and ignored by the rest ;)
I might have misrepresent my opinion: I think that a (good) addon/extension manager is an absolute requirement for FreeCAD, it's one of its mains strength (heck, I'm doing an external workbench, and using several others also).

What I wanted to say, probably badly, is that you have penned the real problem behind the current AddonManager, as has the initial thread beginner: the missing of structured and homogeneous metadata for such external addons. Thus, the problem doesn't come from the current AddonManager itself, and making a new ExternalManager with the same lack of coherent metadata won't solve the problem.

Therefore, I think that the really good solution is to decide what sort of metadata external modules should carry, and THEN to adopt the existing AddonManager to this new metadata. While I understand that the current AddonManager has its issues, it's also not too bad and working most of the time (for me). If you know its code well, your time might be better spent improving it rather than creating a new tool from scratch. That's all I wanted to say. Oh, and also that please, make that metadata-thing as simple as possible.
try the Assembly4 workbench for FreCAD — tutorials here and here
a.l
Posts: 86
Joined: Thu Apr 09, 2020 7:14 pm

Re: [Feature request] Let Addon Manager show current and available version of an add-on

Post by a.l »

Mnesarco I think you have some good reflections and lists in your post https://forum.freecadweb.org/viewtopic. ... 04#p514536

I guess to get many people to agree is likely difficult so to get consensus/getting started maybe break the project down either with your extman or the original add-on manager broken down so that:
  • Add-on (package) devs know that going forward there will be changes coming - not like a big bang where everything is changed at once, but where most needed properties/features are handled first.
  • Maybe handle github only to begin with if packages from other sources (multichannel) takes more time to implement. So other sources will be later on.
  • Lay out for add-on/package devs what the requirements are now, and in what direction things are going in the future so that they are aware of that in good time and - if they like/need to - can object/ask questions/make comments.
  • The extra features such as searchability, flags and voting (which is like good meta data for how useful other find a package) could maybe be delayed.
  • Maybe you guys that are going to implement it consider how much time you max want to spent on an initial release/update of either current add-on manager or ExtMan so that it helps getting to set a scope of which features are pushed for later. Personally I would rather see a smaller feature set to begin with if that yields that the ⚽ gets rolling. Because the other features will come later for sure because they are useful :)
  • So maybe just agree which types of stubs/types of data structures you would like to use and then make a minimal workable solution for the initial release that the add-on devs/creators can try out while the old add-on manager wont break because the (new) meta-file(s) for holding data will not have an impact of the old add-on manager (I guess).
Thanks for your time and efforts guys!
User avatar
mnesarco
Posts: 446
Joined: Thu Mar 26, 2020 8:52 pm

Re: [Feature request] Let Addon Manager show current and available version of an add-on

Post by mnesarco »

Zolko wrote: Mon Jul 05, 2021 9:07 am Therefore, I think that the really good solution is to decide what sort of metadata external modules should carry, and THEN to adopt the existing AddonManager to this new metadata.
Chennes have added a metadata standard to the core: https://forum.freecadweb.org/viewtopic. ... 8&start=40 I have not worked with it but it looks promising. The thing with standards is that they need to be enforced it to make it standard.

Zolko wrote: Mon Jul 05, 2021 9:07 am ...If you know its code well, your time might be better spent improving it rather than creating a new tool from scratch.
Because I know its code is why I don't want to waste my time with it, so I decided that creating something from scratch was a better investment of my time. Sometimes different approaches requires different roots, That is why we have 4 Assembly Workbenches maybe. Anyway the ExtMan project is a Proof of Concept thing, once the Chennes's metadata becomes a real standard (used by all extensions), 60% of the extman code can be removed.

but... My personal feeling is that the right direction is to have a real Freecad Extensions Portal where extensions developers publish and users explore and install from. Something like an App Store. In that portal we can run some validations and even auto generate some missing metadata and track versioning providing a centralized API to access from freecad.
screenshot_12.png
screenshot_12.png (29.92 KiB) Viewed 1221 times
This is just my point of view.
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: [Feature request] Let Addon Manager show current and available version of an add-on

Post by Zolko »

mnesarco wrote: Mon Jul 05, 2021 1:14 pm The thing with standards is ....
obligatory XKCD reference
Image
try the Assembly4 workbench for FreCAD — tutorials here and here
User avatar
mnesarco
Posts: 446
Joined: Thu Mar 26, 2020 8:52 pm

Re: [Feature request] Let Addon Manager show current and available version of an add-on

Post by mnesarco »

a.l wrote: Mon Jul 05, 2021 12:38 pm Mnesarco I think you have some good reflections and lists in your post https://forum.freecadweb.org/viewtopic. ... 04#p514536

I guess to get many people to agree is likely difficult so to get consensus/getting started maybe break the project down either with your extman or the original add-on manager broken down so that:
  • Add-on (package) devs know that going forward there will be changes coming - not like a big bang where everything is changed at once, but where most needed properties/features are handled first.
  • Maybe handle github only to begin with if packages from other sources (multichannel) takes more time to implement. So other sources will be later on.
  • Lay out for add-on/package devs what the requirements are now, and in what direction things are going in the future so that they are aware of that in good time and - if they like/need to - can object/ask questions/make comments.
  • The extra features such as searchability, flags and voting (which is like good meta data for how useful other find a package) could maybe be delayed.
  • Maybe you guys that are going to implement it consider how much time you max want to spent on an initial release/update of either current add-on manager or ExtMan so that it helps getting to set a scope of which features are pushed for later. Personally I would rather see a smaller feature set to begin with if that yields that the ball gets rolling. Because the other features will come later for sure because they are useful :)
  • So maybe just agree which types of stubs/types of data structures you would like to use and then make a minimal workable solution for the initial release that the add-on devs/creators can try out while the old add-on manager wont break because the (new) meta-file(s) for holding data will not have an impact of the old add-on manager (I guess).
Thanks for your time and efforts guys!
I am a bit confused about this comment, Have you actually tried ExtMan? I think that to have the context it is required to know both solutions. I am not saying ExtMan is a better solution but i am saying it is required to know both things.
User avatar
chennes
Veteran
Posts: 3876
Joined: Fri Dec 23, 2016 3:38 pm
Location: Norman, OK, USA
Contact:

Re: [Feature request] Let Addon Manager show current and available version of an add-on

Post by chennes »

Zolko wrote: Mon Jul 05, 2021 1:21 pm obligatory XKCD reference
:D One of my favorites. That's why, rather than inventing a new standard from scratch, I tried to adapt a metadata format that was in use by another substantial project, and has been for many years. REP 149 is a flexible, robust, easy-to-implement standard: https://ros.org/reps/rep-0149.html

My proposal is that, presuming that PR is merged in something close to its current form, that we actually use it for a while with Preference Packs and see how it goes. If it proves too much for packagers to deal with, or doesn't provide what the package manager needs when we actually implement it, then we can revisit it.

I should note that the extension manager is not the only part of FreeCAD that would benefit from this metadata being present -- I wanted it for some other purposes too when implementing Preference Packs.
Chris Hennes
Pioneer Library System
GitHub profile, LinkedIn profile, chrishennes.com
User avatar
mnesarco
Posts: 446
Joined: Thu Mar 26, 2020 8:52 pm

Re: [Feature request] Let Addon Manager show current and available version of an add-on

Post by mnesarco »

Zolko wrote: Mon Jul 05, 2021 1:21 pm
mnesarco wrote: Mon Jul 05, 2021 1:14 pm The thing with standards is ....
obligatory XKCD reference
Image
Yes this is obligatory. And indeed it is the actual situation. :mrgreen: That is why my point is that any "standard" Must be Enforced to be accepted as a standard.
a.l
Posts: 86
Joined: Thu Apr 09, 2020 7:14 pm

Re: [Feature request] Let Addon Manager show current and available version of an add-on

Post by a.l »

mnesarco wrote: Mon Jul 05, 2021 1:41 pm
a.l wrote: Mon Jul 05, 2021 12:38 pm Mnesarco I think you have some good reflections and lists in your post https://forum.freecadweb.org/viewtopic. ... 04#p514536

I guess to get many people to agree is likely difficult so to get consensus/getting started maybe break the project down either with your extman or the original add-on manager broken down so that:
  • Add-on (package) devs know that going forward there will be changes coming - not like a big bang where everything is changed at once, but where most needed properties/features are handled first.
  • Maybe handle github only to begin with if packages from other sources (multichannel) takes more time to implement. So other sources will be later on.
  • Lay out for add-on/package devs what the requirements are now, and in what direction things are going in the future so that they are aware of that in good time and - if they like/need to - can object/ask questions/make comments.
  • The extra features such as searchability, flags and voting (which is like good meta data for how useful other find a package) could maybe be delayed.
  • Maybe you guys that are going to implement it consider how much time you max want to spent on an initial release/update of either current add-on manager or ExtMan so that it helps getting to set a scope of which features are pushed for later. Personally I would rather see a smaller feature set to begin with if that yields that the ball gets rolling. Because the other features will come later for sure because they are useful :)
  • So maybe just agree which types of stubs/types of data structures you would like to use and then make a minimal workable solution for the initial release that the add-on devs/creators can try out while the old add-on manager wont break because the (new) meta-file(s) for holding data will not have an impact of the old add-on manager (I guess).
Thanks for your time and efforts guys!
I am a bit confused about this comment, Have you actually tried ExtMan? I think that to have the context it is required to know both solutions. I am not saying ExtMan is a better solution but i am saying it is required to know both things.
Yes, I did once - and now I just did again - but it breaks e.g. when I activate Assembly 4, but when I read previously that it was a POC then I did not spend more time on trying ExtMan, but just disregard my comment.
My main motivation for the post/comment was simply to give my point of view on how to get the ball rolling.
Something is regarding the add-on/package manager features and something else is regarding getting the smallest set of properties(meta data) that would let the add-on/package manager work.
But I like the UI of ExtMan. It is looking friendly from a user perspective.
Attachments
screenshot.png
screenshot.png (154.89 KiB) Viewed 1158 times
Post Reply