Support reading config setting specs from module #237
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nhoening
requested changes
Nov 11, 2021
nhoening
approved these changes
Nov 11, 2021
|
|
||
| You might want to override some FlexMeasures configuration settings from within your plugin. Some examples for possible settings are named on this page, e.g. the custom style (see above) or custom logo (see below). There is a `record_once` function on Blueprints which can help with this. Example: | ||
| Alternatively, use ``from my_plugin import __settings__`` in your plugin module, and create ``__settings__.py`` with: |
There was a problem hiding this comment.
Technically, you can have your settings in a module with any name you want and import them with:
from my_plugin import whatever_settings as __settings__
But a Python programmer should understand that.
There was a problem hiding this comment.
True. I also tried having FlexMeasures look specifically for a __settings__.py in the plugin module, but I couldn't figure out how to do that. That would have saved the import statement, while requiring an explicit filename.
Flix6x
added a commit
that referenced
this pull request
Nov 15, 2021
Support reading config setting specs from module (#237) * Support reading config setting specs from module * Add additional documentation (review suggestion) * Amend changelog entry
Flix6x
added a commit
that referenced
this pull request
Dec 3, 2021
Make JSON attributes mutable and have the API package get and set metadata on GenericAssets and Sensors. Applies to all version of the API, but excludes CRUD functionality on assets in API v2.0. * Create draft PR for #239 * Db migration that copies over attributes from old data models * - In Asset.__init__, copy over attributes to GenericAsset. - Start having our model_spec_factory get attributes it needs from GenericAsset. - Rename variables, specifically, variables that were annotated as a union of our old sensor models were named generic_asset, which was too easily confused with instances of our GenericAsset class. * model_spec_factory now gets its attributes from GenericAsset instead of old sensor model types * More renaming to avoid confusion * Have db migration copy over sensor attributes: unit, event_resolution and knowledge horizons * In Asset.__init__, copy over sensor attributes: unit, event_resolution and knowledge horizons * model_spec_factory now gets event_resolution and name from Sensor * Fix tests * Factor out use of corresponding_generic_asset attribute * Factor out use of corresponding_generic_asset attribute * More renaming * Pass time series class to model configurator explicitly * Finally, model_spec_factory doesn't need the old sensor model anymore * Allow setting the collect function name for TBSeriesSpecs to something custom * In Asset.__init__, copy over additional asset attributes to GenericAsset * Planning subpackage uses sensors instead of assets * Move some simple attributes in the UI package * Refactor to stop explicitly passing the market to the scheduler, and instead have the scheduler check for an applicable market * Revert "Move some simple attributes in the UI package", because this needs to be done jointly with moving over asset crud (which we test for) This reverts commit 56ff279. * Create draft PR for #242 * Allow config setting specs as module variables, too. Support reading config setting specs from module (#237) * Support reading config setting specs from module * Add additional documentation (review suggestion) * Amend changelog entry * Create draft PR for #242 * Make JSON attributes mutable * Set Asset owner at initialization, so it is copied to GenericAsset * API v1_2 gets and sets asset attributes in the new data model * Deprecate use of Asset class in api v1_2 * Deprecate use of Asset class in api v1_3 * Revert "Allow config setting specs as module variables, too." This reverts commit 327b8b6. * Work around black issue by updating pre-commit-config * Deprecate use of Asset class in api v1_0 * Deprecate use of Asset class in part of api v2_0 * Fix docstring * Revert upgrade of black in pre-commit-config * Still battling black * Correct docstring * Deprecate use of Asset class in SensorField deserialization * Set Asset owner at initialization, so it is copied to GenericAsset * Simplify conftest * Add notes about how each attribute is to be copied from an old class to a new class * Rename variables * Refactor attribute copying to util function * In Market.__init__, copy over attributes from old models to new models * In Weather.__init__, copy over attributes from old models to new models * Deprecate use of Market class in SensorField deserialization * Deprecate use of WeatherSensor class in SensorField deserialization for fm1 * Simplify fm1 entity type schema for deserialization * Deprecate use of WeatherSensor class in SensorField deserialization for fm0 * Refactor query * Rename variable * Refactor query to arrive at a single combined query * Update todos * Intend to copy display_name to both GenericAsset and Sensor * Introduce Sensor attributes and copy most old model attributes there instead of to GenericAsset attributes * Adjust attribute copying in Asset.__init__ * Implement Sensor method to get an attribute * Give old sensor classes a generic_asset property * Give old sensor classes a get_attribute property * Derive Sensor class lat/lng location from GenericAsset * Get attributes from Sensor rather than from GenericAsset * Resolve merge conflict * Refactor after resolving merge conflict * Adjust attribute copying in Market.__init__ * Adjust attribute copying in WeatherSensor.__init__ * Post-merge cherry-pick: Set default attributes on generic assets, too * Post-merge cherry-pick: Add clarity to method docstring * Introduce has_attribute and set_attribute on the Sensor class, too * Remove redundant import * Get attributes from Sensor * Simplify (as requested in PR review) * Add docstring to migration util functions, explaining their parameters * Add module docstring * Add todos * Make Sensor attributes mutable, too * Avoid assumptions on db type (specifically, postgres) * Update upgrade migration docstring * Deprecate use of Market class in api v1_1 * Separate setup of market types and markets for tests, otherwise we run into flush issues * Remove redundant copy, now that we initialize super() first * Fix bugs: work on kwargs before copying from it and move up initialization of super() * Increase the chance of identifying a unique sensor by just its name, if you also know the name of its generic asset type * Simplify API tests by removing the owner id from event-type entity addresses, as the server ignores this optional field anyways * Simplify API tests by removing the owner id from event-type entity addresses, as the server ignores this optional field anyways * Deprecate use of Asset class in v1_3 tests * Deprecate use of Asset class in v1_2 tests * Deprecate use of Asset class in v1 tests * Deprecate use of Market class in v1_1 tests * Fix merge errors * Update string status code * Rename legacy migration module Co-authored-by: Flix6x <Flix6x@users.noreply.github.com> Co-authored-by: F.N. Claessen <felix@seita.nl> Co-authored-by: Felix Claessen <30658763+Flix6x@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.