Starship and Oh-My-Zsh provide Scala support, and detecting a .metals directory causes it to assume that the user is in a Scala project.
Using the VSCode extension immediately creates this in the user's $HOME directory, which results in invocation of the Scala toolchain upon detection, for every command.
While this is desirable within a Metals workspace, this is both a performance and functionality hit for such shell script users.
To Reproduce Steps to reproduce the behavior:
Install Metals-VSCode
Generate a Scala project, e.g. sbt new scala/scala3.g8
Open a .scala source file with VSCode
Observe a .metals dotfile directory being created to hold versions-meta.json at $HOME/.metals.
Expected behavior
XDG standards are preferable where possible.
As versions-meta.json appears to be a configuration file, it should go in an XDG Configuration directory for Metals.
A rough implementation would look like this:
Take $XDG_CONFIG_DIRS if defined, otherwise fall back to the first of:
$XDG_CONFIG_HOME if defined
$HOME/.config if it is present on the filesystem
$HOME (as .metals)
Scan all directories in the list for metals (note the lack of a . (dot) prefix on all but $HOME).
If present, use that directory. If absent, create it in the first extant directory from this list order:
$XDG_CONFIG_HOME as metals
$XDG_CONFIG_DIRS as metals
$HOME/.config as metals
$HOME as .metals
This would comply with XDG's spec, reduce home-directory pollution, and ensure proper functionality of the various popular zsh, bash, and fish prompts.
Currently, this is handled in src/util.ts, wherein the only path searched is os.homedir.
Alternatively, using VSCode's mechanism for configuration storage may be sufficient for viability, though this relies on the .metals directory not being consumed by anything but the VSCode extension, which may not be an assumption that can be safely taken.
Installation:
Operating system: Linux
VSCode version: 1.71.0-insider 078f8e986d44de2c
VSCode extension version: 1.19.7 prerelease
Metals version: (found in VSCode settings, under metals.serverVersion)
Describe the bug
Starship and Oh-My-Zsh provide Scala support, and detecting a
.metals
directory causes it to assume that the user is in a Scala project.Using the VSCode extension immediately creates this in the user's
$HOME
directory, which results in invocation of the Scala toolchain upon detection, for every command.While this is desirable within a Metals workspace, this is both a performance and functionality hit for such shell script users.
To Reproduce Steps to reproduce the behavior:
sbt new scala/scala3.g8
.scala
source file with VSCode.metals
dotfile directory being created to holdversions-meta.json
at$HOME/.metals
.Expected behavior
XDG standards are preferable where possible. As
versions-meta.json
appears to be a configuration file, it should go in an XDG Configuration directory for Metals.A rough implementation would look like this:
$XDG_CONFIG_DIRS
if defined, otherwise fall back to the first of:$XDG_CONFIG_HOME
if defined$HOME/.config
if it is present on the filesystem$HOME
(as.metals
)metals
(note the lack of a.
(dot) prefix on all but$HOME
).$XDG_CONFIG_HOME
asmetals
$XDG_CONFIG_DIRS
asmetals
$HOME/.config
asmetals
$HOME
as.metals
This would comply with XDG's spec, reduce home-directory pollution, and ensure proper functionality of the various popular
zsh
,bash
, andfish
prompts.Currently, this is handled in src/util.ts, wherein the only path searched is
os.homedir
.Alternatively, using VSCode's mechanism for configuration storage may be sufficient for viability, though this relies on the
.metals
directory not being consumed by anything but the VSCode extension, which may not be an assumption that can be safely taken.Installation:
metals.serverVersion
)Additional context
Starship Scala Configuration
Search terms
Home Directory
,Dotfiles
.metals
XDG_HOME
XDG_DATA