mount directories via conf file

[oliwoli]

Managing custom mounts via resolve.sh is cumbersome and unintuitive. This PR introduces a bind_mounts.conf configuration file for simplified container setup, addressing a significant usability issue, especially for editors working externally (e.g., SSD).

---

Tested on DaVinci Resolve Studio 19.1.3 with Podman on Arch Linux (Gnome 47, Wayland).

[fat-tire]

Hey this looks interesting! Quick question to help me understand the use-case-- if I'm reading this correctly, the PR uses lines in bind_mounts.conf to pre-load the RESOLVE_BIND_SOURCES and RESOLVE_BIND_TARGETS. But can't you already do this (plus any other pre-flight commands) in a resolve.rc file (assuming you have appropriate mount points set up) as follows:

resolve.rc:

# sources/targets
RESOLVE_BIND_SOURCES=("/mnt/sfx" "/mnt/music")
RESOLVE_BIND_TARGETS=("/home/resolve/sound/Sound Effects" "/home/resolve/sound/Music")

So long as you have a path to this resolve.rc file in RESOLVE_RC_PATH (set it anywhere you like-- in a resolve.desktop, .bashrc, .zshrc or even by prefixing the ./resolve.sh command itself), this would do what you want, right?

(If you prefer to use the filename binds_mounts.conf, you could use that instead of resolve.rc ...and put it wherever you want -- just specify it in RESOLVE_RC_PATH, like:

export RESOLVE_RC_PATH=/home/myaccount/podman/resolve/bind_mounts.conf

or run with:

$ RESOLVE_RC_PATH=./bind_mounts.conf ./resolve.sh

etc.

Thoughts?

[oliwoli]

if I'm reading this correctly, the PR uses lines in bind_mounts.conf to pre-load the RESOLVE_BIND_SOURCES and RESOLVE_BIND_TARGETS

Yes, that's correct and I added some extra logic in env-set.sh to make it work.

But can't you already do this (plus any other pre-flight commands) in a resolve.rc

Oh, I was confused because the README says:

I've set up some basic mounts in this repo-- but feel free to move those mapped folders around to whatever is most convenient. They're all set up in the resolve.sh file used to launch DaVinci Resolve.

... So I assumed editing resolve.sh was the preferred method. A resolve.rc file makes things much clearer than modifying the bash script. It centralizes all custom configurations, which is logical.

However, there is still a case to be made to set things up the way I did. 3 things stand out to me:

1. Handling Multiple Sources: Attempting to bind multiple sources to the same target mount in resolve.rc results in a duplicate mount destination error. My solution avoids this (though I'm unsure why), allowing, for example, populating the preconfigured "Media" mount without moving files or adding a new mount in DaVinci Resolve preferences.
2. Clearer Structure (with many mounts): If I want to change a path I have to scan and count across the two arrays to figure out what binds to what. So then editing the resolve.sh seems like a more tidy solution after all, if you have a lot of folders. I think I solved that in my method because you have a clear hierarchy by setting things up from top to bottom.
3. Speed and Reduced Errors: My method allows direct copy-pasting of paths into bind_mounts.conf, eliminating the need to specify mount destinations repeatedly and minimizing quoting/syntax errors. The added logic in env-set.sh also supports paths like ~/Videos

What do you think? I feel like both approaches have their advantages: resolve.rc is great for keeping all configurations in one place, but using bind_mounts.conf (like in my PR) has some practical benefits, especially when dealing with multiple mounts. Maybe there's a way to combine the best of both? Curious to hear your thoughts!

[fat-tire]

Handling Multiple Sources: Attempting to bind multiple sources to the same target mount in resolve.rc results in a duplicate mount destination error. My solution avoids this (though I'm unsure why),

I'm unsure why too! Since if I understand it right, your code is essentially building the equivalent of the .rc method. When you use your solution, do you confirm that the mounts are correct and as you'd expect but not when they're set "by hand" in the .rc file? strange...

Maybe there's a way to combine the best of both? Curious to hear your thoughts!

Yeah, I mean, I was thinking along the same lines. Obviously we don't want to break anything for people already using the current .rc system.... but maybe it could be blended into the existing system in a way that would not interfere and be a pure "value add" (ie, you have the option to use this alternate method if you like- or both) -- perhaps by deferring to values set in resolve.rc or always appending to the existing list, provided the values don't already exist?

What do you think? An alternative idea would be to make it so that the configuration lines currently used in bind_mounts.conf could somehow be moved to the .rc file itself? Make it an all-in-one?

I do know that one of the requested features was to make it so that the resolve.rc file (and in fact all the files including the .zip and the mountpoints, etc can be redirected to be in in any location-- some users are putting the resolve repository itself in some read-only directory and then redirecting ALL the configuration, zip, mount files to various locations. I'm not sure why they're doing this, but I'm not really an expert in advanced container usage-- I just know they wanted to have the repository untouched and the support files and folders settable via environment variables in wacky locations rather than hard-coded in. Maybe it has something to do with media file management for shared editing facilities (such as in a post production house) or maybe it's a security thing to keep mounts, media, source and configuration files separate? I've also been told this is the "docker way" 🤷

Anyway, that was a long-winded way of suggesting that perhaps the .conf file itself could be set dynamically and/or rolled into the .rc configuration file that already exists?

I'd appreciate your thoughts.