Skip to content
This repository has been archived by the owner on Jan 29, 2024. It is now read-only.

Possible settings for devcontainer.json #159

Open
pamelafox opened this issue Sep 18, 2023 · 4 comments
Open

Possible settings for devcontainer.json #159

pamelafox opened this issue Sep 18, 2023 · 4 comments
Assignees
Milestone

Comments

@pamelafox
Copy link
Collaborator

Just diffing our devcontainer.json with another similar one:

I think we probably do want these settings:

"python.defaultInterpreterPath": "/usr/local/bin/python",
"python.linting.enabled": true,
"python.testing.pytestEnabled": true,
"python.testing.unittestEnabled": false,

I'm not sure if we want these, or if they are user-specific (not all users like formatting on save):

"[python]": {
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.fixAll": true
},
"editor.defaultFormatter": "ms-python.black-formatter"
},
"python.formatting.provider": "black",

Excluding files is useful, though what we exclude may differ slightly:
"files.exclude": {
"**/*.coverage": true,
".ruff_cache": true,
".pytest_cache": true
},

This is for a third-party extension for listing tasks, which is only useful if we add tasks:
"taskExplorer.enabledTasks": {"python": false},

@pamelafox
Copy link
Collaborator Author

@kjaymiller
Copy link
Owner

TLDR: I think adding the first stuff is definitely a good idea and the others maybe after we talk with the VS Code Python team on their best practices.

I think we probably do want these settings:

"python.defaultInterpreterPath": "/usr/local/bin/python",
"python.linting.enabled": true,
"python.testing.pytestEnabled": true,
"python.testing.unittestEnabled": false,

I agree these should be added.

I'm not sure if we want these, or if they are user-specific (not all users like formatting on save):...

I think we have to think about what we want to accomplish. If our goal from these repos is a "This is the Microsoft suggested way of doing this, I think we should talk with Lucianna and other VS Code specific folks and include what they believe is the best experience.

Excluding files is useful, though what we exclude may differ slightly:

I think excluding files makes a lot of sense but wouldn't we just not include them in the repo? More of a is this a devcontainer.json problem or a .gitignore one.

This is for a third-party extension for listing tasks, which is only useful if we add tasks:

While I love TaskExplorer I don't think it's considered the standard way to manage tasks. So I don't think it would be good to add in this case. If I remember correctly, don't profiles get added to the devcontainer as well which would mean that users have their preferred extensions included. I think that's the place for that specific setting.

@pamelafox
Copy link
Collaborator Author

Re excluding files: that setting hides those folders in the VS Code file explorer, which is distinct from .gitignore which makes sure they're not checked in. And those files will get created by the tools we're using, so we can't avoid their creation.
The default Python Profile includes it, at my suggestion, but that requires importing:
microsoft/vscode-python#21374 (comment)

I agree on no for task explorer.

I'm so torn on these ones:

"[python]": {
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.fixAll": true
},
"editor.defaultFormatter": "ms-python.black-formatter"
},
"python.formatting.provider": "black",

I ended up putting them in my profile for my talk, but I've had project contributors ask why I don't have them in project dev containers, so yeah.. really a DX design question.

@kjaymiller
Copy link
Owner

Yeah I think it's okay to add and we can remove if there are complaints or it's later determined that isn't best practice.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Status: No status
Development

No branches or pull requests

2 participants