Preventing Anki and addons from directly writing their configuration

Anki Suggestions
1

I have an OS where my config files are read-only, and I manage my config with git, rebuilding my system for each new commit.
This means that whenever an addon or Anki tries to write to configuration, I have an error message:
anki
This prevents some add-ons from loading, as shown in the screenshot, but more generally prevents me from actually changing my configuration.

Could there be an option to specify and alternative directory to which the configuration is written, which would allow me to choose how to handle it? The idea would be that configuration is read from the usual directory, but written to an other, meaning that if I do nothing, the writes have no effect.

This exact idea is taken from the solution to this problem provided by an other software I use (Emacs), where you can set the file to which the configuration changes made directly from within Emacs are wrote:

(setq custom-file "~/my/custom/path")

Then the use can choose whether to also load this path or not, by adding or not

(load custom-file)
2

Use Anki from tar.bz2 - from Anki main website, you can unpack it in any folder you want.
This way it will not use
/home/user/.config/
You can give different permissions to Anki add-ons folder or you can use symlink (symbolic link) and also play with permissions.

The idea would be that configuration is read from the usual directory, but written to an other, meaning that if I do nothing, the writes have no effect.

This would mean source configuration file and some temporary configuration file: equals two files. That would make things more complex.

As far as I understand Anki configuration is written in prefs21.db in Anki folder and add-ons configuration on add-ons folder.

I doubt if the idea of Emacs would serve regular Anki users.

You can also play with backups of anki add-ons folder and synchronize backup and original folders some way.

But I am not advanced Linux user, so I barely understand the idea behind your configuration.

3

TL ; DR

Your suggestion doesn’t solve the problem, but it raises a good question about the Anki configuration file management. Therefore, a better feature request might be:

could the writes to the addons directory be redirected into a custom directory?

Full answer

Use Anki from tar.bz2 - from Anki main website,

I actually don’t want to do that, and instead use an already packaged version of Anki provided by my distro, as it is much simpler to install, use, uninstall, etc. …

you can unpack it in any folder you want.
This way it will not use
/home/user/.config/
You can give different permissions to Anki add-ons folder or you can use symlink (symbolic link) and also play with permissions.

This doesn’t solve the issue. No matter where I put Anki, no matter symlinks and whatever, if Anki doesn’t understand that it should read configuration and write configuration to two different files (unless I actually achieve write redirection — which I am not aware is possible), it won’t work with a read-only configuration.
Maybe it is more clear is told in a different way: the actual file of configuration is read-only. This cannot be changed. Anki should therefore never try to write it. Adding a link-wrapper around that doesn’t solve the issue.

This would mean source configuration file and some temporary configuration file: equals two files. That would make things more complex.

Yes, but it actually makes the management of the whole system a lot easier, and a lot safer. Anyways, I am ok with having two files. This is what I am consciously asking.

I doubt if the idea of Emacs would serve regular Anki users.

Yes, I totally agree on that one (why would any program write configuration to a different location than the one it reads from… well, turns out it is useful in niche situations, such as mine), but as with Emacs, this could be a completely optional feature, that must users would be unaware of, until they actually need it.

As far as I understand Anki configuration is written in prefs21.db in Anki folder and add-ons configuration on add-ons folder.

This is a real issue, in the sense that if Anki saves its configuration into a database which is not simply a plain-text file, then it becomes much harder to handle it with git: I could simply stage any change to the database, but I couldn’t stage the changes incrementally…
So, maybe this is too much strain. But I need this feature more for addons than for Anki itself, since I almost never change Anki’s configuration, whereas it is common for me to tweak or install addons.
So maybe a better feature request (at least, a simpler one) would be:
could the writes to the addons directory be redirected into a custom directory?

But I am not advanced Linux user, so I barely understand the idea behind your configuration.

It’s not that hard. I have a distribution that is built around the idea that the OS should handle all the configuration, in order to ensure the system is sound.
To do so, the user describes what the system should look like, and the builds it. The OS takes care of detecting incoherence in what is asked, and if it is not it will generate the configuration for every package required – which might actually require installing other packages, handling dependencies, tweaking the configuration of several packages just for one other package that relies on them.
Among other things, for example, it takes care of installing and configuring Anki addons by itself.
This is why configuration is read-only: you should never try to change it by hand, or really let anyone else besides the OS tweak the configuration. If you want to change how your system ends up being, juste change its description and rebuild it.
To give you an idea, this means that my whole system is entirely defined a ~200 lines file. If I were to burn my computer, I could buy an other one, copy the same 200 lines, let it process them, and I would be back with the same system I left (not my files, of course, but all my system, including all programs installed, all their configuration, all my accounts, my themes, etc. would be exactly the same, even if the new computer is completely different from my old one).

4

This is off topic not related to Anki or your problem.

I have a distribution that is built around the idea that the OS should handle all the configuration, in order to ensure the system is sound.

