Properly handle multiple library without risk of messing with mipmaps

[TurboGit]

Is your feature request related to a problem? Please describe.

Yes, it is possible to use inconsistent cache/db location.

Describe the solution you'd like

A simple support for multiple database.

Currently we have:

--cachedir DIR
    $HOME/.cache/darktable/

--configdir DIR
    $HOME/.config/darktable/

--library FILE

It is wrong to use different database (--library) with the same cachedir as thumb could be mixed.

My proposal would be to have a single option --env <NAME>.

• If name gives the actual sub-directory to use, for the cache $HOME/.cache/darktable/<NAME>/ & $HOME/.config/darktable/<NAME> for the configuration.

• If name is not specified (no --env option) the the actual name used is default.

• If name is :memory: then library is a memory one and we disable the cache, the configuration dir is the default one.

This will give us:

.config/darktable
   default/
      library.db
      data.db
   <other name>/
      library.db
      data.db

.cache/darktable
   default/
      mipmap-*
   <other name>/
      mipmap-*

The three options --cachedir, --configdir & --library can be removed.

[parafin]

As far as I remember mipmap cache goes do the subdirectory of cachedir with name including hash of library file path. It was designed like that exactly to prevent the issue you are describing, or am I missing something? But maybe :memory: library indeed needs special handling as described.

[TurboGit]

You're right about about the hash added to the mipmap directory. So we are safe here.

Yet, I'm looking for something easier to use for the library, and instead of specifying the directory where it can be found I would prefer a simple name that that do the right thing on every OS. This will also help people using multiple db I suppose.

So maybe just using --config-name (instead of --configdir) and so use $HOME/.config/darktable/<NAME>.

I still have to double check that we do disable the cache for :memory: database.

[wpferguson]

opencl kernels also go in the cache directory.

Lua currently uses configdir and cachedir retrieved from darktable configuration. Will those still be available or will they change?

[wpferguson]

Windows may be a problem. I just tried repointing the cache directory. I specified C:\Users\Bill|AppData\Local\Microsoft\Windows\InetCache\darktable45 with --cachedir. It got created, but C:\Users\Bill|AppData\Local\Microsoft\Windows\InetCache\darktable got used.

UPDATE: --cachedir does work on windows and you can put it wherever you would like.

[victoryforce]

My proposal would be to have a single option --env <NAME>.

• If name gives the actual sub-directory to use, for the cache $HOME/.cache/darktable/<NAME>/ & $HOME/.config/darktable/<NAME> for the configuration.

What if I want to specify the location of the configuration or cache in another place, not in a subdirectory of the default directories?

[wpferguson]

What if I want to specify the location of the configuration or cache in another place, not in a subdirectory of the default directories?

Why not just add --env. I like --env from the standpoint of less typing, but I can see the advantage of having finer control in certain instances.

The people most likely to use/abuse this are devs who would know which to use and when.

Another thought about this. For troubleshooting a users bad configuration starting darktable from the command line with a --env <new environment> would be a lot easier than --configdir --cachedir

[dterrahe]

What if I want to specify the location of the configuration or cache in another place

Exactly. I'd be happy for an additional option that simultaneously sets config, library and cache as subs of default config dir, but the "old" way should still be available for more control.

Also, --env :library: could be a separate option. --nodam or something.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.