Reintroduce settings_yml to config subapi as an interface
#19078
Conversation
…erface to only expose scheme-related oprations
| test | ||
| \""" | ||
| settings = conan_api.config.settings_yml | ||
| ConanOutput().info(f"settings.fields: {settings.fields}") |
There was a problem hiding this comment.
User was commenting about an update use case, it doesn't look possible with this interface. IIRC, something like adding new settings, then saving the file to disk, as a way to create custom variations?
May be worth to investigate a bit further, I wonder why not using settings_user.yml instead.
| @property | ||
| def settings_yml(self): | ||
| return load_settings_yml(self._conan_api.home_folder) | ||
| if self._settings_yml is None: |
There was a problem hiding this comment.
We still need to be careful with user side code keeping a reference to the returned object, that will not be invalidated and updated after a reinit() after updating the conf.
This would need a private move constructor to keep the internal self._settings_yml reference and just move the new loaded settings.yml into the existing reference.
That sounds too much for this PR, I think lets first make the API available, we can address the issue of dangling references later, very minimal use case.
2 participants
Changelog: Fix: Reintroduce
settings.ymlaccess toconfigsubapiDocs: TODO
This new approach creates an interface to avoid users having access to non-scheme related methods, as this object won't have the settings values filled.
Maybe the name can be changed, and the interface location can be changed
Closes #19059