Can I always specify only one shell in sheldon?

[mimikun]

For example:
(imagine a setting like this)

~/.config/sheldon/plugins.toml

shell = "bash"
[bash.plugins.foobar_bash_plugin]
github = "owner/foobar_bash_plugin"

shell = "fish"
[fish.plugins.foobar_fish_plugin]
github = "owner/foobar_fish_plugin"

I mainly use fish shell, but sometimes I use bash for features that are only available in bash.

[CharlesChiuGit]

i would really like to see sth similar!

[qnlbnsl]

This will create plugins.toml under $XDG_CONFIG_HOME/sheldon, on most systems this will be ~/.config/sheldon/plugins.toml. You can either edit this file directly or use the provided command line interface to add or remove plugins.

What if you change XDG_CONFIG_HOME in your bashrc to like .bash_config? It might break things in bash but you do say that it's not your daily driver. you could even do something like, set XDG_CONFIG_HOME to a different directory, then run Sheldon source and finally reset XDG_CONFIG_HOME . This way temporarily it would use a different file. Not ideal but might be a possible workaround

For example:
$XDG_CONFIG_HOME=~/.bash_config
eval "$(sheldon source)"
$XDG_CONFIG_HOME=~/.config

[gokuldas]

@qnlbnsl

set XDG_CONFIG_HOME to a different directory, then run Sheldon source and finally reset XDG_CONFIG_HOME

That hack has a few problems:

1. Ideally, all config should be in XDG_CONFIG_HOME. Some people may prefer to backup this directory entirely. This solution makes it hard (possible, but ugly).
2. XDG_CONFIG_HOME is often not set, and ~/.config is assumed as default. Your initialization code will have to be a bit more convoluted to handle all such cases.

Honestly, this should be easier to solve within sheldon, though admittedly I haven't looked at the code yet. I can lend a hand if this feature is acceptable.

[qnlbnsl]

@qnlbnsl

set XDG_CONFIG_HOME to a different directory, then run Sheldon source and finally reset XDG_CONFIG_HOME

That hack has a few problems:

1. Ideally, all config should be in XDG_CONFIG_HOME. Some people may prefer to backup this directory entirely. This solution makes it hard (possible, but ugly).
2. XDG_CONFIG_HOME is often not set, and ~/.config is assumed as default. Your initialization code will have to be a bit more convoluted to handle all such cases.

Honestly, this should be easier to solve within sheldon, though admittedly I haven't looked at the code yet. I can lend a hand if this feature is acceptable.

those are all good points. The only reason i am recommending my approach is because the OP does not seem to use bash as a daily driver.
Def would be easier to handle in the source code but i am also not familiar with it.
I would highly NOT recommend using the above workaround if you use different shells frequently.

[rossmacarthur]

I am keen to solve this problem but I first want to check whether any of the existing sheldon features could solve this for everyone.

1. Separate config and data directories

Typically for different shells most (if not all) the plugins are different so you can configure a separate config and data directory and have separate config files. For example for Bash you could put the config file at ~/.config/sheldon/bash/plugins.toml and configure the environment variables as shown.

# ~/.bashrc

# suggested locations, these could be anywhere
export SHELDON_CONFIG_DIR="${XDG_CONFIG_HOME:-$HOME/.config}/sheldon/bash"
export SHELDON_DATA_DIR="${XDG_DATA_HOME:-$HOME/.local/share}/sheldon/bash"

eval "$(sheldon source)"

2. Profiles

Profiles are available to select certain plugins. You can do this by setting SHELDON_PROFILE and specifying profiles on the plugin. Since the shell setting only changes the global match and templates settings, this means if for every plugin if you specify the use key then the global shell setting is irrelevant (the shell setting also affects the default templates but the source template is currently the same for all shells). For example:

[plugins.foobar_bash_plugin]
profiles = ["bash"]
github = "owner/foobar_bash_plugin"
use = ["*.sh"]

[plugins.foobar_fish_plugin]
profiles = ["fish"]
github = "owner/foobar_fish_plugin"
use = ["*.fish"]

Then when using it you would do the following

# ~/.bashrc

export SHELDON_PROFILE=bash

eval "$(sheldon source)"

[gokuldas]

@rossmacarthur I don't know if you're looking for an opinion - so here's my two cents.

I like option 1 more than 2. It helps keep the configuration separate for each shell. This makes sense where the dotfiles are managed using symlinks, like in case of GNU Stow.

Another suggestion is to convert the environment variables to arguments. Like so:

eval $(sheldon source bash)

This is a convention for a lot of other tools (eg: zoxide, direnv, starship and completions for kubectl, deno, etc). (Perhaps the data directory can have a default location that can be overridden in the config?)