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

[a.l]

This is a feature request to amend the Addon Manager to show the currently installed version of an add-on as well as the newest available version of that add-on next to the line with the name of the add-on in the Workbenches list view. The manipulated screenshot below suggests and illustrates this.

Suggestion and reasoning
(Partly taken from https://forum.freecadweb.org/viewtopic. ... 61#p513629 )

1. It is difficult to keep track of which version of different add-ons that are installed. This leads to the problem that you might think you are on a current version or that you re-install an add-on that is already the newest version.
2. Lets say all add-ons going forward e.g. had to place a file in the root of their repository branch called VERSION
   (like Assembly4 does, but no other add-on I have checked do)
   then it would be easy for:
   * The user to do a manual look up by going to (in this case Linux / Assembly4): /home/user/.FreeCAD/Mod/Assembly4
   , and find the VERSION file.
   * The add-on manager could fetch the version strings for installed add-ons locally by locating the VERSION files as well as fetching the VERSION files online and make the comparison and present the result next to the name of the add-on in the add-on manager like the screenshot shows.
   
   This is obviously a very simple suggestion to a solution and I understand there might be reasons to implement such a feature in another way - e.g. in a manifest file. Probably it would be a good idea to name that file in a way that would make it easy and obvious for the user to find that file intuitively because of its name and then open it to search for version info and other meta data.
3. The 'Description' section (in the top) of https://wiki.freecadweb.org/Std_AddonMgr links to https://github.com/FreeCAD/FreeCAD-addons/ as the place where the newest add-ons are taken from, however it does not seem to be the case.
   E.g. the check out of Assembly4 ('Assembly4 @ 1c63efc') seems to be about 6 month old and the version seems to be of version 0.9.13 when looking in VERSION of that 'Assembly4 @ 1c63efc' in https://github.com/FreeCAD/FreeCAD-addons/ . So a bit confusing when FreeCAD 0.19 (at least for me) downloads what seems to be master (0.9.17) which matches https://github.com/Zolko-123/FreeCAD_Assembly4 .

Question
Would it be okay to make a feature request in the bug tracker re. https://wiki.freecadweb.org/Tracker#Requesting_features ?

Notes
This relates to my previous thread in https://forum.freecadweb.org/viewtopic.php?f=3&t=59761 which I unfortunately do not know how to move to 'Open discussion'.

OS: Ubuntu 20.04.2 LTS (MATE/mate)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.
Build type: Release
Branch: unknown
Hash: 9e3b630bbfb6807e93eeffb655e6c20f218644fc
Python version: 3.8.5
Qt version: 5.12.8
Coin version: 4.0.0
OCC version: 7.5.1
Locale: Danish/Denmark (da_DK)

Thanks!

[obelisk79]

Subtle, but I like it.

[Kunda1]

I say go for it. Some workbenches have version numbers. But even the ones that don't can still be listed because behind the scenes addon manager uses git so you can simply programmatically find out if the upstream repository is ahead in commits. See https://stackoverflow.com/a/3278427

[Pauvres_honteux]

Perhaps have a chat/cooperate with mnesarco (Frank David Martinez) who has already come a bit on the way with his NewGEM?

If we look at it from the user perspective, I'd say the desired funtionality would be something like:

- overview (categorizing / ... add your favourite overview option here ... ).
- searchability (keywords / fast scrolling small pictures / ... add your favourite search option here ... / AND(+)\OR\NOT(-)\*\?).
- simple explanation of each addon (pictures with numbered arrows + explanatory text), both mandatory.
- is installed yes/no + version + sorting.
- update exist yes/no + version + sorting.
- additional stuff must be installed yes/no + version.

Your suggestion has come a bit on the way and mnesarco and has come some other bit on the way, hence my suggestion to cooperate. Joining your forces will most likely take the AddOnManager to the seventh level, seen from my perspective at least.

[M4x]

Another idea: Easy way to display all workbenches / macro with a pending update.

[Kunda1]

Perhaps have a chat/cooperate with mnesarco (Frank David Martinez) who has already come a bit on the way with his NewGEM?

Personally I'd be happy if we switched over to mnescaro's addon manager code

[carlopav]

Perhaps have a chat/cooperate with mnesarco (Frank David Martinez) who has already come a bit on the way with his NewGEM?

Personally I'd be happy if we switched over to mnescaro's addon manager code

+1

[a.l]

Perhaps have a chat/cooperate with mnesarco (Frank David Martinez) who has already come a bit on the way with his NewGEM?

Personally I'd be happy if we switched over to mnescaro's addon manager code

+1

+1
I think mnesarco's addon manager looks nice too.
If he would add version number to the manager it will be cherry 🍒 on the cake. :)

