Skip to content
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

Extension settings should be stored in default location #1149

Closed
cbrnr opened this issue Jul 14, 2022 · 12 comments
Closed

Extension settings should be stored in default location #1149

cbrnr opened this issue Jul 14, 2022 · 12 comments

Comments

@cbrnr
Copy link

cbrnr commented Jul 14, 2022

Describe the bug
Extension settings are usually located in ~/.vscode/extensions. However, the settings for this extension are stored in ~/.vscode-R.

To Reproduce
Here's an example of my setup, all extensions store their settings under .vscode:

~  ls ~/.vscode/extensions
adpyke.codesnap-1.3.4                     ms-python.python-2022.10.0            ms-toolsai.jupyter-renderers-1.0.8
github.vscode-pull-request-github-0.46.0  ms-python.vscode-pylance-2022.7.20    quarto.quarto-1.26.0
julialang.language-julia-1.6.24           ms-python.vscode-pylance-2022.7.30    reditorsupport.r-2.5.0
kevinrose.vsc-python-indent-1.17.0        ms-toolsai.jupyter-2022.6.1101950301

This does not include vscode-R, which has its own folder in my home:

~  ls ~/.vscode*           
/Users/clemens/.vscode:
extensions  argv.json

/Users/clemens/.vscode-R:
tmp  init.R  request.lock  request.log  settings.json

I could try to fix this if people agree this is a bug.

Expected behavior
I expected the settings of vscode-R to be in the standard location under ~/.vscode/extensions.

Environment (please complete the following information):

  • OS: macOS 11.6.7
  • VSCode Version: 1.69.1
  • R Version: 4.2.1
  • vscode-R version: 2.5.0
@cbrnr cbrnr added the bug label Jul 14, 2022
@renkun-ken
Copy link
Member

For self-managed R sessions, it might not be very convenient to have the files located in the extension folder (e.g. /home/user/.vscode-server/extensions/reditorsupport.r-2.5.0) since it contains the version of the extension. I think this is a main reason we keep such a folder at the moment.

@cbrnr
Copy link
Author

cbrnr commented Jul 14, 2022

I see. Could this be solved in a different way (e.g. creating a symlink if someone wants a self-managed session)? The relevant code snippet could be updated as follows:

configdir = list.files(".vscode/extensions", pattern="reditorsupport*")
if (interactive() && Sys.getenv("RSTUDIO") == "") {
  source(file.path(Sys.getenv(if (.Platform$OS.type == "windows") "USERPROFILE" else "HOME"), configdir, "init.R"))
}

@eitsupi
Copy link
Contributor

eitsupi commented Jul 14, 2022

I think VSCode Server has a different directory name (.vscode vs .vscode-server).
Is there any reason to change the storage location at the risk of it not working?

@cbrnr
Copy link
Author

cbrnr commented Jul 14, 2022

My reasons are (1) it's easier to find the settings folder when it's in the standard location, and (2) I don't like applications cluttering my home directory (I know it's a hidden folder, but still). Of course these reasons might not be enough to warrant the change.

@eitsupi
Copy link
Contributor

eitsupi commented Jul 14, 2022

See also #495

@cbrnr
Copy link
Author

cbrnr commented Jul 14, 2022

Yes, #495 is very much related! Instead of ~/.vscode-R, if within ~/.vscode/extensions is not an option, you might want to consider using ~/.config/vscode-R instead.

@renkun-ken
Copy link
Member

~/.config/vscode-R seems to be a better place.

@benz0li
Copy link
Contributor

benz0li commented Aug 14, 2022

Folder ~/.vscode-R is according to requirements – at least for Unix-like operating systems. Nothing wrong with that.

Should this folder be abandoned, do not hard-code ~/.config/vscode-R but follow the guidelines as outlined in #495 (comment) by @LiteracyFanatic.

@github-actions
Copy link

This issue is stale because it has been open for 365 days with no activity.

@github-actions github-actions bot added the stale label Aug 15, 2023
@github-actions
Copy link

This issue was closed because it has been inactive for 14 days since being marked as stale.

@LucasFA
Copy link
Contributor

LucasFA commented Jan 20, 2024

A backwards compatible change would be to use the XDG locations if they exist (ie, use XDG_CONFIG_HOME/vscode-R/ or fall back to ~/.config/vscode-R/). If neither of those exist, move ~/.vscode-R (if it exists) to XDG_CONFIG_HOME/vscode-R. Of course if the XDG_CONFIG_HOME variable is not set it would fall back to use ~/.config/vscode-R as new default behaviour.

Regarding @benz0li's comment, it is worthy to note that the linked spec explicitly mentions and links to the XDG specification and the Glib conventions, here in the GNOME documentation which also use the XDG spec.

Somewhat related, the wakatime-cli family of extensions are trying to migrate, too. Issue on the main project, the jetbrains extension and the vim extension

Off-topic, but I do not see the value of auto-closing issues. That's like automically tagging it wontfix. An unhandled issue is not intrinsically less worthy than a new issue simply by nature of being older. If this does not reopen it, I will open another one to continue this conversation unless asked not to by a mantainer.
Edit: weird. I was pretty sure the stale-bot would reopen the issue by its default settings

@mayurankv
Copy link

I also find this quite annoying and would love for XDG conventions to be respected. Ideally an environment variable would specify the path, followed by XDG conventions, followed by ~/.vscode-R. This would let those of use who manage our dotfiles carefully set the location explicitly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants