Is there a way to disable loading of configuration from appsettings.json

[AshD]

I would like to load my configuration differently instead of appsettings.json.

I can supply the needed configuration like this

            builder.Services.AddSingleton(onnxStackConfig);
            builder.Services.AddSingleton(stableDiffusionConfig);
            builder.Services.AddOnnxStackStableDiffusion();

But these lines in Registration classes cause issues

serviceCollection.AddSingleton(ConfigManager.LoadConfiguration());
serviceCollection.AddSingleton(ConfigManager.LoadConfiguration<StableDiffusionConfig>(nameof(OnnxStackConfig)));

If I comment the above lines, It loads the configuration from the data I give it but then I have to modify the source of the library, which is not a good solution.

Looking for some guidance on the best way to supply the configuration without appsettings.json

Thanks,
Ash

[saddam213]

The appsettings is also needed by .NET Core, logging etc, so the file will need to stay, but you can move the model stuff to another file or database.

The OnnxStackConfig and StableDiffusionConfig can just be replaced after Registration is called, as its just a singleton

// Register
builder.Services.AddOnnxStackStableDiffusion();
 
// Replace Singletons
builder.Services.AddSingleton<OnnxStackConfig>(stableDiffusionConfig);
builder.Services.AddSingleton<StableDiffusionConfig>(stableDiffusionConfig);

I will add some proper Registration overloads for the next version to make this a bit nicer to use

[saddam213]

Ok, I added some convenience methods to registration so you can easily override the default config in a much nicer way
Commit

Now you can override both configs like:

builder.Services.AddOnnxStack(onnxStackConfig);
builder.Services.AddOnnxStackStableDiffusion(onnxStackStableDiffusionConfig);

//Load Custom `IConfigSection` If required
builder.Services.AddOnnxStackConfig<MyCustomSection>();

Note: you will need to call AddOnnxStack() explicitly before AddOnnxStackStableDiffusion if you are using custom configs

[AshD]

Thanks Adam. I will try it out.

[james-s-tayler]

I was thinking of submitting a PR around this also, as I think the fundamental design of having to register the OnnxStackConfig is kind of problematic, and I'm not entirely sure it makes sense from a design perspective, but was keen to get your thoughts on it @saddam213.

This pain point was the second one I bumped up against after I solved the problem of how to actually get it running under Linux. When I was writing the tests for loading the model my initial assumption was that the programming model would be that the method to load the model would simply take some object that contained the necessary information required by the library to load it. I was a little confused to discover that the method to load the model instead took the name of the model, and the only way to pass the information required to load the model was to through IConfiguration.

I think the coupling to IConfiguration for this information is far more of an implementation detail than an absolute necessity. My first assumption was that it was probably a design choice that made pragmatic sense in the context of the accompanying apps you've been working on as part of this repo, but if I'm just consuming this library itself to use in some other arbitrary application, then what models are available to load, and when in the lifecycle of the application they get loaded is also going to be arbitrarily defined by the nature of the program making use of the library. As such the tight coupling to managing this information through IConfiguration doesn't quite make sense to me and feels very restrictive.

For instance think about how to handle something like what A1111's stable-diffusion-webui does where you finish training a dreambooth model or downloading a new model from Civit.ai into your models folder, you hit the 'refresh' button in the UI and it updates the list of available models, and you can then chose to load the new model. This all happens at runtime, and to support that via IConfiguration you'd have to utilize something like IOptionsMonitor<T> as shown here. In theory an application consuming this library may wish to manage that information through some arbitrary datastore, so that would require then having to implement a custom IOptionsMonitor<T> that integrates with that datastore or for the library to provide all such integrations out of the box, which feels like it adds quite a bit of friction when instead the library itself could just "you tell me everything I need to know in order to load a model, and I'll load it for you, but how you manage where the information lives is an implementation detail of your application".

The reason I was thinking to submit a PR around it was the integration tests are currently forced to run on CUDA due to this coupling as it's defined in the appsettings.json and tightly coupled in this way, and the present design doesn't have enough flexibility built in to allow (without having to make code changes) windows users to run them on DirectML (or AMD users to run them at all?) etc. So, I was looking at sitting down and thinking about if I wanted them to be runnable by anyone regardless of operating system or hardware utilizing just IDE-level run configurations then what changes need to be made to support that?

Thoughts?

[saddam213]

1. I don't plan anything, I just get bored easy
2. I have never used another stable diffusion app, so no idea how they work
3. There is no need to use appsettings, just use objects, I just found the json and easy way to store model details

Just don't call the Register methods and load your own Configs

Edit:
I think you have a misconception, there is no coupling to IConfiguration the app settings just holds cached data to be passed at startup, this can be EMPTY (the json element may need to exist, but that can be fixed)

You can add/remove models at runtime using the ModelService this is what the UI does after it downloads a model,
appsettings was used for convenience, its NOT required, it was already there, so made sense to use it for cache data

I think I addressed the main issue which was the Register Methods had no helpful overload, leaving you to do it manually, these have been added now so you can more easily use without the appsettings content

[saddam213]

I can add some changes to improve runtime loading, make it a bit nicer to use

At the moment you need to use the OnnxModelService to load a IOnnxModelSetConfig, but I could add some convenience methods to StableDiffusionService for Load, Unload to save people needing to use both services in this case