Here's the associated issue: #206

@willynilly Sorry, I would rather not add code for specific editors. Adding .vscode to .gitignore would be my preference.

Well, that's too bad. Most developers do use and rely on specific editors (IDEs) and including some IDE settings helps facilitate scientific participation, review (especially with testing), and reproducibility. If you are worried about messing up other people's VSCode settings, one could postfix .default to the JSON settings files. Also, one can still contribute code without using VSCode. I think the conventional wisdom to exclude all IDE settings, while well intended, impedes the science more than it helps it.

I agree with adding .vscode to .gitignore. .idea, for pycharm, is already in .gitignore.

I think the conventional wisdom to exclude all IDE settings, while well intended, impedes the science more than it helps it.

Yes, without hearing otherwise I think excluding all IDE settings from the repo is the way to go. Especially for public open source repos where many people with totally diverse toolsets can look at the code. In a company setting where more uniformity is enforced (e.g. everyone must use the same editor) I could see arguments for sharing IDE settings within the repo.

If you don't want to go the "add .vscode to .gitignore" route then I'd appreciate if you explain (1) why you think the conventional wisdom is to exclude all IDE settings and then (2) explain why you think it would be wise to deviate from that conventional wisdom.

@jagerber48

Thank you for your questions:

1. I think many people want to exclude IDE settings because:

a) they want to exclude what they believe is optional or unnecessary from the code in order to reduce code complexity and perhaps reduce sources of error,
b) they believe that such settings may interfere with the personal settings of other developers and they want to maximize the freedom of other developers to participate by not forcing them to use a standard development environment.
c) they have heard from other trusted sources (e.g., other developers or trusted posts) that one ought not do it, and they defer to judgments of such sources

2. All of these reasons for caution have good intentions, but I think there is some room to doubt whether they apply in this case, and perhaps consider including some IDE settings in repos.

Those who might support including some IDE settings can address some of these earlier concerns AND can address other concerns not addressed by the exclusion camp. Firstly, optional IDE settings (e.g, default VSCode settings for tests) can reduce the complexity of setup and avoid setup errors. Secondly, it can help with scientific transparency and reproducibility, since setting up some development environment is necessary to test code, and default IDE settings reduce the barriers to entry for setting up a trusted development environment. Thirdly, offering default trusted IDE settings do not hinder developers because they can be made inactive by default (e.g. postfixing the VSCode settings files with ".default") and they can be ignored. Moreover, they can help document how their personal settings deviate from trusted default settings, and such deviations may explain differences in outcomes.

I do recognize that there are differences of opinion on this matter, and I will of course adopt and work within the decision of the lmfit group, whatever you may decide.

Here's a link where people are debating this issue:
https://stackoverflow.com/questions/32964920/should-i-commit-the-vscode-folder-to-source-control

@willynilly

I think the conventional wisdom to exclude all IDE settings, while well intended, impedes the science more than it helps it.

Well, you want to set the configuration for some choice (a perfectly valid one, I suppose, but not the only one) of development tools for anyone else who uses that tool to edit the code in this repository. And you somehow want us to believe that not doing this will "impede science"... um, what?

One does not need an IDE to run tests. Some of us understand this to be a feature.

I think many people want to exclude IDE settings because:
a) they want to exclude what they believe is optional or unnecessary from the code in order to reduce code
complexity and perhaps reduce sources of error,

Yup. The configuration file is literally for an IDE and is not about the code here.

Why would we support that? How would we support that? How do we know whether that configuration is even reasonable? If we change something in the code, do we now have to add a test for using that particular development system?

b) they believe that such settings may interfere with the personal settings of other developers and they
want to maximize the freedom of other developers to participate by not forcing them to use a standard
development environment.

Yeah, of course. I think you could replace "a standard" with "any".

c) they have heard from other trusted sources (e.g., other developers or trusted posts) that one
ought not do it, and they defer to judgments of such sources

I doubt that appeals to authority carry much weight here. Rather the opposite.

And, if we are going to have an editor war, I pick EDT. Unless your tool has a Gold Key, I claim victory. ;)

All of these reasons for caution have good intentions, but I think there is some room to doubt whether
they apply in this case, and perhaps consider including some IDE settings in repos.

You doubt what? Who cares what development tools are used?

I do recognize that there are differences of opinion on this matter, and I will of course adopt and
work within the decision of the lmfit group, whatever you may decide.

Why on earth would we tell people how to configure development tools?

Trying to be polite, and I would like to think that you mean well. But I am honestly not sure.

I do mean well and I think you do as well. I have made my case. It did not convince you. That's fine. We can have a differece of opinion. You are the maintainer of this code base. Not me. That's fine too. You make the final decisions for this repo. I am ok with that. I can always create a seperate tiny repo with default IDE settings for this project to help people more easily get started testing the code, which I think supports good science.To be clear, from my perspective, that you don't want to include IDE settings in the repo does not imply you are a bad scientist or that you are trying to impede good science. I think you are trying to be inclusive and transparent as well. I was suggesting a way to do that, which you disagree with. That's fine. The simple work-around for me is to publish a repo with some default IDE settings for this project, and invite any of you who want to share default IDE settings to put them in that seperate repo. It's not a big deal.

My understanding is that @newville prefers to exclude all default IDE settings from the repo he maintains. So I have created a pull request to add .vscode folder to the .gitignore: #212

I have also created a separate repo with the default IDE settings for VSCode here: https://github.com/willynilly/uncertainties-default-ide-settings

If anyone has some default IDE settings that they think will help others more easily test and/or develop the code, feel free to send me a pull request to this repo with those settings and I will try to add them.

One thing I have seen in other projects is a .editorconfig file for the Editor Config project which tries to define some subset of editor configuration that could be consistent cross-editor. I don't have experience trying to use it though.

Also, for this very specific case of running tests with pytest, I still wonder if adding a configuration file (or section of pyproject.toml) for pytest would be enough for VS Code to figure it out since I don't see a .vscode directory in other projects. Maybe that can be added in or after #211.