-
-
Notifications
You must be signed in to change notification settings - Fork 447
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC]: add support for persisting REPL configuration across sessions #2510
Comments
Re: The only REPL option which doesn't seem sensible for persistence is Re: commands for loading and saving configuration files. Yes, this makes sense. We should add these. |
But what about the default persistence? Does it make sense persisting |
I am not sure it makes sense to persist settings by default. Instead, I'm thinking a user should explicitly opt-in to persisting the settings for a specific REPL session. And whenever settings are updated, they shouldn't be persisted until a user explicitly asks them to be persisted. Otherwise, any setting experimentation ends up overriding previously saved settings, which may not be desirable. We could, I suppose, persist settings by default on exit, but it is not clear to me that they should be auto-loaded the next time a user starts a new REPL session. The use case I am imagining is if a user's computer crashes and they want to restart the REPL with the same settings as when the crash happened. This is a "restore" use case. For the restore use case, we could persist settings just before exit to a file named, e.g., For auto-loading, a user could explicitly persist settings to a file named To load a specific configuration file on REPL instantiation, a user would be required to pass the configuration file to the REPL constructor via a new REPL option (e.g., |
Behaviors from other REPLs:
function customize_colors(repl)
repl.prompt_color = Base.text_colors[:cyan]
end
atreplinit(customize_colors) This is how you can customize the theme using
c.InteractiveShell.autoindent = True
c.InteractiveShell.colors = 'LightBG'
c.InteractiveShell.confirm_exit = False
c.InteractiveShell.deep_reload = True
c.InteractiveShell.editor = 'nano'
c.InteractiveShell.xmode = 'Context'
c.PromptManager.in_template = 'In [\#]: '
c.PromptManager.in2_template = ' .\D.: '
c.PromptManager.out_template = 'Out[\#]: '
c.PromptManager.justify = True
c.PrefilterManager.multi_line_specials = True There is no automatic persistence of changes made in the REPL (like themes). ie, if I change the theme, I would have to change it again the next visit (unless I make a profile configuration). I think we should stick to the |
Also, I was wondering if we could extend the |
Thanks for the R&D. Re: path for storing default configuration. I don't think I agree. Personally, I am always a little annoyed when libraries/apps start cluttering my home directory. Not clear to me why we'd want to not use the system configuration directory. Storing configuration is what it's for. Re: extending |
Yeah, I am curious why so many services don't use the config dir. |
Update: it looks like FHS does allow for storing files in a user's home directory (ref), but I don't believe this applies on Windows. We could, however, allow a user to specify the configuration directory, overriding default resolution. Regardless, I think, for walking the file system to find a configuration file, we should begin with local directories and walk until reaching the root directory. Once at the root directory, check for a For storing the default and last session configuration files, I think using the resolved system configuration directory should be fine; no need to clutter a user's home directory by default. |
Yeah, |
Update: seems like a user's home directory is commonly used for two reasons: (1) easy to find and (2) allows modification without needing elevated permissions. The compromise is using |
May be worthwhile seeing how other REPLs, such as Julia's, handle the Windows case. |
I was running Julia on windows when writing the above observations.. |
@Snehil-Shah Including the configuration file path? I'm a little surprised that |
Yes, startup file also in the |
I believe this is an artifact of the Windows Linux Subsystem. Reading through SO, it seems one possible place this corresponds to is |
I am sorry, I don't think I follow. Can you elaborate on this..? |
What's the value of |
Interesting. Okay, it seems my understanding of Windows path conventions are outdated. Given that you've demonstrated that there's uniformity across Linux, Mac, and Windows, I'll stand down. Defaulting to a |
To summarize, starting from |
In what circumstance would |
Yeah, maybe if the user adds their own configuration in |
Typically, users never directly add files to root dot directories. That is managed by the application. I'd think we should just have a canonical location. |
Makes sense. Let's stick with |
Description
This RFC proposes adding support for REPL configuration files to persist user preferences (eg. settings) across each session.
Questions
What to persist? For starters, we can persist settings, themes, and most of the options that the REPL receives during instantiation like
inputPrompt
,welcomeMessage
,padding
etc. I think we should avoid saving options likeload
and others which are something that is typically used per session.If we end up NOT saving anything else than what already can be passed as REPL options, does it make sense to have commands for loading custom configuration files? As loading a configuration or just loading the REPL options is pretty much the same process. In that case, just having a single configuration that remembers user preferences is more than enough, as the user can have scripts with specific options for different use-cases/profiles.
Other
Saving command history is an existing TODO, once we support that maybe we can also auto-persist them. I believe IPython does this.
Checklist
RFC:
.The text was updated successfully, but these errors were encountered: