Extend plugin configuration #1062
Replies: 2 comments 1 reply
-
I like this plugin configuration quite a lot! Keeping the plugin attributes out of the root level of <py-config> is swell, and prevents us from running into naming collisions for plugin attributes down the road. +1 from me. One small comment on the proposed format - it feels slightly awkward that [plugins.dog-facts]
path = "site/dogs.py"
goodpet = true
[plugins.alligator-warning]
path = "site/gator.py"
goodpet = false or in JSON {
"plugins": {
"dog-facts": {
"goodpet": true,
"path": "site/dogs.py"
},
"alligator-warning": {
"goodpet": false,
"path": "site/gator.py"
}
}
} |
Beta Was this translation helpful? Give feedback.
-
Got to have a big ole conversation last week about Plugin metadata configuration at the February offsite - here's an updated proposal for plugin configuration and what the |
Beta Was this translation helpful? Give feedback.
-
Python plugins are a bit of a hidden feature since they are still a WIP, but we can fetch a python plugin like this:
Under the hood, we use the same logic as
[[fetch]]
to try to import the python plugin; providing that we have access, the plugin should be available and usable.Using a list for plugins is a good and easy way to get plugins into a pyscript app. We could also allow users to use an extended plugin configuration.
Plugin configuration proposed
Or using json
This could be a good way to allow users to pass specific configurations to the plugins, for example:
Pyscript could then use those extra configurations available as hooks for the plugin itself (which I think is the idea of the
plugins.configuration
.Some concerns
Using this extended configuration does bring some issues. For once, it will be easier to have a bad config if you don't know toml/json.
The code that ingests the config and looks over the plugins will have to be more complex to handle the more complex structure.
Beta Was this translation helpful? Give feedback.
All reactions