Metadata: One Standard to Rule Them All

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
mnesarco
Posts: 446
Joined: Thu Mar 26, 2020 8:52 pm

Re: Metadata: One Standard to Rule Them All

Post by mnesarco »

chennes wrote: Thu Apr 15, 2021 9:50 pm mnesarco -- a question for you about how these "packages" work. The built-in Add-on manager really only supports installing into two relatively fixed locations:

Code: Select all

FreeCAD.getUserAppDataDir() + os.sep + "Mod"
and

Code: Select all

FreeCAD.getUserAppDataDir() + os.sep + "Macro"
Here there really isn't any notion that a package could contain either or both of these things, as the "Content" section of the new metadata format implies to me. Does your workbench use its own directory structure, or does it work within this one?
mnesarco wrote: Mon Apr 12, 2021 1:57 am Ping
There is nothing like a directory structure right now, but it is a fact that you can include any number of workbenches, macros and pretty much anything in:

Code: Select all

FreeCAD.getUserAppDataDir() + os.sep + "Mod"
subdirectories. If Macros are found there, the AddOnmanager will create symlinks from the FreeCAD.getUserAppDataDir() + os.sep + "Macro" on install.

Becasue there is no standard now, there is no way to really know what is included in a "Mod". As you are developing the very first "standard" that is why I proposed the content section to allow the AddOnManager and Extman to know what the hell is included in the package without having to brute force parsing everything inside it.

For example right now:

1. There is no way to know the icon of a workbench, the only way is commiting the icon to the main FreeCAD repo or installing the workbench.
2. There is no way to know if a Mod have macros before installing it (search for files with .FCMacro extension)
3. When you install a Mod, it is supposed that it will contain a Workbench, but this is not mandatory at all, and it can contain zero or more workbenches.

So the Content section in metadata does not map to any specific Directory structure, the idea is that it informs what is in the package and the relevant information required for the AddOnManager, ExtMan and others to inspect the package before installing it.
User avatar
chennes
Veteran
Posts: 3876
Joined: Fri Dec 23, 2016 3:38 pm
Location: Norman, OK, USA
Contact:

Re: Metadata: One Standard to Rule Them All

Post by chennes »

Makes sense, thanks. I'm to the point where I am implementing "themes" in the Addon manager now, and I wanted to make sure I was following whatever the "standard" is. So it sounds like really "Mod" is the standard install location for everything, and Macro is a sort of "auxiliary" location. I am trying to decide if it makes sense to have a "Theme" subdirectory in addition to Macro and Mod, but I am leaning toward "no" -- that everything is in Mod, and if the package metadata says there is a theme, then the GUI picks that up and offers it in the Preference dialog. Since by construction all themes will have package.xml metadata this should work out well, and provide us some opportunity to test out how that works before starting to add the metadata to other things.
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: Metadata: One Standard to Rule Them All

Post by mnesarco »

chennes wrote: Fri Apr 16, 2021 2:44 am So it sounds like really "Mod" is the standard install location for everything, and Macro is a sort of "auxiliary" location.
Mod location is mainly for extension in the sense of software created by developers, while Macros are user's content more than software. So it has sense that Macros and Mods are in different places. But as developers also create Macros, so Mods can include macros as well...

I don't know what the core team thinks about this topic, it is how i understand the topic.

Also there are many names for the same thing:

Mod, Extension, Addon, Package ....

I like package more than any other because it is generic enough. I feel that initially Mod concept was only for workbenches, but it evolved to something bigger.

It is less known but if i understand well, extensions can be also installed as conda packages and conda has it's own metadata, but conda's metadata is not about FreeCAD integration, it is just about distribution on anaconda platform. Looo is the man behind it.
looo wrote: Fri Apr 16, 2021 2:44 am ping
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: Metadata: One Standard to Rule Them All

Post by looo »

mnesarco wrote: Sat Apr 17, 2021 1:59 pm It is less known but if i understand well, extensions can be also installed as conda packages and conda has it's own metadata, but conda's metadata is not about FreeCAD integration, it is just about distribution on anaconda platform. Looo is the man behind it.
With Freecad-namespace packages it's possible to package a workbench as a normal python-package (pip, conda, whatever-package). We do this for the openglider package and it's freecad extension (glider-workbench). Using conda guarantees compatibility. This is important as some dependencies of openglider are compiled and those libraries need to be compatible with freecad.
https://github.com/conda-forge/openglid ... /meta.yaml
User avatar
chennes
Veteran
Posts: 3876
Joined: Fri Dec 23, 2016 3:38 pm
Location: Norman, OK, USA
Contact:

Re: Metadata: One Standard to Rule Them All

Post by chennes »

This is now coded and working on my Themes branch if anyone wants to see it. I've written up the new file format in advance of submitting the PR so that reviewers can make sure that the code does indeed implement the standard as documented. Please have a look and let me know if you see any problems with it:

https://wiki.freecadweb.org/Package_Metadata
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: Metadata: One Standard to Rule Them All

Post by mnesarco »

chennes wrote: Tue Apr 27, 2021 8:43 pm This is now coded and working on my Themes branch if anyone wants to see it. I've written up the new file format in advance of submitting the PR so that reviewers can make sure that the code does indeed implement the standard as documented. Please have a look and let me know if you see any problems with it:

https://wiki.freecadweb.org/Package_Metadata
Hi chennes,
I think classname must be inside content/workbench because it is only useful for workbenches, Also the icon and file elements should be childs of the corresponding content item.
User avatar
chennes
Veteran
Posts: 3876
Joined: Fri Dec 23, 2016 3:38 pm
Location: Norman, OK, USA
Contact:

Re: Metadata: One Standard to Rule Them All

Post by chennes »

mnesarco wrote: Wed Apr 28, 2021 5:50 pm I think classname must be inside content/workbench because it is only useful for workbenches, Also the icon and file elements should be childs of the corresponding content item.
I'll tweak the documentation for those items -- it was easier to design the XML structure to be recursive, so although technically <package> could have those elements per the standard, I don't expect them to get used except as elements of a <content> item.
Chris Hennes
Pioneer Library System
GitHub profile, LinkedIn profile, chrishennes.com
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: Metadata: One Standard to Rule Them All

Post by Kunda1 »

Just a heads up x-post: https://forum.freecadweb.org/viewtopic.php?f=42&t=58156 "conda / mamba based extension manager"
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
User avatar
chennes
Veteran
Posts: 3876
Joined: Fri Dec 23, 2016 3:38 pm
Location: Norman, OK, USA
Contact:

Re: Metadata: One Standard to Rule Them All

Post by chennes »

I have made a few minor changes to the metadata format as I worked on the Preference Packs (formerly known as "Themes"). Those changes are reflected in the updated documentation on https://wiki.freecadweb.org/Package_Metadata . This new metadata format's handling C++ class and its Python wrapper are part of PR 4787.
Chris Hennes
Pioneer Library System
GitHub profile, LinkedIn profile, chrishennes.com
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: Metadata: One Standard to Rule Them All

Post by Kunda1 »

Great work!!
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Post Reply