Nice that git can be used to pull out at least some info re. "But even the ones that don't can still be listed because behind the scenes addon manager uses git so you can simply programmatically find out if the upstream repository is ahead in commits"

What would be the process of getting the add-on developers to accept a change for add-ons so that they would have to provide version info and changelog in one version/revision file?

E.g. it could be a file that contains something like:

Code: Select all

<?xml version='1.0' encoding='UTF-8' ?>
<history>
	<entry>
		<version>0.1.2.3</version>
		<changes><![CDATA[You can write any anything within here without breaking the xml]]></changes>
	</entry>
	<entry>
		<version>0.1.2.2</version>
		<changes><![CDATA[* Extra buttons were added. <br/> * Change of internal structure... <br/> * Bug regarding rotation was fixed.]]></changes>
	</entry>
	<entry>
		<version>0.1.2.1</version>
		<changes><![CDATA[* Bug fix: Unable to input floating point values.]]></changes>
	</entry>
	<entry>
		<version>0.1.2.0</version>
		<changes><![CDATA[* Feature: Orb merge is now possible.]]></changes>
	</entry>
</history>

It could be xml, json or whatever works well in FreeCAD and the add-on manager of choice.
Then it would be easy for the creator of an add-on to update the version history in one place and the add-on manager can grab the info it wants without a problem.

EDIT
Just found this thread discussion regarding metadata for packages and made an update: https://forum.freecadweb.org/viewtopic. ... 40#p514511

[mnesarco]

Hello Friends,
I'm sorry for being late to the discussion.

I started the ExtMan project with the idea to make a next generation Extension Manager for Freecad. When I started it I was new in the FreeCAD community and I was not familiar with the FreeCAD way of work... So I supposed that Extensions (Mod, Macro, Workbench...) has a fully defined metadata describing it and describing integration but I discovered that there is no metadata, and the integration api is something that have grown organically so there is no formal specification. I started a Metadata discussion thread, and I was hoping to achieve some kind of standardization but also discovered that there were previous attempts to define metadata.... Well the point is that a good Extension Manager needs a well defined standard for Extension in general, including a standard API and a standard Metadata.

On the other hand, I tried to overcome all the obscure aspects and do something useable, so the ExtMan was released as a POC. The idea of the ExtMan was to mark a direction of a better extension manager with the following goals:

1. Better UX
2. Searchability
3. Classification
4. Versioning (not implemented yet)
5. Multi channel (extension repositories)
6. Avoid of pushing commits to the main FreeCAD repo (Required by AddOn Manager for icons)
7. Complete cycle: Discover, Install, Uninstall, Upgrade, Rating
8. Flags (obsolete, banned, etc...)
9. Unification of Extension Concept = (Mod, Macro, Theme, Workbench....) = Package

At some point I realized that without a well defined standard, ExtMan will become as unstable and unmaintainable as the AddOn manager, it depends on too many fragile things like Wiki parsing, html parsing, regex parsing of python files .....

The key aspects I can see as a must have to develop a really good Extension Manager are:

1. Formal Extension Package Definition
2. Formal Package Metadata definition
3. Formal Extension API
4. Formal Extension Development Guidelines

There is an extension API of course, but it is bare minimal, poorly documented and incomplete, so the extension developer needs to hack a lot to achieve simple things.

The other problem is backwards compatibility with existing extensions (this is Huge)

Well that was a wish list.... Most of the problems of extension managers can be solved just with proper Metadata.

My vision of a future extension manager:

1. A public extensions portal (i.e. https:://ext.freecadweb.org) with search, ratings, versioning... (similar to https://www.npmjs.com)
2. Every extension is packaged in a well defined format inside a zip archive. (i.e. mypackage.fce) so it can be downloaded for manual install or installed by an extension manager
3. A very minimal UI in freecad to install/upgrade/uninstall a freecad extension package (.fce)
4. Dependency management (This is Hard) ensuring that the installed package will work.

IMPORTANT!!!
It is less known but apparently any FreeCAD extension can be deployed as a standard python package, so pip and https://pypi.org/ can do all the work. But it does not work with AppImages.

Well, I will be happy to accept code contributions to the ExtMan if you want to use it as a base, but I seriously think that a Portal is the right direction, so the user just find and download a package file and drop it into freecad importer UI and that's it. Then upgrade and uninstall can be managed by a minimal ui from freecad.

ref: Metadata thread: https://forum.freecadweb.org/viewtopic.php?f=10&t=57448

[chennes]

See also Pr 4787: https://github.com/FreeCAD/FreeCAD/pull/4787

…which includes a first cut at implementing the metadata format we discussed. The format is very easy to extend to include the ideas in the OP above, and me hope was to work on add-on management once that PR is merged.