https://pantsbuild.org/ logo
Join Slack
Powered by
vscode users: will it be problematic for the Pants...
# development
f
vscode users: will it be problematic for the Pants repo to have a workspace-specific 
.vscode/settings.json
file? https://github.com/pantsbuild/pants/pull/20094
context: I would like to add a Rust-specific setting to allow VSCode to find the Pants Rust source.
f
I usually gitignore 
.vscode
w
oooh, I don't like that at all
It overwrites the existing settings?
Ah wait, JUST for our repo?
f
I mean I already have a workspace-specific settings.json for vscode for pants
is this the line you want to add? 😄
Copy code
❯ rg rust .vscode/settings.json
10:    "rust-analyzer.linkedProjects": ["src/rust/engine/Cargo.toml"],
f
yes
Ah wait, JUST for our repo?
just for our repo yes
g
As an other editor user whose config is never checked in, ~meh. But would we feel the same way if we had 
.dir-locals.el
, 
.vimrc
, 
.intellij
for the same, etc? It gets bloaty quite fast.
w
I originally read (like 4 times I misread it) that as "a Pants repo", if it's for the mainline repo. I'm generally pretty meh about shared workspace settings, with as narrow scope as possible to avoid overriding user stuff.
f
I have some other personal settings in that file though, and git will just complain about their being a local file there if i try to check it out, forcing me to maintain/deal with a branch and cherry picks if i want to keep my settings. I'm pretty 👎🏻 on this
f
that is the critical point I needed to know; no way to keep user-specific settings for the repo
so will close the PR
g
I mean, I'm on Josh's team here but that is definitely not true. You can easily diverge the file and just keep it unstaged
f
you're technically right but that will drive me nuts
w
As a counter point, depending on what it is - having "complicated" settings does encourage new contributors a tad bit more. Example: https://github.com/embassy-rs/nrf-softdevice/blob/master/.vscode/settings.json Otherwise, would need to be documented - I wouldn't figure out those on my own
g
In a better world LSPs wouldn't require per-editor config and would instead have config files like other, sane, tools.
w
Counter counter point - this might be something we could put in a VSCode extension?
f
my suggested solution: commit to 
editor-configs/vscode/settings.json
and in some readme suggest something like
Copy code
jq -s '.[0] * .[1]' editor-configs/vscode/settings.json .vscode/settings.json > .vscode/settings.json
as a way to merge in suggested config
or just document setup stuff
w
Can you have separate settings in a multi-root workspace?
f
it was annoying having to figure out how to set this up
but IDE stuff is personal enough where I think thoughtful documentation is better than automation
w
f
I'd have to play around with it to be sure
w
@flat-zoo-31952 Do you re-create your settings everytime you re-clone the repo?
f
no, i just know this particular setting
and I don't re-clone much
w
Ah, I have like 5-10 clones at any given time
f
I use worktrees if I need that, but I always have a primary worktree
f
I somewhat thought they could have like a 
.vscode/settings.json
and 
.vscode/settings-user.json
and let the latter override the former.
w
There is a ticket for a settings.local.json - but no go as far as I know. Nor can you "extend" from other settings from what I've seen
f
I'll add to documentation instead then. At least, can be useful as a starting point for people.
👍🏻 1
w
Custom code-workspace might be the solution - that way, if you want the standardized format, you can use that 🤷 To Tom's point, do we want any IDE-specific settings
[audible shrug]
f
cool, i didn't know about code-workspace
I'll try and test this out, and then we could document how to use code-workspace instead of settings.json
4 Views
Open in Slack
PreviousNext
Powered by