well, once it’s done I will show it here. Offtopic but it brings up another question… This can’t get in the codebase with contrast and texture having just landed.
I’m hearing voices asking for a module plugin system. With the cambrian explosion of good stuff driven by AI, maybe we won’t have another choice.
What do you think the current modules system is? They are pretty much plugins in C.
Yes, what he is talking about (and has been discussed before) is the ability to publish a new module as a .dll or .so that darktable would be able to scan for and load at startup. Module authors would be able to just drop a new module build instead of having to bundle the whole application binary with every new experimental module or module update.
As you say, modules are already well scoped and self-contained, so doing this should be relatively simple.
Except, everything has to be added to the pipeline ordering, which is code shipped as part of darktable. It can be extended, somehow, but just adding a module binary does not mean it will work in the current system: darktable/dev-doc/New_Module_Guide.md at master · darktable-org/darktable · GitHub
We are going off topic here. But a module could declare how it should position itself relative to other modules in each workflow (e.g., after X and before Y) and then darktable could assign an actual position dynamically at runtime.
There are a few pitfalls though:
So such a free plugin module may sound nice to have, and could work for someone not interested in sharing the editing stacks. As soon as any kind of sharing comes into play, it sounds less attractive to me.
EDIT: dynamic positioning as @masterpiga describes could help, but how do you specify a relative position when the presence of a given module is no longer guaranteed? and how do you deal with two/three modules specifying the same relative position, where the authors may not even know about other module?
With the exception of the guaranteed module order, all the other limitations already exist with custom builds, don’t they.
We are not talking about distributing CORE darktable modules as plugins. Those would still be distributed as they are now. We are talking about making it easier for devs to distribute experimental modules, and for users to test them.
Just use official releases for playraw? This problem already exists today. I, and many users here, use darktable master or nightly releases, which contain modules others are not able to use, as such, whenever I do a playraw I always stick to an official release so others can open it. This is a pretty minor point all things considered.
Sorry @Masterpiga didn’t see your reply
You only specify relative position based on the official modules.
It does not need to be perfect, we are talking about testing out experimental features. Users who are brave enough to try out new modules can also move a module in the pixelpipe if the need arises 
We could also have the requirement that if there are experimental modules --library :memory: is implicit and all XMPs are written to a temporary dir, so that people do not risk messing up their library by mistake.
while I like the idea of plugins. There is more too it…
Also I think that the current situation also has some value
Not saying we should not have a discussion on it, or that I am against it. But I think it is more involved than just a technicality in the pipeline order.
I can see the benefit, but mostly in testing situations.
sounds like a support nightmare.
You have custom modules? No support for you
We could also have this disabled in standard builds, so that only people who compile it have the feature enabled.
I mean, Lightroom, GIMP or Blender do not support their plugins either, they just provide a stable API and that’s it.
You are wrong about this… Gimp actually has a plugin system.
I think ‘plugin’ suggests an open ecosystem. Being able to add ‘experimental modules’ is a different problem: rough edges are expected.
Maybe I was not clear enough. Those software I listed do not support plugins other people make they simply support the API which allows the plugins to exist.
–
Furthermore, a software with good logs and traces could very easily filter out problems coming from external plugins. These are solved engineering problems, is darktable’s architecture that bad that nothing of this kind is possible? Even ART has CTL and it’s a project with an 10x(or more) less developers than darktable.
Huhuhu! 
Maybe I’m overselling it 
One may be able to create a CTL module, into which you can load a script. You could even have multiple instances, so you could move them around in the pipe. They’d forever be 2nd class citizens, I think: no colour picker integration, for example. Saving parameters may be an issue: in darktable, every module defines its fixed-size data structure. Maybe we could say that this module’s data structure is an 8kB byte string, and have it convert all CTLs params to some format that fits.
Also, UI is constructed statically; now it would have to be dynamic, another hurdle. Another case of 2nd-class citizen effect: no shortcuts.
There’s probably a reason no one has implemented it.
But is this a topic about darktable, or about the use of Ai in coding?
I think the main reason is that there was not a strong motivation for it. Creating new modules and iterating on them was slow, and releasing a new build once a month was a reasonable way to get people to test and express an opinion on one or two new sliders.
But it seems clear that the situation has changed. Also the difficulty of implementing a decent plugin infra has been reduced significantly.