Sublime Forum

Automatically add/remove package settings to the user settings

#1

as the packages gets updated, the author/owner may add or remove any settings,

but as the user may have already made some changes to the package settings “in the User folder” there is no way for the user to get those new configurations unless he read the readme or the changelog.

so what if a new global file was made (something like the .no-sublime-package) which give the package author the ability to specify what was removed or added to the configs ex.

[
    new: {
        // new settings
    },
    removed: {
        // old settings
    }
]

which gets pushed automatically to the user package settings ?

1 Like
#2

You can modify a user’s settings easily using the API. I did migration like this a long time ago when I renamed settings of my packages and it still works Just Fine™.

0 Likes
#3

i thought it will be more user friendly so everyone can use it without any prev exp in python, however can u send me a link to where it have info about such feature

0 Likes
#4

I couldn’t quite find the code where I did this (maybe my memory is failing my), but the procedure is as follows:

def rename_settings(settings, rename_map):
    changed = False
    obj = object()
    for old_name, new_name in rename_map.items():
        value = settings.get(old_name, obj)
        if value is not obj:
            settings.set(new_name, value)
            settings.erase(old_name)
            changed = True
    
    return changed

    
settings = sublime.load_settings("Preferences.sublime-settings")
rename_map = {"old_setting_name": "new_setting_name"}
if rename_settings(settings, rename_map):
    # write changes to disk
    sublime.save_settings("Preferences.sublime-settings")
2 Likes
#5

FOCKEN AWESOME, that gave me another idea :bulb:

what about automating this ?, so instead of each package author including this in his package, maybe we can turn this little code into a package by itself that take care of this from time to time, so the flow would be

  1. sublime app open
  2. the python file waits for all packages to finish loading
  3. go through each settings file in the packages/user folder
  4. check only the files that has its name matching a package name to avoid removing settings for the wrong package, ex.

HTML.sublime-settings == Packages/HTML or Installed Packages/HTML

4.remove the config that is in the user settings but not in the package.

** for the option renaming, this have to be included in the package it self ofcourse.

0 Likes
#6

Just change this

by this

When the command is run

and it’d be great. It’s not every restart that, first, you get a package update, and it’s not every package update that you get some settings renamed. I don’t think it’s worst it.

Here’s what I think would be good:

def plugin_loaded():
    if not sublime.load_settings('SettingsUpdater.sublime-settings').get('auto_update_on_start'):
        return
    sublime.run_command('update_settings')

class UpdateSettingsCommand(sublime_plugin.ApplicationCommand):
     def run(self, packages=None):
         if packages is None:
             packages = get_every_packages()
         for package in packages:
              update(package)
1 Like
#7

Imo this task can easily be handled by each package individually and engineering something to centralize this would be way more bothersome than all packages just copying my snippet above combined.

2 Likes
#8

the reason after the python file waits for all packages to finish loading so when the step #4 check only the files that has its name matching a package name to avoid removing settings for the wrong package
we dont take any extra time re-searching the packages.

also this wont work on each package update, thats what i meant by from time to time so maybe the script will have an option where the user define when this script should run daily, weekly, monthly

0 Likes
#9

i understand ur point, the reason behind the global idea is more of thinking globally, like instead of waiting for every package author to include this which he may or maynot forget or think it would be too much, we make a package that take care of this once and for all, which i think is a better solution.

0 Likes