Programming

17366 readers

457 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

Plugins and config file (programming.dev)

submitted 3 months ago by grumpydeveloper@programming.dev to c/programming@programming.dev

9 comments fedilink hide all child comments

Hi,

I'm asking for opinions and preferences.

There is no right or wrong.

Scenario:

I have a tool (server component, api only, no gui) that has a config file and no per-user adjustable things. The admin can change things, of course.

Now the tool gets plugins, where to configure them?

All in one config file with plugins having a section for their things,
plugins get their own config file.
the main config points to a storage (database) with config options for everything, a kind of variant of 1.
something else/better

Hoping for a civil discussion ;)

Cheers

Grumpy

you are viewing a single comment's thread
view the rest of the comments

[–] joranvar@feddit.nl 1 points 3 months ago (1 children)

I'd try to share the config space as much as possible. Options 1 and 3 make sense then.

What feels "right" to me, when using NixOS and its module system, is that all config has the same shape, and is therefor easily moved to a different section, or to a section that is shared by a subset of plugins.

Con: It could lead to bad practices like strengthening dependencies between plugins (if they hard code to use a specific config option of another plugin).

Pro: But if you can discourage that, or use "deprecated pointers" to the new location of an option, the ease of moving shared config options to a more generic level can make it easier to maintain the total configuration. Developers of the separate plugins can build on what others have already done, and even synergize functionality (add a convenient integration if they see another option configured).

If some options are "secret", though, and you don't want those shared, they should either be in their own config (easier), or you'd need some access control on the configuration storage/file for each plugin (more work). Allowing a plugin to have a separate file for credentials, for instance, could be a good choice.

[–] joranvar@feddit.nl 5 points 3 months ago

As Flatfire mentions, another issue can arise if plugins can modify the config. I assumed config to be read-only for the software, only editable by the admins, and never by the tools themselves.