Open wildanrfq opened 1 year ago
The problem with this implementation in particular is that it isn't reload-safe. Technically speaking jishaku.Flags
isn't fully reload-safe either, but if you use the environment variables you can create persistent settings anyway.
The approaches to dynamic config like this I have in my head are:
jishaku reload
or something to carry settings over - this is not ideal because settings will not survive a full unload-load, it wouldn't survive a reload by any non-jishaku means, and in the case of using things like config classes, would result in old instances of jishaku being persisted in memory due to lingering referencesbot.jishaku_config
) - this kind of duck typing could be hard for linters and things like pylance to understand, and if it needs a config class instance, then it results in the same lingering reference problem as above. The best I could probably do is have jishaku expose a TypedDict and then allow you to set these things through that instead, but I think this approach just sucks for ergonomics in general (Where would a user traditionally put such an assignment? In their bot class? What if they don't have one? What if they need a really large config and want separation of concerns between the configuration and their other stuff?)sys.modules
- super ultra gross, this is a real thing that libraries do sometimes and Python itself used to do it for systems without threading support, I just think it's real nasty~/.config/jishaku.toml
) - this approach is good for separation but kind of not obvious and "acts at a distance", behavior between users is now dependent on something that is not easy to find and that the user has to explicitly know and remember about, config wouldn't be version controllable together with its bot, what if people want different configs for different bots on the same machine, what if the config needs to be 'rich' (e.g. contain python functions), etcUltimately all of these approaches suck in some way that's blocked me from really doing this in the long run - better configuration is something heavily requested and I've wanted to add, but I need to think it over and try to minimize the footguns involved in implementing it.
The Problem
In the jishaku python's command, there's some aliases we can use to shorten our evaluation code, such as
me
forContext.me
,get
fordiscord.utils.get
, etc.I wonder if configurable aliases like those is possible to implement.
The Ideal Solution
My idea is to add more aliases to jishaku. Something like this design is what I'm thinking of:
The Current Solution
Fork the repository and add the desired aliases manually into the
get_var_dict_from_ctx
function inrepl_builtins.py
file.Summary
A feature that allows the user to configure or add jsk py aliases to use in the command.
I don't know if this feature is already possible to do or implemented, so I'm making an issue to make sure.