Addon Manager Redesign 2021
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Addon Manager Redesign 2021
It certainly won't be required: if Addon authors want to just carry on as they currently do that will continue to work. But I do think it would be a good idea to have some way for an Addon author to specify either a tag or branch that represents a version that works with a particular version of FreeCAD. That way people who don't want to update their copy of FreeCAD for whatever reason don't end up with a broken Addon if they do an update.
It seems to me that the most logical place to do this is in the FreeCAD-Addons repo, which is where we are currently setting the branch that gets used. If instead of hijacking the .gitmodules file we create our own file, we can tie branch and FC version information together. Addon authors who want to can submit a specific tag or branch that is tied to a specific FreeCAD version. This would be an opportunity for us to also provide an opt-in "development" channel for Addon authors, etc.
It seems to me that the most logical place to do this is in the FreeCAD-Addons repo, which is where we are currently setting the branch that gets used. If instead of hijacking the .gitmodules file we create our own file, we can tie branch and FC version information together. Addon authors who want to can submit a specific tag or branch that is tied to a specific FreeCAD version. This would be an opportunity for us to also provide an opt-in "development" channel for Addon authors, etc.
Re: Addon Manager Redesign 2021
ah, It begins to make sense. If I understand correctly: a company makes a product A, using FreeCAD v0.20.3, and addon SuperDuper v1.2.3. This is an important product for the company, so they want to be sure to be able to open corresponding files, and decide to keep a copy of FreeCAD v0.20.3 around in case they need to open design files. They don't want to take risks about incompatibilities.
Later, the company develops product B, using the latest FreeCAD version v1.23.4, that gives some nice new functionalities. They use the latest addon SuperDuper v4.5.6 that uses the new shiny functionality.
But then, they discover that when they launch the legacy FreeCAD version 0.20.3 to open design files of product A, it actually uses the addon SuperDuper from ~/.local/share/FreeCAD/Mod which is at version v4.5.6, installed by the latest FreeCAD v1.23.4. And which doesn't open the files correctly.
Is this the use-case you want to address ? But then, how will the AddonManager keep 2 versions of the addon SuperDuper on the same computer ? Or, alternatively, how can you save and restore ancient FreeCAD versions ?
In parallel to this, I preferred the FreeCAD files to be located in ~/.FreeCAD as per v0.19 rather then spread over several directories as per v0.20. What was the reason to do that ? And please, don't answer LSB !
- adrianinsaval
- Veteran
- Posts: 5552
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Addon Manager Redesign 2021
best choice for the company will likely be to launch old freecad in a sandbox or even a container/VM then the advantage will be that they can just download the relevant addon version from the addon manager (provided nothing else breaks) instead of manually hunting down a commit they can use and checking out in their addon clone.
Another example, say you are using some platform were newer versions of freecad aren't available and all you get is say 0.21, if you want to download addons but the latest version of those don't work in your freecad this would make it possible to easily download a compatible version. This might sound unlikely now, but this scenario has already happened with 32bit windows for example, how long until the same happens with x86_64 apple for example?
What's LSB in this contextx? Anyways, this "new" structure is a pretty common standard on linux to make these files easier to manage (at user level considering all apps, not specifically for FreeCAD), see https://specifications.freedesktop.org/ ... atest.html or https://wiki.archlinux.org/title/XDG_Base_DirectoryIn parallel to this, I preferred the FreeCAD files to be located in ~/.FreeCAD as per v0.19 rather then spread over several directories as per v0.20. What was the reason to do that ? And please, don't answer LSB !
This for example makes life easier for the flatpak that uses isolated config and addons by setting up non-default XDG variables, and probably the snaps too.
Re: Addon Manager Redesign 2021
you cannot be serious saying this
Lennart Poettering !?!?!? Of all the people, you want to build a functioning open-source CAD system on ideas from this clueless narcissist idiot ? Please tell me this is a (bad) joke.
why the bloody f***ck should user specific data be written to $USER/.local/share ???? Only a moron like Pottering can come up with such a stupid idea. "local" comes from ancient times where the /usr directory was mounted from the network, and /share comes from a shared directory on the local machine shared by the local users. Which, in a local user directory, has absolutely no meaning. What is "local" in a user's home directory ? What is "shared" in a users home directory ?XDG_DATA_HOME
Where user-specific data files should be written (analogous to /usr/share).
Should default to $HOME/.local/share.
Who did take these decisions and where was it discussed ?
Re: Addon Manager Redesign 2021
@Zolko please de-escalate and take a break.
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
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
Re: Addon Manager Redesign 2021
I am right now thinking of the simpler use case in which a user simply chooses not to upgrade their copy of FreeCAD to the latest build -- I would like Addon developers to be able to essentially declare that branch/tag/hash/ref BLAH_BLAH is the one to use with FreeCAD version X. So the dev can freely use features of the latest FreeCAD build, without breaking everyone still on version X's installation. That lets them prepare for the next release simultaneously with its development, but still easily support older copies of FreeCAD.
- adrianinsaval
- Veteran
- Posts: 5552
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Addon Manager Redesign 2021
I''m talking github api and the like, I don't get what is so wild about this to you?
Regarding your xdg related rant, take it up to freedesktop, like it or not it's a standard gaining adoption by the day on linux and frankly you're the first person I've seen so pissed off by those details (classic zolko). I forgot to mention before but if you don't like this you can use a flag to keep the old directories, I don't recall now the exact text but I mentioned it somewhere in the release notes.
Re: Addon Manager Redesign 2021
Zolko wrote: ↑Thu Jun 30, 2022 10:01 pmwhy the bloody f***ck should user specific data be written to $USER/.local/share ???? Only a moron like Pottering can come up with such a stupid idea. "local" comes from ancient times where the /usr directory was mounted from the network, and /share comes from a shared directory on the local machine shared by the local users. Which, in a local user directory, has absolutely no meaning. What is "local" in a user's home directory ? What is "shared" in a users home directory ?XDG_DATA_HOME
Where user-specific data files should be written (analogous to /usr/share).
Should default to $HOME/.local/share.
Usually this means that for the specific user (many users forgot that Linus is a "multiuser" system "by design") what is put in "~/.loca/sharel" will override or integrate "system defaults" that are found in /usr/share/for this specific user.
example if I put a "desktop file" in ~/.local/share/applications I will found the relative icons in the WM or DE menu to select and launch the application, but only for me and for other users.
This is the sense of local and Pottering is not to be called in cause, this behaviour predates his birth date I think.
Regards
Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
Re: Addon Manager Redesign 2021
Yes I suspected that. Now, would you please consider my use case ? A "project" wanting to archive à given FreeCAD version including all it's addons
How do you intend to manage that ?
Re: Addon Manager Redesign 2021
Well ... may-be you didn't think this one trought ? Keywoard being "crossplatform". "We" don't do Linux. FreeCAD's specificifity is to be OS agnostic, be it Linux (any variants) BSD, Windows and MacOs.adrianinsaval wrote: ↑Fri Jul 01, 2022 2:41 am Regarding your xdg related rant, take it up to freedesktop, like it or not it's a standard gaining adoption by the day on linux
(classic zolko)
Therefore, the phantasmes of an idiot concentrating on Linux go directly /dev/null
On the other side : FreeCAD has stored all its user speific data in .FrerCAD for 20 years : apart from not pleasing Mr Potter, what problem did we have with that ? Did you ask Ms Gates or Ms Jobs what they think about this ? What problem do you solve with this ?
As I said this stinks of à solution in search of à problem.