The great thing about Linux is that it allow such things.

I don’t know what do you mean by “sound”. Perhaps not breaking. But in Linux many things can braek because distribution creators don’t have control over all components. They just put it together.

If this means security read about Qubes OS.

Even it this is a solution to some problem it causes another problems as you described with Anki configuration file, and I doubt anyone on Anki side will be willing to address it.

To give you an idea, this means that my whole system is entirely defined a ~200 lines file.

You mean its configuration.

If I were to burn my computer, I could buy an other one, copy the same 200 lines, let it process them, and I would be back with the same system I left

You would have to install system on a new disk first.

I am not sure but perhaps you can achieve the same result with some proper techniques of backup. For example with BTRFS you can move system from one disk to another and recover in minutes. To recover from snapshots it takes seconds.

Anki configuration is in user space meaning in /home.

Not writtable user space is something I would call unusual.

Are you sure that it causes more solutions to problems than problem of diffrent nature.

Preventing Anki and addons from directly writing their configuration

But as Anki user you want to have your add-ons configured, means customised.

What do you need original versions of add-ons for? You can keep backup of such original versions of add-ons and write script to recover from backup.

5

Yes, that’s wonderful :slight_smile:. :heart: Linux.

I’m not sure I was clear enough.

That’s the exact issue the OS tries to solve. The idea is, in a normal distribution, each package’s configuration is “private”, so to say. This means that if I want to configure two packages to work together, I have to “stick” them with “configuration glue”, meaning I have to configure either one package which relies on the other, or both packages, to match each other given the system requirements. But the packages cannot autoconfigure themselves, because they don’t know have a global point of view.
On the other hand, my distro tries to remove this “sticking” step by make sure all the configuration is handled by a single entity, the OS, which has a global view of the situation, and can basically change anything in order to reach the state it is asked.
Sometimes, what you ask is fundamentally impossible, so it just refuses to build.

This is done exactly because distribution creators do not have control over every component.

No, the distribution I use is not meant to be more secure than the average Linux distro. In a way, I think that’s a bit overkill…

I’ll try to be more concrete.

No, I really mean the system definition. I do not touch the configuration. I only specify how it should look to me when I boot, not how it should accomplish that.

Well, of course that was implicit. But, I don’t know if you have spent a lot of time installing OS — I have. The idea is that installing the system is as easy as downloading the OS from internet, copying my system description file in the right place, and let it happen, as opposed to pass a few dozen hours to tweak to until it is finally similar to what I left.

This is not a backup technique, the fact that I can recover so fast my system is just a side effect. As said, it does not handle proper user’s files. For example, it doesn’t handle my Anki database. So, using this distribution is complementary to backups.
The difference is that, when you backup, what you expect from it is the ability to restore a given machine to a definite state. This would not work on an other machine, for configuration. Imagine I have configuration that deals with having two monitors, and I install it on a laptop. It wouldn’t work — or, at least, that would require tweaking. By contrast, if you copy the system definition, and then let it build, it will generate the appropriate configuration.
However, restoring on an other machine backups of user files, that’s fine. I hope you can see the difference, and why they are solutions that solve different problems.

Well, the question about writability is not exactly whether it’s in the user space, but rather is it in a configuration space. You can find non-configuration files outside user space (/dev), configuration files outside user space (/etc), non-configuration files inside user space (whatever file you usually use) and configuration files inside user space (/home/you/.config).

Well, so far Anki has been the only program that doesn’t interact very well with my distribution, so I’d say it’s quite a gain. Especially considering that I like a lot tinkering with the OS, and that I have screwed my system more than one time, leading to a complete re-installation. Screwing my current distribution is much harder.

Actually, I don’t need the original version of the add-ons. What I want it to look like is, in the file that defines my system, a list of the Anki add-ons I want. Then, when the system is built, it takes care of installing them for me. What it currently does is that it stores the original version somewhere, in a cache, and creates read-only links where Anki is supposed to find them.

But, and this is important, there are other ways to obtain the same result without storing the original version.

  1. First way. Anki could have an API which delegates the add-ons management, meaning each time my system wants an add-on, instead of looking for it in its cache, it asks Anki: “could you make sure this add-on is installed, with this configuration?”. Conversely, when I change an add-on setting, Anki says to my system: “this add-on now has this settings”.
  2. Second way. Anki doesn’t have such an API, so I write a specific add-on that hooks itself to add-on management and does the same thing. I could write it, but I don’t have enough time to dig in the whole Anki dev doc (maybe someday…).

But, the important aspect is that the purpose is not to backup the add-ons. It’s to be able to define every aspect of my system from within the system definition file.

6

But maybe you’re right, I shouldn’t try to encapsulate the Anki add-ons in the definition of my system, until someones writes the right patch that enables me to make it work without thinking too much about it…

But it would still be cool if that could work.