feat: add update_config functionality

[sugatoray]

Adds a standardized config updating functionality

• [x] sorts the config for better readability
• [x] updates _name_or_path key in config with upload_repo
• [x] sets indentation of 4 spaces
• [x] allows adding other key-value pairs via kwargs
• [x] reduces code duplication
• [x] standardizes config-update across mlx-lm

The config file uploaded to huggingface repos is not sorted currently. This sorts the config files first and also updates the _name_or_path key in config.json with the HF upload_repo provided by the user.

Example of what is expected:

• mlabonne/NeuralMonarch-7B

{
    "_name_or_path": "mlabonne/Monarch-7B",
	...
}

What MLX repos have currently vs. what this will fix:

• sugatoray/mlx-alphamonarch-7b-q4bits

{
-   "_name_or_path": "/Users/sugatoray/.cache/huggingface/hub/models--mlabonne--AlphaMonarch-7B/snapshots/83a587946ece206325bf07c3bf11134a7256feb0",
+    "_name_or_path": "sugatoray/mlx-alphamonarch-7b-q4bits",
}

:bulb: Closes #532

[sugatoray]

cc: @awni Requesting code-review / CI runs.

[sugatoray]

@awni / @mzbac Please see if it is okay to setup the CI run now.

[sugatoray]

Thanks for fixing that. There's two changes I would make:

• Rename update_config to save_config as I think that is more clear (and just save it without returning it).
• Don't actually update the config in update_config. While I think what you did with the kwarg update could be nice in some cases, I don't know of any future use cases where will commonly want to send in kwargs and do an inplace update.. we can revisit in the future.

Thank you, @awni. I will make changes accordingly.

• Are you at all in favor of breaking the function into two? please see here
• Or, you would prefer to keep the save_config alone?

[awni]

Hi @sugatoray sorry I just saw your question:

Are you at all in favor of breaking the function into two?

The update config seems less useful for me since we only do an update to the one field and it happens in only a couple of places. It doesn't buy us much in terms of saving code or reducing duplication, but introduces a new function / API that obscures things a little.

[sugatoray]

Hi @sugatoray sorry I just saw your question:

Are you at all in favor of breaking the function into two?

The update config seems less useful for me since we only do an update to the one field and it happens in only a couple of places. It doesn't buy us much in terms of saving code or reducing duplication, but introduces a new function / API that obscures things a little.

Thank you @awni. I will change it to save_config.

I kept the kwargs in the function to allow for the user to add user-defined-metadata in the json file. But am dropping that functionality for now.

[awni]

@sugatoray I'm still waiting for you to let me know when to check this again right?

[sugatoray]

@awni I will make the change today and leave a note for you with a @mention.

[sugatoray]

@awni I have made code changes suggested in the code-review. Please take a look at it and merge it if all looks good to you.