Overwriting default settings should be possible on fine-grained level

[viper-admin]

Created by @aterga on 2016-11-23 15:59 Last updated on 2017-04-05 06:14

• OS: All
• Version: 0.4.0

Use case: one wants to increase the verification timeout for a particular back-end.

Problem: one needs to copy the entire "viperSettings.verificationBackends" object into the User Settings. Even overwriting a single backends is impossible.

Ideal solution: support something like viperSettings.verificationBackends.silicon.timeout: 100500.

Potential problems: overwriting might cause issues with version controlling the settings; this syntax might not be supported.

[viper-admin]

@aterga on 2017-01-12 09:37:

• changed priority from major to minor
• edited the description

[viper-admin]

Bitbucket user rukaelin commented on 2017-02-20 13:40

v 0.5.405: overwriting default settings is now possible in a finegrained way. e.g.:

"viperSettings.preferences": {
  "v": "0.3.0",
  "logLevel": 5
}

is a valid configuration, the not specified values are taken from the default settings. For the verificationBackends fine-grained overwriting is more complicated, since there are multiple default values, (for carbon and silicon). completing a silicon backend with defaults from the carbon settings can lead to counter intuitive problems. therefore, for now, you should still provide the complete object for the backends.

idea: we could add the default backends to the user-defined backends to allow changing only one of the backend while still being able to use the other

[viper-admin]

@aterga commented on 2017-02-22 16:54

This approach seems error-prone because of the way you merge the settings. What if the "v" filed is not specified? Would those settings work for all versions fo the extension? If not, then the merging rules for "v" will differ from merging rules for other settings, right? That seems very confusing. Need to discuss.

[viper-admin]

@aterga on 2017-03-05 13:46:

• changed component from (none) to Settings

[viper-admin]

Bitbucket user rukaelin commented on 2017-03-21 14:38

fine grained overwriting of the settings is now also possible for the backends. When the same name is used for the partially specified backend as for a default backend, the missing values are filled in. The non mentioned default backends are added to the specified ones and are therefore always usable.

[viper-admin]

@aterga commented on 2017-03-21 16:33

If this is the case, then how do you decide if the settings the right version?

[viper-admin]

Bitbucket user rukaelin commented on 2017-03-22 07:36

For the backends it works well, if the version field is missing, the IDE detects that the settings as old. This works, because the backends are a list of objects.

For all other settings, VSCode automatically takes the values of the default object for fields not specified in the user and workspace settings. Therefore, when removing the version filed the IDE thinks the settings are up to date.

I could not figure out how to avoid this problem yet.

[viper-admin]

@aterga commented on 2017-03-22 11:16

Could you remind me the scenario in which we needed versions of settings?

[viper-admin]

Bitbucket user rukaelin commented on 2017-03-22 11:39

It is needed because not all changes on the settings can be done backwards compatibly. Versioning ensures that the user settings do not became invalid unnoticed. E.g. when renaming a field in the settings, the user might wonder why changing his value of the settings (with the old name) does not have any effect.

[viper-admin]

@aterga commented on 2017-03-22 15:42

What if we use schemas? Check out this website: http://json-schema.org

[viper-admin]

Bitbucket user rukaelin commented on 2017-03-22 16:03

That is interesting for validating the son file, but here it does not help because the problem is about not knowing what part of the settings is from the default settings and what was configured by the user.

e.g. the IDE cannot distinguish the case where a user copied all default settings from a case where his settings are empty.

[viper-admin]

@aterga commented on 2017-03-22 16:08

Ok, then the level of granularity at which it is possible to customize the settings must be such that every Json object has a version number. Like in the case of the backends. And if we want to simplify the customization efforts for particular settings, we will have to split some settings into smaller Json objects. Does that make sense?

[viper-admin]

Bitbucket user rukaelin commented on 2017-03-23 10:23

Yes, that is the way we solved it up until now. However, VSCode has become smarter and it is now completing partially specified settings using the default settings.

e.g.:

Default Settings:

"viperSettings.nailgunSettings": {
  "v": "0.5.440",
  "serverJar": "$viperTools$/nailgun/nailgun.jar",
  "clientExecutable": "$viperTools$/nailgun/ng",
  "port": "*",
  "timeout": 5000
}

User Settings:

"viperSettings.nailgunSettings": {
  "v": "0.5.440",
  "timeout": 5000
}

Then For the IDE viperSettings.nailgunSettings.port is still *

And in earlier versions of VSCode it used to be undefined

Currently I do not know how to force the old behaviour of VSCode.

For the backends it is different, because they are stored as a list instead of an object.

[viper-admin]

@aterga commented on 2017-03-23 12:07

Is it possible to make the "v" field of "viperSettings.nailgunSettings" mandatory?

[viper-admin]

Bitbucket user rukaelin commented on 2017-03-28 09:11

The version filed existence check and the version field hashing are implemented and will be deployed with v1.0.0

[viper-admin]

Bitbucket user rukaelin commented on 2017-04-05 06:14

As we delayed the deployment of 1.0.0, it is already shipped with Viper v.0.6.0

[viper-admin]

Bitbucket user rukaelin on 2017-04-05 06:14:

• changed state from new to resolved