Bundle the lua-scripts with the darktable release

[wpferguson]

Is your feature request related to a problem?

Over the last few years we've made it easier and easier to install the lua-scripts. The last remaining pain point is needing to have git installed in order to clone the repository and install it to the proper place.

The scripts are poised to move from nice to have to need to have.

#17073 adds built in camera styles that give a jpeg look as a starting point. darktable-org/lua-scripts#503 provides a companion script that applies the style on import, or applies the styles to selections or collections for those that want to apply the styles to images imported before the styles were added.

#17326 can be implemented with a script that replaces the existing Create HDR button with another Create HDR button that calls HDRMerge to do the alignment and merge, generating a DNG image that appears in lighttable exactly like the existing implementation.

#16827 wants image groups to persist across databases. I've implemented it as a script with an API change that runs in background. It adds grouping information to the XMP file, and reads it on import into a different database and restores the grouping.

#16135 exists to move the translation functions from the scripts to darktable as part of the effort to make it a "first class citizen". Adding the scripts to the release would make them a "first class citizen".

Describe the solution you'd like

Bundle the scripts with the darktable release package.

#16135 adds the lua-scripts as a submodule. A few lines of CMake magic...

###############################################################################
# lua-scripts section

if(USE_LUA)
#
# lua system scripts
#
FILE(COPY lua-scripts DESTINATION "${DARKTABLE_DATADIR}")
install(DIRECTORY "lua-scripts" DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/darktable COMPONENT DTApplication
  PATTERN "lua-scripts/.git/*" EXCLUDE
  PATTERN "lua-scripts/.git" EXCLUDE
  PATTERN "lua-scripts/.gitignore" EXCLUDE
)
endif(USE_LUA)

puts the scripts in darktable's data directory.

Alternatives

Leave things the way they currently are.

Additional context

What needs to change, besides the CMake magic?

• search path - the script search path needs the darktable datadir lua-scripts location appended to it.
• script_manager - this needs a fair amount of work to manage the possibilities of scripts in two different locations
• data/luarc - scripts_installer needs removed and a line added to start script_managaer
• scripts_installer - will now become a separate script in the tools directory. The user can run it to install the lua-scripts from the repository into the user lua-scripts location.

What if I already have the scripts installed?

Since the bundled scripts directory occurs last in the path, the user installed scripts will take precedence.

Can I have some scripts in the data directory and some in the user config directory?

A user can run the lua-scripts from the darktable data directory and install additional scripts in the user configuration lua directory.

What if there's a bug with one of the scripts?

The logging library provides different log levels (debug, info, warn, error, success, critical) that control which log messages are written. Normally the level is set to warn or error. At present if the user wants more information they have to edit the script and change the log level. This wont be an option with the bundled scripts. However, #17300 adds the ability for scripts to communicate with each other so the log level could be changed while the script is running to capture the necessary information.

If a bundled script has a bug and a fix is available, the fixed script can be downloaded and placed in the user lua scripts directory where it will be found before the defective script is found and thus it will be run in place of the defective one. The worst case is the same as a bug with darktable, you wait until the next release.

What's the timeline to get this done?

I'd like to see this in 5.0, but I don't know if I can get it done quick enough to allow for sufficient testing. I'd say the realistic answer is that I could have it ready to merge early in the 5.1 cycle so that it can get plenty of testing so people can do things to it that I never thought of. 😄

What if the user doesn't want to run the scripts?

If we use scripts to provide core functionality such as group persistence or Create HDR, then those scripts need to run always. I think of them as "system" scripts and as such they shouldn't be under the control of the user. So, if the user doesn't want to "run" the scripts, then I think we start script_manager, it starts the "system scripts" and it sets the UI visibility to hidden. We give the user a lua option to turn the scripts "off" and if one day they decide the want to use the scripts, they uncheck the option and have at it.

Final Thought

Maybe I should rename script_manager to features 😄

Fixes darktable-org/lua-scripts#391

Fixes darktable-org/lua-scripts#352

[github-actions]

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.