FreeCAD Forum

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.

chennes wrote: ↑Thu Jun 30, 2022 3:38 pm 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.

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 !

Zolko wrote: ↑Thu Jun 30, 2022 8:28 pm 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 ?

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?

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 !

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_Directory
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.

adrianinsaval wrote: ↑Thu Jun 30, 2022 9:22 pm ... (provided nothing else breaks) ...

you cannot be serious saying this

see https://specifications.freedesktop.org/ ... atest.html

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.

XDG_DATA_HOME
Where user-specific data files should be written (analogous to /usr/share).
Should default to $HOME/.local/share.

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 ?

Who did take these decisions and where was it discussed ?

@Zolko please de-escalate and take a break.

Zolko wrote: ↑Thu Jun 30, 2022 8:28 pm Is this the use-case you want to address ?

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.

Zolko wrote: ↑Thu Jun 30, 2022 10:01 pm

adrianinsaval wrote: ↑Thu Jun 30, 2022 9:22 pm ... (provided nothing else breaks) ...

you cannot be serious saying this

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.

Zolko wrote: ↑Thu Jun 30, 2022 10:01 pm

XDG_DATA_HOME
Where user-specific data files should be written (analogous to /usr/share).
Should default to $HOME/.local/share.

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 ?

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.

chennes wrote: ↑Fri Jul 01, 2022 12:30 am

Zolko wrote: ↑Thu Jun 30, 2022 8:28 pm Is this the use-case you want to address ?

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

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 ?

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)

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.

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.